> ## Documentation Index > Fetch the complete documentation index at: https://developers.circle.com/llms.txt > Use this file to discover all available pages before exploring further. # How stablecoin payments work > Understand how Stablecoin Payins and Stablecoin Payouts work in Circle Payments Network, including payment intents, recipient management, refunds, and regional availability. Stablecoin Payments in Circle Payments Network (CPN) covers two products for moving USDC and EURC onchain with external counterparties: Stablecoin Payins and Stablecoin Payouts. Stablecoin Payins accepts USDC or EURC sent from an external wallet to a deposit address that Circle assigns to your account. Stablecoin Payouts sends USDC or EURC from your Circle balance to a third-party recipient at a wallet address you register. Stablecoin Payins and Stablecoin Payouts require explicit activation on your Circle account, separate from base Circle Mint access. To request access, contact Circle through the [Circle Mint contact form](https://www.circle.com/mint-contact). ## Payment intents A payment intent is a first-class API object that represents a single agreement to receive funds onchain. The intent bundles the settlement currency, the allowed blockchains, and a deposit address that Circle assigns asynchronously after creation. Your server creates the intent, displays the address to the payer once Circle returns it, and observes settlement events as inbound transfers arrive. Each transfer that settles against an intent produces a `payments` resource. Payments and refunds share that single resource, discriminated by `type`, so your integration listens to the same notification channel for both inbound and outbound activity tied to an intent. The intent's lifecycle depends on its mode. A transient intent has a target amount, so it moves through `created`, `pending`, `complete`, `expired`, `failed`, and `refunded` states; when it reaches `complete`, the latest timeline entry carries a context of `paid`, `underpaid`, or `overpaid`. A continuous intent has no target amount, so it stays at `active` after Circle assigns the deposit address and never advances to `complete` on its own. To reconcile settled transfers against a continuous intent, listen to the `payments` webhook or call `GET /v1/payments?paymentIntentId={id}`; the intent's own `paymentIds` array is only populated for transient intents. ### Continuous and transient modes A payment intent operates in one of two modes. Continuous mode produces a long-lived deposit address that can receive multiple transfers over time, which suits recurring billing, treasury top-ups, or any flow where a payer needs to send funds more than once. Transient mode produces an address scoped to a single checkout: you declare the expected amount up front, and the address is not intended for reuse after that one payment settles. Continuous is the default behavior. The following table compares what you send when creating each type of intent and how the resulting deposit address behaves. | | Continuous | Transient | | ------------------ | --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | Amount at creation | Omitted. You set `currency` and settlement. | You set a fixed `amount`. | | Deposit address | Same address can receive multiple transfers. | Tied to one checkout; not reused after settlement. | | How you select it | Omit `type` (default) or set `type` to `continuous`. | Set `type` to `transient`. | | Intent lifecycle | Stays at `active`. Never advances to `complete` on its own. | Advances to `complete` after a transfer settles, with context `paid`/`underpaid`/`overpaid`. | | `paymentIds` | Not populated on the intent. Use the `payments` webhook or `GET /v1/payments?paymentIntentId={id}`. | Populated when the intent reaches `complete`. | For continuous intents, every inbound transfer is recorded as its own payment against the same intent. For transient intents, the single deposit address is tied to one checkout or invoice and should not be reused after the payment settles. ## Payin flow A stablecoin payin moves through four logical stages: the customer signals intent to pay, Circle assigns a deposit address, the customer transfers funds onchain, and Circle notifies your server when the payment settles. The following diagram illustrates the actors involved and the order of operations. ```mermaid theme={null} sequenceDiagram participant C as Customer participant W as Customer-facing UI participant S as Your server participant M as Circle APIs Note over C,M: Create payment intent C->>W: Chooses to pay with stablecoins on a blockchain W->>S: Requests onchain deposit S->>M: Sends payment intent creation request M-->>S: Sends payment intent Note over C,M: Send and display deposit address M-->>S: Sends notification containing:
payment intent status (pending),
deposit address S->>W: Sends deposit address W->>C: Displays deposit address Note over C,M: Customer pays onchain and Circle notifies your server C->>M: Transfers funds to deposit address M-->>S: Sends notification containing:
payment status (paid) M-->>S: Sends notification (transient intents only):
payment intent status (complete) Note over C,M: Confirm payment to customer S->>W: Sends payment confirmation W->>C: Displays payment confirmation ``` For continuous intents, only the `payments` notification fires; the intent itself does not transition to `complete`. Use the `payments` webhook (or list payments with `GET /v1/payments?paymentIntentId={id}`) to reconcile settled transfers against a continuous intent. ## Payout flow A stablecoin payout moves from your Circle balance to a registered recipient address in three logical stages: you register the recipient, you create the payout, and Circle delivers funds onchain. The following diagram shows the actors and order of operations. ```mermaid theme={null} sequenceDiagram participant S as Your server participant M as Circle APIs participant R as Recipient wallet Note over S,M: Create address book recipient S->>M: Sends create address book recipient request M-->>S: Sends address book recipient Note over S,M: Create payout S->>M: Sends create payout request M-->>S: Sends payout (pending) Note over M,R: Onchain delivery M->>R: Transfers USDC or EURC to registered address Note over S,M: Payout complete M-->>S: Sends notification containing:
payout status (complete) ``` ## First-party versus third-party transfers Stablecoin Payouts is always a third-party flow: the destination wallet belongs to a merchant, vendor, contractor, customer, or other counterparty outside your business. If you need to send USDC or EURC to a wallet that your own business controls, such as a treasury wallet or a self-custody address, use the Core API instead. The following table summarizes when each path applies. | Use Stablecoin Payouts when… | Use the Core API when… | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | You're paying a third party, such as a vendor, contractor, marketplace seller, remittance recipient, or end customer. The address belongs to someone other than your business and requires recipient review. | You're moving funds to a wallet your business owns or controls, such as a treasury wallet or self-custody address. See [Transfer USDC Onchain](/circle-mint/howtos/transfer-on-chain). | The two paths use different APIs and have different compliance treatments; choosing the right one matters for both operational behavior and Travel Rule applicability. ## Address book and recipient lifecycle Every Stablecoin Payouts destination must be registered through the Address Book API before you can send funds to it. Registration is per recipient, not per payout, so once a recipient is active you can send additional payouts to the same address without re-registering. A recipient moves through the following lifecycle: * `pending`: Circle is reviewing the recipient. * `inactive`: The recipient is in the delayed withdrawals holding period. This state appears for 24 hours when the **delayed withdrawals** toggle is on in the Circle Mint console; otherwise recipients skip this state. * `active`: The recipient is ready to receive payouts. * `denied`: The recipient failed review and cannot receive payouts. Procedural details, including the API request to register a recipient, live in the [Send a stablecoin payout](/cpn/stablecoin-payments/howtos/send-stablecoin-payout) how-to. ## Refunds Refunds let you return funds against a payment intent that has already received at least one settled payment. The following constraints define the refund window: * You can start a refund only after at least one payment on the intent has completed and settled. You cannot refund a pending payment. * Refunds are available for 30 days from the intent's creation date. In that window you can issue more than one partial refund, up to your Circle account limits. * Once a refund is initiated, the payment intent transitions to `refunded` and stops accepting new payins. Treat the intent as terminal at that point and create a new intent for any future checkout. For the refund procedure, see [Refund a stablecoin payin](/cpn/stablecoin-payments/howtos/refund-stablecoin-payin). ## Blockchain support Stablecoin Payins and Stablecoin Payouts support USDC and EURC on a defined set of blockchains. For the authoritative list of supported blockchains and currencies, see [Supported blockchains](/cpn/stablecoin-payments/references/supported-blockchains). ### Memo-based blockchains Some blockchains identify the destination with a memo or tag in addition to the address. For Stellar (`XLM`) and Hedera (`HBAR`), a payment intent's deposit address includes an `addressTag`. If the payer's wallet enforces memos, they must include this tag when they send funds. For XRPL (`XRP`) payout destinations, Stablecoin Payouts supports only the classic-address format, such as `rPEPPER7kfTD9w2To4CQk6UCfuHM9c6GDY`. The x-address format is not supported. Use the `addressTag` field to specify the destination tag. ## Regional availability Stablecoin Payouts is available through Circle's U.S. entity (Circle LLC), Circle's Singapore entity (`CIRCLE_SG`), and Circle's France entity (Circle SAS, `CIRCLE_FR`). Payouts booked through Circle Singapore or Circle SAS have additional Travel Rule data requirements described in [Travel rule compliance](/circle-mint/references/travel-rule-compliance). Payouts booked through Circle SAS fall under the EU Transfer of Funds Regulation and can include an optional legal entity identifier (LEI) on beneficiaries. Stablecoin Payins is available in the Americas through Circle LLC. Other regions are not supported for inbound stablecoin payments. ## Travel Rule Third-party stablecoin payouts that exceed certain thresholds require Travel Rule data on the sender and the recipient, including originator and beneficiary identities and, where applicable, Virtual Asset Service Provider (VASP) information. Circle LLC applies Travel Rule to payouts of \$3,000 USD-equivalent or more, while Circle Singapore (under MAS PSN02) and Circle SAS (under the EU Transfer of Funds Regulation) apply it to every third-party payout regardless of amount. For the complete reference, including identity schemas, payment reason codes, and VASP handling, see [Travel rule compliance](/circle-mint/references/travel-rule-compliance).