How Stablecoin Payments Work

Editorial status: PUBLISHED. AI-assisted educational material; user batch approval recorded on 2026-10-19. The payment route, fees and exchange values are fictional; no provider or transfer was tested.

Learning objectives

• Trace a payment through funding, transfer, conversion and receipt.
• Identify which obligation each confirmation actually satisfies.
• Calculate received value without counting the same conversion twice.

Payment is an end-to-end obligation

A stablecoin transfer changes a recorded token position. A payment also has a payer, payee, amount, agreed settlement asset and completion condition. Sometimes the payee accepts the token itself. Sometimes a service converts it into bank currency before the merchant is paid. These arrangements have different boundaries and counterparties.

BIS Bulletin 73 analyzes stablecoins and tokenized deposits as different monetary arrangements, including the possibility of stablecoin prices deviating from par. It does not guarantee that a named token redeems into bank money or that a merchant accepts it. BIS: Stablecoins versus tokenised deposits

For research, draw the whole route: source of funds, token issuer, wallet or custody service, transfer network, conversion provider and recipient account. A network confirmation is evidence for one step, not proof of every downstream obligation.

Worked example: token delivered, merchant not yet paid

Imagine a fictional invoice requires the merchant to receive 995 currency units in its bank account. The payer starts with 1,000 token units, each assumed worth one currency unit for this exercise. The route deducts a stated 2-unit transfer cost and a 3-unit conversion cost from the same starting amount. With no additional costs or price changes, the expected bank receipt is 1,000 − 2 − 3 = 995.

The transfer confirms at time A. The conversion provider acknowledges receipt at time B. The recipient bank records 995 at time C. If the agreed invoice completion condition is bank receipt, only the evidence at C establishes that condition. A screen displaying “sent” at A should not be described as completed merchant payment.

Now suppose conversion produces only 990 because the assumed one-to-one value no longer holds. The invoice may remain short by 5 under the fictional agreement. Determine who bears that difference from the actual payment terms; do not invent a provider guarantee.

Payer's 1,000 tokens → transfer cost 2 → provider receives 998
    → conversion cost 3 → expected bank receipt 995
Token confirmation ≠ conversion completion ≠ recipient bank receipt

The example assumes a single currency equivalent and deducts two distinct costs once. A quoted all-in conversion rate might already include a spread; adding it again would overstate cost.

Record completion and recovery separately

Specify the transaction reference, destination network and asset, amount, fees, conversion quote expiry and recipient condition. A similar-looking token on another network is not automatically the asset the recipient agreed to accept. Use the actual service instructions and verify which party can recover a wrong-network transfer, if any.

A timeout does not establish failure. Preserve the original business payment reference and authoritative token result before retrying. The conversion service may have received funds even when its interface is unavailable. Maintain unresolved, returned and completed states rather than reducing every outcome to success or failure.

PFMI distinguishes settlement money, finality and linked obligations. These principles help frame questions about a payment route, without certifying a consumer stablecoin service. BIS: PFMI

Common misconceptions

“Confirmed onchain means the merchant has bank money.” That is true only if the agreed route ends at that token confirmation; external conversion can remain.

“One stablecoin always equals one spendable currency unit.” Price, fees, eligibility and redemption conditions need evidence.

“No response means resend.” An uncertain operation may already have completed.

Risks and limits

No current fee, redemption promise, transfer speed or jurisdictional availability is asserted. This lesson excludes real sanctions screening, account access, tax and financial execution. Reading official monetary research is not a direct payment test. Real routes require current primary terms and a precise allocation of shortfall and failure risks.

Exercise and answer

Exercise: The token transfer confirms, but the bank receipt is still missing. Under the stated invoice condition, may the payer mark the merchant paid?

Answer: Not yet. Record the confirmed token step and unresolved downstream payment. Reconcile the recipient's 995 receipt before asserting the agreed completion condition.

Related learning

Continue in the payments track with deposit structures and card types. Apply the five-question framework in Research.

Source map

bis-tokenised-deposits: BIS international monetary research, 2023-04-11. bis-pfmi: international infrastructure principles, 2012. Both were actually read by the source-analysis role on 2026-10-18. The invoice, fee route, values and timing labels are original teaching assumptions, not product terms or performance evidence.