Skip to main content

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.

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.
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.

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.
ContinuousTransient
Amount at creationOmitted. You set currency and settlement.You set a fixed amount.
Deposit addressSame address can receive multiple transfers.Tied to one checkout; not reused after settlement.
How you select itOmit type (default) or set type to continuous.Set type to transient.
Intent lifecycleStays at active. Never advances to complete on its own.Advances to complete after a transfer settles, with context paid/underpaid/overpaid.
paymentIdsNot 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. 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.

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.
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 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.

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.

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.
Stablecoin Payins is currently launched in the Americas through Circle LLC. Other regions are not yet 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 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.