A stablecoin transfer can appear in a block before a merchant should treat it as final. “Pending,” “confirmed” and “finalized” describe different states, and the exact meaning depends on the blockchain and the payment provider’s policy.

The token may be called a dollar, but settlement still follows the chain underneath it.

Documentation reviewed: 28 October 2026. Confirmation rules and provider thresholds can change. Check the provider and network documentation for a live payment.

Four separate questions

When a customer sends a stablecoin, ask:

  1. Was the transaction submitted to the intended network?
  2. Did the network include it in a block?
  3. Has the chain reached the confirmation or finality state required by the recipient?
  4. Has the payment application matched the transfer to the correct order?

A transaction hash answers the first question. It does not answer all four.

Pending

“Pending” usually means the transaction has been signed and broadcast but has not reached the application’s acceptance threshold.

On an account-based chain, it may still be waiting in a transaction pool. It can be delayed by a low fee, an unavailable RPC provider, a conflicting nonce or network congestion.

A merchant should not release irreversible goods based on a screenshot of a pending transaction. Check the chain and the processor’s payment object.

Included or processed

Once a validator or block producer includes the transaction, the token transfer can appear in the recipient’s balance.

That is stronger evidence than a wallet’s “sent” screen, but an early block can still be replaced under some consensus conditions. Applications often use a fast status for user feedback and a stronger status for settlement.

Solana’s official RPC documentation calls its newest view processed. It says this view can still be rolled back. The same documentation defines confirmed and finalized as progressively stronger states; see Solana commitment levels.

Confirmed

“Confirmed” is not a universal number of blocks.

On Solana, the official RPC definition says a confirmed block has been directly voted on by more than two-thirds of active stake. On another chain or inside an exchange, “confirmed” may mean a certain block depth or an internal risk rule.

A payment page should state the chain and the acceptance rule. “One confirmation” without a network name is incomplete.

Finalized

Finality is the network’s strongest settlement state, but its mechanics differ.

Ethereum’s proof-of-stake documentation describes finality through justified and finalized checkpoints. A finalized block cannot be reverted without a critical consensus failure and the destruction of at least one-third of total staked ether. The protocol explanation is in Ethereum’s Gasper documentation.

Solana’s RPC documentation defines finalized as the cluster’s strongest confirmation state using maximum lockout.

These definitions are protocol properties. They do not guarantee that a merchant matched the correct token, amount or order.

Why the merchant can still show unpaid

A transaction may be final onchain while the checkout remains unpaid because:

  • the customer used the wrong network;
  • the token contract is not the supported one;
  • the amount is short after an exchange withdrawal fee;
  • the transfer arrived after the quote expired;
  • the memo, destination tag or payment identifier is missing;
  • the processor’s indexer is delayed;
  • the payment address was reused incorrectly.

This is why checkout reconciliation matters. Read how businesses accept stablecoin payments for the full order-to-settlement flow.

Token transfer and native gas

A successful stablecoin transfer records token movement through the token contract. The network fee is paid according to the chain’s gas model.

On Ethereum, USDT or USDC transfer status should be checked at the token-transfer event and transaction receipt, not only by looking at the ETH balance. Our Ethereum stablecoin gas guide explains the fee side.

On Solana, check the correct token account and cluster. A transaction on Devnet is not a Mainnet payment.

A merchant acceptance policy

A useful written policy separates customer messaging from fulfillment risk.

Stage Customer message Merchant action
Submitted Payment detected Do not fulfill yet
Included/processed Payment seen onchain Reserve inventory
Confirmed Network threshold reached Fulfill ordinary reversible orders if policy allows
Finalized Strongest network state Fulfill high-risk or irreversible orders
Reconciled Correct token, chain, amount and order Close the invoice

The table is a policy example, not a universal requirement. A coffee purchase and a high-value digital asset should not necessarily use the same threshold.

Build the policy from the product backward

For low-value physical goods, waiting for finality may add unnecessary friction if shipment can still be stopped. For instant delivery of non-recoverable digital goods, a stronger threshold may be appropriate.

Record:

  • supported chains and token contracts;
  • minimum accepted amount;
  • status required for each product class;
  • timeout and underpayment rules;
  • manual-review threshold;
  • refund route;
  • evidence stored with the order.

A payment provider may abstract the chain states into one status. Read its documentation to learn what that status means.

Reorgs, outages and indexer delays

A reorganisation changes which recent blocks are canonical. Stronger confirmation states reduce this risk, but “zero risk” is not a useful promise.

An RPC or indexer outage can also create a display problem without changing the chain. Compare the provider status, a second reputable explorer and the transaction receipt before asking the customer to pay again.

Never request a duplicate payment merely because one dashboard is delayed.

Questions people ask

Is a transaction hash proof of payment?

It proves that a transaction exists. You still need to verify the chain, token contract, recipient, amount, execution status and acceptance threshold.

How many confirmations does USDC need?

There is no single USDC-wide number. The rule depends on the network and the recipient’s provider or policy.

Can a finalized transfer be refunded?

A blockchain refund is usually a new transfer. The original transaction is not reversed. See the processor’s refund rules and verify the recipient address.

Why does the wallet show money before the merchant accepts it?

The wallet may display an early chain state, while the merchant waits for a stronger status and order reconciliation.

Sources

This explainer does not replace a processor’s live settlement rules.