Stablecoin Payment Lifecycle Record

Stablecoin Payment Lifecycle Record

Lifecycle boundary

A stablecoin payment can contain customer eligibility, wallet connection, asset selection, network selection, quote, address creation, signing, broadcast, chain confirmation, processor recognition, screening, merchant credit, conversion, payout, reconciliation, refund, and support.

The token transfer is only one layer. The payer may first need an on-ramp. The merchant may want a fiat balance or bank payout. Both can add time, cost, counterparties, and regulatory duties.

Current Stripe example

Stripe's current stablecoin-payment documentation says customers connect a wallet on Stripe's hosted crypto surface. Supported payments settle into the merchant's Stripe balance in USD.

The documentation currently limits acceptance to eligible businesses, lists supported assets and networks, caps the transaction amount, supports full and partial refunds, does not support manual capture, and states that disputes do not become chargebacks.

Refunds return stablecoins to the original wallet. Deposit-mode documentation warns that a refund to an exchange or omnibus sending address may be unrecoverable by the customer. This demonstrates why refund destination is an operational control.

Meanings of settlement

On-chain confirmation means a network accepted the transaction under its protocol and confirmation policy.

Processor credit means the provider recognized the payment and credited an internal merchant balance.

Conversion means the asset was exchanged into another stablecoin or fiat currency.

Bank payout means funds reached the merchant's external account.

Final accounting means the payment, fees, conversion, payout, refund exposure, and tax treatment reconcile to the merchant's books.

Exception boundary

Wrong networks, wrong assets, incorrect amounts, stale quotes, malicious addresses, key loss, chain outages, reorganization policy, issuer redemption risk, screening holds, liquidity gaps, wallet incompatibility, and support failures require named owners and fallback paths.