> ## 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 payins and payouts work

> Understand how Stablecoin Payins and Stablecoin Payouts work on Circle Mint, including payment intents, recipient management, refunds, and regional availability.

Circle Mint exposes two products for moving USDC and EURC onchain with external
counterparties. 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 Mint balance to a third-party recipient at
a wallet address you register. These products were formerly the Crypto Deposits
API and Crypto Payouts API.

<Note>
  Stablecoin Payins and Stablecoin Payouts require explicit activation on your
  Circle Mint account, separate from base Circle Mint access. To request access,
  contact Circle through the
  [Circle Mint contact form](https://www.circle.com/mint-contact).
</Note>

## 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 as of April 2, 2026.

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 Mint 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: <br> payment intent status (pending), <br> 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: <br> payment status (paid)
    M-->>S: Sends notification (transient intents only): <br> 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 Mint 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 Mint 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: <br> 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](/circle-mint/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 Mint 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](/circle-mint/howtos/refund-stablecoin-payin).

## Chain support

Stablecoin Payins supports a narrower set of blockchains than Stablecoin
Payouts. The two lists diverge because deposit-address provisioning and
recipient delivery have different operational requirements. For the
authoritative list of supported blockchains and currencies for each product, see
[Supported Chains and Currencies](/circle-mint/references/supported-chains-and-currencies).

## Regional availability

Stablecoin Payouts is available through both Circle's U.S. entity (Circle LLC)
and Circle's Singapore entity (CIRCLE\_SG) as of April 7, 2026. Payouts booked
through Circle Singapore have additional Travel Rule data requirements described
in [Travel Rule Compliance](/circle-mint/references/travel-rule-compliance).

<Note>
  Stablecoin Payins is currently launched in the Americas through Circle LLC.
  Other regions are not yet supported for inbound stablecoin payments.
</Note>

## 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 applies 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).
