<!-- tempo-docs-context -->
> Source: [/docs/resources/guides/how-to-accept-stablecoin-payments](https://tempo.xyz/developers/docs/resources/guides/how-to-accept-stablecoin-payments.md)
> Section: [Get Started](https://tempo.xyz/developers/get-started.md). Choose a starting point, send a test payment, get testnet funds, connect a coding agent, find the SDKs and CLI, and use the resource guides to plan payment workflows, liquidity, provider selection, and partner integrations.
> [Documentation index](https://tempo.xyz/developers/llms.txt) · [Docs skill](https://tempo.xyz/developers/SKILL.md)

> Tempo MCP: Use `search`, `find_pages`, `read_page`, and `code` at `https://mcp.tempo.xyz` for Tempo and related documentation.
> If an indexed page is missing or reflects an older site, read this site’s [documentation index](https://tempo.xyz/developers/llms.txt) and Markdown pages directly.

[Guides](https://tempo.xyz/developers/docs/resources/guides) / [Payment workflows](https://tempo.xyz/developers/docs/resources/guides#payment-workflows) / Plan stablecoin payment acceptance

# Plan stablecoin payment acceptance

To accept stablecoin payments, give the customer the correct network, token, receiving address, amount, and payment reference. Verify the delivered transfer before updating an invoice or fulfilling an order. Follow the [Receive payments guide](https://tempo.xyz/developers/docs/guide/payments/accept-a-payment) for implementation, then use this checklist to connect it to your B2B checkout and finance workflow.

Stablecoin payments can operate alongside ACH and wires. Tempo supplies the onchain settlement layer; your application or provider supplies checkout, customer records, custody controls, and any bank funding or payout steps.

## Define the payment and integration model

Choose one initial flow, such as invoice collection, marketplace deposits, or funding an embedded account. Decide whether your application receives stablecoins directly or relies on a provider for funding, custody, conversion, and reporting.

| Decision | Establish before accepting funds |
| --- | --- |
| Recipient outcome | Retain the stablecoin, convert to another supported token, or request a provider bank payout. |
| Asset | Specify the token contract and network. Use the [token guide](https://tempo.xyz/developers/docs/guide/ousd) and [token list](https://tempo.xyz/developers/docs/quickstart/tokenlist). |
| Custody and signing | Identify who controls the receiving account and authorizes withdrawals or refunds. |
| Payment controls | Decide which senders and tokens are eligible and how exceptions are reviewed. |
| Finance integration | Define the invoice, event, and ledger records that establish a completed payment. |

Direct integrations use the [Tempo SDK](https://tempo.xyz/developers/docs/sdk) and read onchain transfer events. A receiving account does not need to call an API to accept each ordinary transfer. Provider-led integrations can expose higher-level payment APIs or a hosted interface.

## Configure accounts, assets, and fees

[Token policies](https://tempo.xyz/developers/docs/protocol/tip403/overview) enforce issuer-defined transfer rules. [Account receive policies](https://tempo.xyz/developers/docs/accounts/policies/receive-policies) control which receipts an account accepts. Identity checks, screening decisions, and payment approvals stay in your application.

If you need customer-specific destinations, [customer deposit addresses](https://tempo.xyz/developers/docs/guide/payments/virtual-addresses) can attribute incoming funds while crediting a shared account. They don't create separate onchain customer balances; your application keeps that ledger.

Use the [Stablecoin DEX](https://tempo.xyz/developers/docs/guide/stablecoin-dex/executing-swaps) if you need to convert a delivered stablecoin. Quote the actual amount and verify the output. Two supported tokens don't always convert at par or have enough liquidity for the payment.

Tempo charges [network fees](https://tempo.xyz/developers/docs/protocol/fees) in eligible stablecoins, subject to fee-token and Fee AMM liquidity requirements. Your application does not need to acquire a separate gas token. [Fee sponsorship](https://tempo.xyz/developers/docs/guide/payments/sponsor-user-fees) lets your application pay transaction fees. Include provider, conversion, and bank-delivery charges when calculating the complete payment cost.

## Build a payment request that finance can reconcile

A payment link, QR code, or invoice should state which network and token to use, where to send it, how much is due, and which reference identifies the order. The checkout interface belongs to your application or provider. Test that customer wallets preserve the requested reference.

Follow [Create payment links](https://tempo.xyz/developers/docs/resources/guides/payment-links) to store trusted request terms, share a link or QR code, and recover an interrupted checkout.

| Request field | What to establish before sharing it |
| --- | --- |
| Network and asset | Specify Tempo and the accepted token contract, not only a ticker. |
| Recipient | Use an account you control or a supported customer deposit address. |
| Amount | Store the expected amount and token precision in the payment system. |
| Reference | Assign a short, unique ID that maps to an invoice or order in your database. |
| Payment terms | Define expiry, partial payments, overpayments, and the refund process. |

For an invoice requesting 1,000 USDC.e on Tempo, use `INV-2048` as the reference. Customer details, purchase orders, and billing information stay in your database. If the wallet cannot supply a memo, consider customer deposit addresses for attribution.

[Transfer memos](https://tempo.xyz/developers/docs/guide/payments/transfer-memos) hold a 32-byte reference. The limit is bytes, not characters, and memos are public transaction data. Use the same encoding when requesting a reference and matching incoming events.

## Verify delivery before fulfilling an order

Fulfill an order only after you verify the network, token contract, recipient, amount, successful receipt, and delivered transfer events, as the [receiving guide](https://tempo.xyz/developers/docs/guide/payments/accept-a-payment#match-payments-to-customers) describes. A receive policy can hold funds instead of delivering them to the intended recipient.

Store the network, transaction hash, and transfer log index as a unique event key. Record the event and update the invoice in one database transaction so a repeated notification cannot credit the customer twice. Recover missed activity after a connection interruption and follow pagination through historical records.

Route underpayments, overpayments, expired requests, and missing references to an exception queue. A shared transaction hash can contain several transfers; a balance increase doesn't identify an invoice.

## Treat refunds as a separate payment

A merchant refund is a new outbound transfer linked to the original payment. Verify the destination independently; an exchange or shared wallet's sending address may not credit a return to the customer.

Follow [Handle stablecoin refunds](https://tempo.xyz/developers/docs/resources/guides/refunds) to reserve partial amounts, prevent concurrent over-refunds, and resolve uncertain submissions. For Routes provider returns, follow the [delivery and refund states](https://tempo.xyz/developers/docs/routes/delivery).

## Test the complete acceptance flow

:::steps
### Verify the testnet payment path

Use the test token and network named in the implementation guide. Confirm the correct token, amount, recipient, memo, and receipt before marking a test invoice paid.

### Exercise payment exceptions

Test repeated notifications, missed events, wrong assets, partial payments, blocked receipts, refund requests, and unresolved submissions.

### Connect the finance close

Check that each delivered payment maps to one invoice and ERP record, with fees recorded separately. Define who investigates exceptions and what evidence closes them.
:::

## Payment acceptance questions

### Do stablecoin payments replace ACH and wires?

No. Keep those methods where they fit the workflow. Stablecoins add an onchain rail with separate funding, conversion, and delivery responsibilities.

### What does a B2B company need to accept stablecoin payments?

Define the payment flow, account model, asset, controls, finance integration, and exception process. Then build it directly or through a provider.

### Can an application sponsor network fees?

Yes. Configure fee sponsorship and monitor the sponsor's balance and fee-token availability. Sponsorship changes who pays network fees; it doesn't remove them.
