How to Mint and Redeem USDC With Circle Mint in 2026

Circle’s 2026 guide explains wiring fiat to a linked bank to mint USDC, sending onchain to allowlisted addresses, and redeeming remaining USDC back to fiat via wire payouts.

Circle’s 2026 documentation outlines the end-to-end process institutional customers use to mint USDC, move it onchain and redeem any remaining balance to fiat. The guide covers sandbox testing and production operations and lists the API endpoints operators must call to complete the loop.

The guide assumes teams already have a Circle Mint account and API keys. It separates account opening and API-key setup from the mint-and-redeem workflow and references specific businessAccount and payouts endpoints for the operational loop.

The first step in the flow is registering a wire-capable bank account with POST /v1/businessAccount/banks/wires and saving the returned bank id. That bank id becomes the destination for later wire payouts and the key used to request wire instructions.

Operators then call GET /v1/businessAccount/banks/wires/{id}/instructions to retrieve wire instructions. The response includes a tracking reference and, when enabled, a Virtual Account Number (VAN) in beneficiaryBank.accountNumber. When virtualAccountEnabled is true the VAN can be used as the beneficiary account number and the tracking reference in the wire memo becomes optional. When it is false the sender must include the tracking reference in the wire memo so Circle can match the deposit.

To mint USDC, teams deposit fiat. In sandbox the deposit is simulated with POST /v1/mocks/payments/wire; sandbox mock deposits are batched and can take up to 15 minutes to process and do not touch production rails. In production operators must originate a real wire from their bank using the exact instructions returned by the API. Circle documents same-day settlement for domestic wires that meet cutoffs and one to three business days for many international wires. After settlement, teams verify the minted balance with GET /v1/businessAccount/balances.

Outbound onchain transfers require creating an allowlisted recipient with POST /v1/businessAccount/wallets/addresses/recipient and saving the returned address id. The transfer is then created with POST /v1/businessAccount/transfers using destination.type verified_blockchain and the addressId. The guide notes Circle covers gas for standard outbound USDC sends in most cases. Transfers at or above $3,000 may trigger Travel Rule processing and use the company identity on file for compliance messaging. Customers in France and Singapore must complete an additional recipient verification step in the Mint Console before outbound transfers will process.

To redeem USDC to fiat, teams create a wire payout with POST /v1/businessAccount/payouts where destination.type is wire and destination.id is the bank account id used earlier. Payouts move through pending and complete states; bank-side rejects return funds to the Mint balance. The documentation recommends subscribing to payouts webhooks or polling the payout status rather than assuming settlement timing.

The guide highlights common operational pitfalls. Sandbox mock wires do not reflect production wire behavior. Production wires must match beneficiary names, account numbers and routing numbers byte-for-byte to avoid rejects or multi-day delays. If virtualAccountEnabled is false and the tracking reference is omitted, Circle may not match the deposit. Operators must keep idempotency keys unique to avoid accidental duplication when retrying API calls. Failed or returned payouts should be treated as operational incidents and monitored until funds are confirmed returned.

Circle frames the businessAccount banks, balances, transfers and payouts endpoints as the standard mint-and-redeem loop for USDC and EURC. The documentation recommends testing the flow in sandbox and verifying bank templates match live instructions before initiating production wires.

Articles by this author