How to Send Circle Stablecoin Payouts in USDC and EURC

Circle published a Sept. 12, 2026 guide describing how to send Stablecoin Payouts in USDC and EURC from Circle Mint accounts. The guide covers product activation, the address-book recipient lifecycle, API calls to submit payouts, and entity-specific Travel Rule requirements for Circle LLC, Circle Singapore (CIRCLE_SG) and Circle France (CIRCLE_FR).

The guide says Stablecoin Payouts must be explicitly enabled on a Circle Mint entity and require a funded source wallet and an API key. The product is intended for third-party recipients; transfers to wallets the business owns should use Transfer Onchain or the Core API. Destinations must be on a supported chain. For XRP destinations the guide requires a classic address plus an addressTag and notes that x-address format is not supported. For CIRCLE_SG and CIRCLE_FR, recipients must use a hosted VASP wallet; self-hosted destination wallets are not supported on those entities as of Sept. 12, 2026.

To register a recipient the guide directs clients to call POST /v1/addressBook/recipients with at minimum an idempotencyKey, chain and address. On Circle LLC identity and ownership are optional for creating a basic recipient. On CIRCLE_SG and CIRCLE_FR beneficiary identity and ownership must be included on creation and ownership.custody.vaspId must match a VASP returned by GET /v1/addressBook/vasps. New recipients start in a pending state and move to active. If the Mint Console option Delayed withdrawals is ON, new recipients remain inactive for 24 hours. The guide recommends subscribing to addressBookRecipients webhooks or polling GET /v1/addressBook/recipients/{id} until status is active. It also notes that identity and ownership fields cannot be modified with PATCH and that errors 2036 and 2037 require creating a new recipient.

To submit a payout the guide directs use of POST /v1/payouts with the source wallet id, the address-book recipient id as destination, amount and toAmount. Circle LLC requires inclusion of source.identities[] when a payout equals or exceeds $3,000 USD-equivalent. CIRCLE_SG and CIRCLE_FR require Travel Rule data on every payout and require a purposeOfTransfer payment-reason code in the PMT000–PMT030 range except PMT006; missing or invalid PMT codes commonly return synchronous 5020 errors. Sandbox examples include illustrative network fee values but note that production fees vary.

Confirmation should come via payouts webhooks or by polling GET /v1/payouts/{id} until status is complete. The guide groups failures into synchronous HTTP 4xx responses that require fixing the request body and retrying, and asynchronous accepts (HTTP 201) that later flip to failed and require resubmission with a new idempotencyKey. Common async failure signals include transaction_denied with reason 3220 when Travel Rule data is missing or invalid, and insufficient_funds when the source wallet lacks funds for amount plus fees. Address-book validation errors 2024–2037 indicate identity, ownership or vaspId issues and the guide states that errors 2036 and 2037 require recreating the recipient.

The guide advises testing in sandbox, registering and validating one recipient before moving to production, accounting for delayed-withdrawals timing, and building error handling for codes 3220, 5020, insufficient_funds and 2024–2037.