
Paying with cryptocurrency can appear almost instantaneous. A customer scans a QR code, confirms an amount in a wallet and sees a success message. Behind that simple interface, however, several technical and financial processes must occur before the merchant can treat the payment as final.

The wallet constructs and signs a transaction, the blockchain network checks it, and a miner or validator includes it in a block. A payment processor may then monitor confirmations, compare the received amount with the invoice and notify the merchant’s system.
Receiving crypto and receiving money in a bank account are not necessarily the same event. Some merchants keep the digital asset, while others use a processor that converts it into a stablecoin or traditional currency. Understanding this sequence explains why payments can remain pending, fail or settle for a different amount than expected.
The Merchant First Creates a Payment Request
The process normally begins before the customer opens a wallet. The merchant or payment processor generates an invoice containing the amount, accepted asset, blockchain network, receiving address and payment deadline.
A customer downloading payment-related software through a page such as melbet apk indir may encounter a checkout designed to hide much of this technical complexity. The interface can display a familiar currency value while automatically calculating the required crypto amount.
A payment request may contain:
- The price in the merchant’s accounting currency.
- The corresponding amount of cryptocurrency.
- A destination wallet address.
- The required blockchain network.
- A QR code containing payment details.
- A time limit for completing the transfer.
- A unique invoice or order identifier.
- The number of confirmations required.
- Instructions concerning network fees.
Invoice element | Purpose |
Payment amount | Tells the wallet how much to transfer |
Asset | Identifies the required cryptocurrency or token |
Network | Prevents transfer through an incompatible blockchain |
Address | Directs the funds to the correct recipient |
Expiration time | Limits exposure to exchange-rate changes |
Order reference | Connects the transfer with the purchase |
Confirmation policy | Defines when the merchant considers payment final |
QR code | Reduces manual entry errors |
Crypto invoices often expire because the exchange rate can move rapidly. If a customer pays after the deadline, the merchant may need to recalculate the amount or review the transaction manually.
The Customer’s Wallet Prepares the Transaction
After the customer selects the payment option, the wallet reads the address, asset, network and requested amount. A user accessing an account through a page such as melbet app login may see only a confirmation screen, but the wallet must construct a valid blockchain transaction underneath.
The exact structure depends on the network. In general, the wallet specifies:
- Which account or coins will fund the payment.
- The recipient’s address.
- The amount being transferred.
- The network fee.
- A sequence number or other anti-replay information.
- Any smart-contract instructions required for a token.
- A possible refund or change output, depending on the blockchain.
Wallet action | Customer sees | Technical purpose |
Select balance | Available crypto amount | Identifies funds that can be spent |
Enter recipient | Address or QR code | Establishes the destination |
Confirm amount | Payment total | Defines the transferred value |
Choose fee | Estimated network cost | Influences processing priority |
Approve payment | Password, PIN or biometrics | Authorises use of the wallet |
Submit transaction | Pending status | Broadcasts signed instructions |
For a native blockchain asset, the wallet transfers value directly according to the network’s transaction model. For a token such as a stablecoin, it may call a smart contract that updates token balances.
The customer should always verify the amount, asset and network. Sending the correct token through an unsupported network can make recovery difficult or impossible.
The Private Key Creates a Digital Signature
A wallet does not send the private key to the merchant or blockchain. Instead, it uses the key to create a cryptographic signature authorising the transaction.
The signature demonstrates that the transaction was approved by someone controlling the relevant wallet. Network participants can verify the signature without learning the private key itself.
This stage provides several important protections:
- The payment cannot be validly created without control of the key.
- Transaction details cannot be changed without invalidating the signature.
- Network nodes can verify authorisation independently.
- The merchant does not need access to the customer’s wallet credentials.
- A central bank or payment company is not required to sign the transfer.
The security of the payment therefore depends heavily on private-key protection. If an attacker obtains a seed phrase or signing key, the network may treat the attacker’s transactions as legitimate.
Custodial wallets operate differently from self-custody wallets. With self-custody, the user controls the keys and signs directly. With a custodial service, the provider may authorise and execute the transfer from wallets it controls after confirming the user’s request internally.
The Wallet Broadcasts the Transaction to the Network
Once signed, the transaction is sent to one or more network nodes. Those nodes perform initial checks and pass the transaction to other participants.
They may verify that:
- The signature is valid.
- The sender has sufficient funds.
- The transaction follows the network’s rules.
- The sequence number or nonce is correct.
- The same funds have not already been spent.
- The network fee meets minimum requirements.
- The smart-contract instruction is valid.
If the transaction passes these checks, it enters a pool of pending transactions. Bitcoin commonly refers to this as the mempool, while account-based networks maintain comparable pending-transaction systems.
At this point, the merchant’s processor may detect the payment. Detection does not necessarily mean final settlement. The transaction is visible to the network but may not yet have been included in a confirmed block.
Transaction status | Meaning |
Created | Wallet assembled the payment |
Signed | Customer authorised it cryptographically |
Broadcast | Transaction reached network nodes |
Pending | Waiting for block inclusion |
Confirmed | Included in a validated block |
Finalised | Reversal has become sufficiently unlikely |
Failed | Network did not execute the transaction successfully |
Dropped | Pending transaction was removed or replaced |
A transaction can remain pending if the network is congested, the fee is too low or the wallet has submitted another conflicting transaction.
Miners or Validators Select the Transaction
Blockchains need a consensus mechanism to agree on valid transactions and their order. On proof-of-work networks, miners assemble transactions into candidate blocks. On proof-of-stake networks, validators propose and attest to blocks.
Selection is influenced by network rules and economic incentives. Transactions offering competitive fees are often processed sooner, especially during congestion.
The block producer checks the transaction again and executes any required state changes. If accepted, the transaction becomes part of a block distributed across the network.
The process differs by blockchain:
Network characteristic | Effect on payment |
Block interval | Influences time until initial inclusion |
Capacity | Determines how many transactions fit |
Fee market | Affects priority during congestion |
Consensus mechanism | Defines how blocks are approved |
Finality rules | Determine when reversal becomes unlikely |
Smart-contract design | Controls token transfer execution |
A wallet may show an estimated completion time, but this remains an estimate. Demand can change rapidly, and block producers decide which valid transactions to include.
Confirmation Reduces the Risk of Reversal
A transaction receives its first confirmation when it is included in a block accepted by the network. Each subsequent block built on top of it generally makes reversal more difficult.
Merchants choose confirmation requirements according to the asset, network, transaction value and risk tolerance.
A coffee shop might accept a low-value payment after network detection or one confirmation. A merchant selling an expensive product may wait longer. Some networks provide stronger forms of finality that do not map directly to Bitcoin-style confirmation counts.
Payment type | Possible confirmation approach |
Small in-person purchase | Fast detection or minimal confirmation |
Ordinary online order | Standard processor policy |
Digital product | Automatic release after confirmation |
High-value merchandise | Additional confirmations |
Exchange deposit | Platform-specific threshold |
Large business settlement | Strong finality and compliance review |
Waiting protects the merchant against double spending, chain reorganisations and transactions that fail to become final. The appropriate delay depends on the network rather than a universal crypto standard.
The checkout page may show “payment detected” before it shows “payment complete.” These statuses reflect different stages of confidence.

The Processor Matches the Transaction to the Invoice
A payment processor monitors one or more receiving addresses and compares incoming transactions with active invoices. It must determine whether the customer sent the correct asset, amount and network.
The processor typically checks:
- Destination address.
- Token contract.
- Blockchain network.
- Amount received.
- Transaction identifier.
- Time of receipt.
- Confirmation count.
- Invoice expiration.
- Required compliance conditions.
Matching is easy when each invoice receives a unique address. If one address accepts many payments, the processor may rely on unique amounts, reference fields or other identifiers.
Once the transaction meets the processor’s policy, it updates the invoice and sends a notification to the merchant’s website. This notification is often delivered through a webhook—an automated message from the payment service to the merchant’s server.
The merchant’s system can then:
- Mark the order as paid.
- Release a digital product.
- Send an order confirmation.
- Begin fulfilment.
- Update inventory.
- Record the transaction for accounting.
A merchant should verify webhook authenticity. Otherwise, an attacker could attempt to send a false payment notification without transferring any funds.

Underpayments and Overpayments Require Special Handling
Crypto payments do not always match the invoice exactly. A customer may forget that the network fee is separate, use an outdated exchange rate or manually enter the wrong amount.
An underpayment occurs when the merchant receives less than required. An overpayment occurs when the customer sends too much.
Payment problem | Likely cause | Possible response |
Small underpayment | Fee deducted from payment amount | Request difference or accept tolerance |
Large underpayment | Incorrect manual entry | Keep invoice pending |
Overpayment | Customer entry error | Issue a refund |
Late payment | Invoice rate expired | Recalculate or review manually |
Wrong asset | Wallet selection error | Attempt recovery if supported |
Wrong network | Incompatible transfer route | Manual technical investigation |
Duplicate payment | Customer repeated transaction | Refund or credit balance |
Processors can define tolerances for small differences. A merchant may accept an amount slightly below the invoice when the cost of resolving it exceeds the missing value.
Refunds require care. The merchant should not automatically send funds to an address supplied through an unverified message. The original sending address may also belong to an exchange rather than directly to the customer.
Network Fees Are Usually Separate From the Purchase
A crypto payment may involve several types of cost. The customer typically pays a network fee for including the transaction in the blockchain. A wallet provider, exchange or processor may charge additional fees.
The complete cost can include:
- Blockchain gas or miner fee.
- Wallet withdrawal fee.
- Exchange conversion fee.
- Payment processor fee.
- Merchant conversion spread.
- Bank withdrawal fee.
- Foreign-exchange cost.
The merchant may receive the requested crypto amount while the customer pays the network fee separately. In other systems, the fee can effectively reduce the amount received if the sender selects an incorrect withdrawal method.
This is why checkout instructions should clearly state whether the displayed total includes network costs.
Layer-two networks and specialised payment chains can reduce fees, but they add another requirement: both the wallet and merchant must support the same network.
The Merchant Chooses How to Receive the Value
After confirmation, the merchant does not necessarily receive traditional currency. The settlement method depends on the payment arrangement.
Common options include:
- Settlement in the original cryptocurrency.
- Automatic conversion into a stablecoin.
- Conversion into dollars, euros or another fiat currency.
- Division between crypto and fiat balances.
- Aggregation of many payments before withdrawal.
- Direct transfer to a merchant-controlled wallet.
Settlement preference | Advantage | Main exposure |
Original crypto | Retains full digital asset | Price volatility |
Stablecoin | Easier accounting value | Issuer and peg risk |
Fiat currency | Matches ordinary expenses | Conversion and banking fees |
Mixed settlement | Balances flexibility and stability | More complex accounting |
Processor balance | Convenient management | Dependence on provider |
Self-custody wallet | Direct control | Key-management responsibility |
A merchant that keeps Bitcoin assumes market risk after receiving it. A merchant that converts immediately avoids much of that volatility but pays conversion costs and depends on available liquidity.
Stablecoin settlement can provide a middle route: the funds remain on-chain while their value is linked to a familiar currency.
Conversion May Happen Before the Merchant Notices
Some processors quote the customer in one asset but guarantee the merchant settlement in another. The processor handles conversion in the background.
For example, a customer may pay with a volatile cryptocurrency while the merchant receives a dollar-linked stablecoin or bank deposit. The processor may use an exchange, internal liquidity or a market-making partner to complete the conversion.
The exchange rate can be determined:
- When the invoice is created.
- When the transaction is detected.
- After the required confirmations.
- When the merchant requests withdrawal.
- According to a guaranteed-rate window.
Each method allocates volatility differently. If the rate is locked at checkout, the processor assumes some price risk during the payment window. If conversion occurs only after confirmation, the final merchant amount may differ from the initial estimate.
Merchants should understand the settlement policy rather than assuming the checkout rate is automatically guaranteed.
Compliance Checks Can Delay Settlement
Blockchain settlement may be fast, but payment providers still need to follow legal and compliance requirements. A processor can screen wallet addresses, monitor suspicious activity and review transactions before allowing withdrawal.
Possible checks include:
- Customer identity verification.
- Merchant identity and business verification.
- Sanctions screening.
- Transaction monitoring.
- Source-of-funds review.
- Geographic restrictions.
- High-risk wallet analysis.
- Tax and reporting requirements.
A transaction can be confirmed on-chain while the merchant’s processor balance remains restricted. Blockchain finality and platform availability are separate issues.
This distinction is especially important for high-value or unusual transactions. The network may consider the transfer valid, but a regulated company may still require additional information before converting or releasing the funds.
Fiat Settlement Reintroduces the Banking System
If the merchant chooses bank settlement, the final stage takes place outside the blockchain. The processor sells or otherwise converts the crypto and sends ordinary currency to the merchant’s bank account.
This stage may involve:
- Crypto conversion.
- Deduction of processing fees.
- Aggregation into a payout batch.
- Compliance review.
- Creation of a bank transfer.
- Processing by one or more banks.
- Credit to the merchant account.
- Reconciliation with individual orders.
Stage | Infrastructure used |
Customer signs payment | Crypto wallet |
Transaction broadcast | Blockchain network |
Confirmation | Miners or validators |
Invoice matching | Payment processor |
Asset conversion | Exchange or liquidity provider |
Fiat payout | Banking network |
Accounting match | Merchant’s financial system |
Even if the blockchain transfer occurs at the weekend, the bank payout may wait until a working day. The merchant may therefore see a completed crypto payment before receiving spendable fiat money.
Reconciliation Connects Payments With Business Records
Settlement is not complete from an operational perspective until the merchant can match the received funds with orders, fees, refunds and payouts.
A processor may provide:
- Invoice identifiers.
- Transaction hashes.
- Original currency amounts.
- Crypto amounts received.
- Exchange rates.
- Processing fees.
- Settlement currency.
- Payout references.
- Confirmation timestamps.
- Refund records.
Reconciliation becomes more complicated when one bank payout combines hundreds of crypto purchases. The merchant’s accounting system must connect the total payout with every underlying transaction.
Accurate records are also important for tax purposes. Depending on the jurisdiction, receiving, holding, converting or refunding cryptocurrency can create separate reporting consequences.
Failed Transactions Do Not All Fail in the Same Way
A payment may fail before broadcast, during network execution or inside the merchant’s processing system.
Common failure scenarios include:
- Insufficient wallet balance.
- Insufficient funds for the network fee.
- Incorrect nonce or transaction sequence.
- Smart-contract execution error.
- Payment sent after invoice expiration.
- Unsupported token or network.
- Transaction replaced by another.
- Processor unable to match the payment.
- Compliance hold.
- Conversion or payout failure.
A failed smart-contract transaction may still consume a network fee because validators performed computational work even though the intended transfer did not complete.
Users should check the transaction through a reliable block explorer and compare its status with the merchant’s invoice. A visible transaction hash alone does not prove successful payment.
Refunds Are New Transactions
A crypto refund does not reverse the original blockchain entry. Instead, the merchant creates a new transaction sending value back to the customer.
This has several consequences:
- A new network fee may apply.
- The refund amount must be calculated.
- The return address must be verified.
- Exchange-rate changes may affect value.
- The original payment remains permanently recorded.
- Refund processing may require manual approval.
If the customer paid with a volatile asset, the merchant must decide whether to refund the original crypto quantity or the original fiat value. These approaches can produce different results after a price change.
Clear refund terms should explain which value is used, who pays the network fee and how long processing may take.
Merchant Settlement Is a Chain of Separate Events
A crypto payment is not one single action. It is a sequence of connected events, each with its own technology and risk.
The full process can be summarised as follows:
- The merchant generates an invoice.
- The wallet prepares the transaction.
- The customer authorises it with a digital signature.
- The wallet broadcasts it to the network.
- Nodes validate the basic rules.
- A miner or validator includes it in a block.
- Confirmations increase confidence in finality.
- The processor matches the transaction to the order.
- The merchant receives a payment notification.
- Crypto is held or converted according to settlement preferences.
- Fiat funds may be paid into a bank account.
- The merchant reconciles the payout with business records.
The customer may see only the first few seconds of this journey. The merchant, however, must manage the entire lifecycle.
Crypto payments combine wallet security, blockchain consensus, payment processing, asset conversion and traditional accounting. Their apparent simplicity is created by software that coordinates these separate layers.
A successful payment therefore means more than broadcasting a transaction. The right asset must reach the right address on the right network, become sufficiently final, match an active invoice and settle in the form the merchant expects.
As payment interfaces improve, much of this complexity will become less visible. Customers will scan, approve and receive confirmation, while processors manage validation, conversion and settlement in the background. The underlying sequence will remain essential, even when users no longer need to think about it.