A business can accept a stablecoin payment by generating a payment instruction, receiving the customer’s transfer on a supported chain and matching the settled transaction to an order. The difficult part is not displaying a wallet address. It is controlling the asset and network, screening the recipient flow, handling underpayments and refunds, and reconciling an onchain transfer with the business ledger.
Circle’s current Stablecoin Payments documentation provides one concrete implementation model for USDC and EURC. It is not the only architecture, and its product availability depends on the customer’s booking entity and onboarding.
Start with the operating model
There are two broad choices.
In a self-managed flow, the business or its payment provider creates the checkout, monitors the blockchain payment and holds the resulting stablecoins. Circle’s Stablecoin Payments APIs, for example, create payment intents and deposit addresses while leaving treasury and conversion decisions with the customer.
A managed flow moves more of the custody, compliance and settlement work to the provider. Circle describes Managed Payments as a separate, turnkey product, with its own invitation and onboarding requirements. It should not be treated as an automatic feature of every Circle account.
The choice changes who holds customer funds, who screens addresses, who manages private keys, what records are available and how refunds are executed. A checkout design should name those responsibilities before the first payment is accepted.
Create a payment intent for the order
A payment intent ties an expected payment to a business event such as an order, invoice or account credit. In Circle’s payin flow, the business creates an intent and receives deposit instructions. The customer transfers the specified stablecoin to the assigned address, and the business follows the status through webhooks or API requests.
Circle distinguishes two intent types:
- A transient intent expects a target amount. It can settle as paid, underpaid or overpaid.
- A continuous intent has no target amount and can remain available for repeated deposits.
A checkout normally needs the transient model because an order has a price. A continuous address can fit account funding, but the business still needs a separate method to identify who made each deposit and what balance should receive the credit.
The payment instruction must specify the asset, chain, destination address and amount. “Send USDC” is incomplete when the provider supports USDC on several networks.
Control the supported asset and chain
Stablecoins with the same ticker on different chains are separate onchain assets. A business should show only the combinations its provider can detect and settle.
Circle publishes a supported-chain matrix and notes that payins and payouts do not necessarily support the same set of networks. That difference matters when a business wants to receive funds on one chain and pay a supplier on another. The product documentation should be checked at implementation time and again when adding a network.
The checkout should also distinguish native assets from bridged versions. A provider that supports native USDC on a chain may not credit a different token that uses a similar name or symbol.
For the broader routing decision, see Choosing a Network for Stablecoin Transfers. The same questions about finality, token support and destination compatibility apply to a merchant checkout.
Wait for settlement, not just submission
A wallet can show a transaction hash before the payment is final enough for the business to fulfill an order. The provider’s settled status should drive fulfillment.
Circle’s flow uses webhooks and API status checks to report the intent’s progress. A business should make webhook processing idempotent, because delivery can be retried. It should also retain a way to query the authoritative status when a webhook is delayed.
Underpayment and overpayment need explicit rules. If a transient intent settles below the requested amount, the business must decide whether to request the remainder, refund the payment or cancel the order. An overpayment cannot simply disappear into a generic balance without a reconciliation record.
The business ledger should connect the order ID, payment-intent ID, destination address, asset, chain, transaction identifier, amount received, provider fees and settlement timestamp. That record is what lets support and finance teams resolve a dispute later.
Design the refund path before launch
An onchain transfer cannot be reversed in the way a card authorization can be voided. A refund is a new transfer initiated by the business or provider.
Circle’s current Stablecoin Payments documentation says refunds are available after a payment has settled and within 30 days of the payment intent’s creation. It also permits partial refunds, subject to account limits. Once a transient intent is refunded, it stops accepting new payins.
Those are product-specific rules, not universal stablecoin rules. Another provider can have a different time window, approval process, supported destination or fee schedule.
A refund policy should state which asset is returned, who pays network fees and how the destination address is verified. Sending funds to an address supplied through a compromised support conversation creates a new loss even when the original checkout was correct.
Check screening and data requirements
A stablecoin payment route can involve sanctions screening, wallet-risk controls, customer identification, transaction monitoring and Travel Rule data. The exact obligations depend on the business, provider and jurisdictions involved.
In Circle’s payout model, recipients are registered and screened through the Address Book. The documentation also describes Travel Rule information requirements that vary by entity and threshold. Those controls are part of the payout flow, not evidence that every possible counterparty or transaction is permitted.
Product availability also needs a fresh check. Circle’s current concept page lists payin availability in the Americas, while the payin how-to also lists the EEA. Because those pages differ, a business should confirm the applicable booking entity and enabled regions with Circle before treating the feature as available.
This is a place for a documented eligibility check, not an inferred answer from an account dashboard or marketing page.
Decide what happens after settlement
Receiving stablecoins is only the first treasury decision. The business may hold them, use them for supplier payments, transfer them to another account or redeem them for bank money.
Each route has separate costs and timing. Network fees, provider fees, conversion spreads and bank payout charges can matter more than the initial transfer fee. Our guide to the full cost of a cross-border stablecoin payment separates those components.
If the payment covers a supplier invoice, Paying Suppliers in Stablecoins explains why the invoice agreement and accounting record must match the token transfer.
A minimum implementation checklist
Before launch, a business should be able to answer these questions:
- Which legal entity provides the service, and where is the product available?
- Which stablecoins and chains are accepted for payins?
- Does each order receive a unique intent or deposit address?
- Which status authorizes fulfillment?
- How are delayed, duplicate, underpaid and overpaid transactions handled?
- What is the refund window, and how is the refund address verified?
- Which screening and Travel Rule data does the provider require?
- How are transactions matched to orders and accounting entries?
- What happens to the stablecoins after settlement?
- Which fees apply at each stage?
A provider API can automate several steps. It does not choose the business’s refund policy, revenue recognition, customer-support procedure or treasury strategy.
