Stablecoin Payment Flows
Every stablecoin payment flow step by step — checkout by deposit address, payment request, signed authorization and authorize-and-capture escrow; stablecoin-linked cards; on- and off-ramps and issuer mint/redeem; B2B Travel Rule and cross-chain CCTP transfers; refunds, subscriptions and exceptions — with best practices for each and a payment matcher that classifies real-world transfers.
Five ways a merchant gets paid in stablecoins — push to a deposit address, a payment-request QR, a gasless signed authorization, card-style authorize & capture, and acceptance settled to the merchant in fiat.
The most common checkout: the processor quotes the order in a coin, issues a fresh deposit address for it, and the customer pushes a transfer from any wallet or exchange. Token transfers carry no payment reference, so the address is the reference.
Create invoice: 49.90 USD
Order id, price, accepted coins and chains, idempotency key.
The processor fixes the amount in token units — 49.90 USDC is 49900000 at 6 decimals — and an expiry, typically 15–60 minutes. A dollar coin needs no FX quote for a dollar price; a euro price paid in USDC does, and the quote is what expires.
- One address per invoice or per customer, never shared across merchants — the address is the payment reference.
- Match on chain + canonical token contract + address; never on symbol, and never on amount alone.
- Show the chain as prominently as the address, and list only the chains you actually watch.
- Make status a state machine (awaiting, partial, paid, overpaid, underpaid, expired, held), not a paid flag.
- Apply a finality rule by chain and amount before fulfilling; keep watching expired addresses.
- Prefer contract deposit addresses (CREATE2) so sweeps need no per-address gas top-up.
- Look-alike tokens: any contract can emit a Transfer event named "USDC".
- Exchange withdrawals arrive short by the exchange’s fee.
- The same 0x address on another EVM chain — the commonest support ticket.
- Reusing addresses across invoices makes late and duplicate payments unattributable.
| Method | Initiation | Gas paid by | Payment reference | Amount control | Cancel before settlement | Refund | Best for |
|---|---|---|---|---|---|---|---|
| Unique deposit address | Push — the payer sends | Payer | The deposit address | Payer types or scans it; short, over and late payments happen | Nothing to cancel — expire the invoice | New transfer to a collected address | Any wallet or exchange; the default |
| Payment request (Solana Pay / EIP-681) | Push, built by the wallet | Payer (or merchant via transaction request) | Reference key (Solana); none on EIP-681 | Encoded in the request | Expire the request | New transfer | In-store QR and mobile wallets |
| Signed authorization (EIP-3009) | Pull — the processor submits a signature | Processor | Authorization nonce | Exact, signed | cancelAuthorization or let it expire | New transfer | Gasless checkout, API and agent payments (x402) |
| Authorize & capture escrow | Pull into escrow, then capture | Operator | Payment id (hash of the terms) | Capped by the signed maximum; partial capture | void; payer reclaims after expiry | refund() within the signed window | Physical goods, split shipments, marketplaces |
| x402 (HTTP 402) Open flow → | Pull — facilitator settles a signature | Facilitator | Authorization nonce + HTTP request | Exact, from the 402 quote | Let it expire | Application-level transfer | Per-request API and AI-agent payments |
| Stablecoin-linked card | Card authorization (ISO 8583) | Issuer, off the payment path | Card identifiers (RRN, ARN) | Card rules (partial, incremental, tips) | Reversal | Card refund; chargeback rights | Spending at any card acceptor |
Every method settles with the same finality: once the transfer is final it cannot be recalled. What differs is who signs, who pays gas, how the payment is found again, and whether anything can be cancelled before the money reaches the merchant.
Token transfers carry no payment reference. A processor issues an address, then has to decide what every transfer that reaches it means. Pick a case or build your own: the matcher applies the rules below and says what to do.
Canonical contract: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
Finality on Base: ≈ 20 min — Final once the batch holding the block is posted to Ethereum and that L1 block is finalized — about 20 min (“safe”, batch on L1, after about 2 min). All chains →
| # | Chain | Token | Amount | Block at (min) | Finality | Sender screening | Result | |
|---|---|---|---|---|---|---|---|---|
| 1 | Counted |
- Mark paid and fulfil. Store chain, token contract, tx hash, log index and block time on the order — that tuple is the settlement reference.
Rules, in order: a transfer counts only on the invoiced chain, from the canonical token contract, included in a block no later than the expiry minute. A sender-screening hit holds the whole invoice. A soft-confirmed transfer counts only when the invoice amount is at or below the soft-finality limit; unconfirmed transfers never count. Paid when the counted amount reaches the invoice minus the tolerance. A teaching model — real processors add per-chain confirmation rules and their own policies.
Coins, chains and contracts: Stablecoin Reference · field by field: ISO 8583 ↔ On-Chain Settlement Mapper · settlement timing: Stablecoin Settlement Simulator · platform flows: BVNK Flow Simulator · HTTP payments: x402 Flow Simulator · decode an authorization: Calldata & EIP-712 Decoder · check an approval: Approval & Address Risk Checker · background: Stablecoin Payments 101.
Why stablecoin payments need their own flows
A stablecoin transfer is final within seconds to minutes, runs every day, and costs cents — but it carries no payment reference, cannot be recalled, and moves whatever amount the sender typed. Every flow on this page is a different answer to the same three questions: how does the processor know which order a transfer pays, who signs and who pays the gas, and what can still be undone before the merchant has the money.
Push flows (a deposit address, a payment request) work from any wallet or exchange, so they are the default — and they produce short, over, late and wrong-network payments the processor must handle. Pull flows (an EIP-3009 authorization, an authorize-and-capture escrow, a spend permission) fix the amount and payee in a signature, so those exceptions disappear and the processor pays the gas. Stablecoin-linked cards keep the card network in front, so merchants change nothing and cardholders keep chargeback rights.
The checklist every flow shares
- Identify the asset by contract, not symbol. Native USDC on Arbitrum is
0xaf88…5831; bridged USDC.e is a different token at a different address. - Apply a finality rule by chain and amount. Ethereum finalizes after two epochs (about 13 minutes); an OP-stack L2 such as Base is final when its batch is final on L1; Solana’s “finalized” commitment comes about 13 seconds after a block; Stellar and the XRP Ledger are final when the ledger closes.
- Screen counterparties and exchange Travel Rule data between regulated providers before value moves; never auto-return funds after a sanctions hit.
- Keep gas-token balances on every chain you send from, and treat running out as an outage.
- Refund by new transfer to a collected address — never by default to the sender, which may be an exchange.
- Store chain, contract, tx hash, log index and block time on every payment record: together they replace the card world’s RRN and ARN.
Common questions
Which acceptance method should a merchant start with?
A unique deposit address, settled to the merchant in fiat: it works with every wallet and exchange and keeps digital assets off the merchant’s books. Add signed authorizations for wallets that support them (no gas needed by the payer, no wrong amounts), and an authorize-and-capture escrow where orders ship later or in parts.
Can a stablecoin payment be charged back?
Not on-chain. A refund is a new transfer; an escrow can void uncaptured funds and refund within a signed window. Chargeback rights exist only when the payment ran over card rails — a stablecoin-linked card.
Why does a payment arrive short?
Usually because an exchange deducted its withdrawal fee from the amount. The sender pays on-chain gas on top, so a direct wallet transfer arrives in full. Processors either accept a small tolerance or ask for a top-up.
What is the difference between transferWithAuthorization and receiveWithAuthorization?
Both move tokens with the payer’s EIP-3009 signature. receiveWithAuthorization can only be submitted by the payee itself, which stops a third party from submitting the signature first and breaking the payee contract’s own call.
Flows follow the EIP-3009, EIP-681 and Solana Pay specifications, the Commerce Payments Protocol and Spend Permissions contracts, Circle’s CCTP V2 contracts and the EU Transfer of Funds Regulation, checked October 2026. Everything runs in your browser; no network requests are made.