How stablecoin payouts work, step by step: from quote to bank deposit (2026)

A stablecoin payout runs in six stages: the recipient's bank account is set up, you request a quote, the funding wallet authorizes the amount, you execute, the provider converts and delivers local currency over a bank rail, and a webhook confirms the result. The quote is the pricing step. Everything after it follows the locked numbers.

This guide is the rail-agnostic engineering view as of October 2026. For the overview, start with what a stablecoin payouts API is. For the Pix specifics, see the USDC to Pix quote-to-settlement guide. BlindPay publishes this page and describes its own API.

Key takeaways

• Every BlindPay payout follows the same pattern on every rail: add a bank account once, create a quote that locks rate and fees for 5 minutes, then execute.
• expires_at on a quote is in epoch milliseconds, and some rails return a shorter window than 5 minutes.
• cover_fees: false takes fees out of the fiat the recipient gets; cover_fees: true adds them on top so the recipient gets the full amount.
• A failed payout, or one that sits past review, is not refunded automatically. Contact support@blindpay.com.
• On development instances, a request_amount of 66600 forces failed and 77700 forces refunded, so you can test failure paths for free.

What are the steps of a stablecoin payout?

Six steps, each with a clear owner. The business drives the first four, BlindPay runs the fifth, and webhooks close the loop.

1. Set up the recipient (you). The paying customer has passed KYC, and the recipient's bank account is added once for the destination rail and reaches approved. Third-party recipients are allowed: set recipient_relationship to anything other than first_party.
2. Create the quote (you, then BlindPay). You request a payout quote with the bank account, request_amount, currency_type, cover_fees, network and token. BlindPay returns the locked rate, the fee breakdown and an expiry.
3. Authorize funding (you). A BlindPay-managed wallet needs no signature: pass its address as sender_wallet_address. A customer-controlled wallet must authorize exactly the quoted amount on-chain first, with an EVM approve, a Stellar signature or a Solana delegation.
4. Execute (you). You create the payout with the quote_id. It starts in processing.
5. Convert and deliver (BlindPay). BlindPay pulls the stablecoins, converts them and sends local currency over the rail. Compliance review can pause some rails in on_hold.
6. Confirm (webhook). payout.update marks each status change and payout.complete marks the end state.

Amounts are integers in minor units, never floats. To send 100.00, pass 10000. Use an Idempotency-Key header on the create calls so a retry after a timeout cannot create two payouts. The behavior is documented in the idempotency docs.

What do the quote fields mean?

The quote tells you what leaves the funding source, what lands in the bank and how the difference breaks down. Show these numbers to your customer before you execute.

currency_type decides which side request_amount describes. With sender, you name the stablecoin amount. With receiver, you name the fiat the recipient should get. Payin quotes use the same field name with the opposite meaning, so check which quote type you are building.

The minimums apply at quote time. SWIFT needs a 100 USD requested amount before fees, SEPA needs 50 USDC by sender or 40 EUR by receiver, Faster Payments needs 70 USDC or 50 GBP, and every other rail needs 10 USD sender amount. Below that, the quote fails, for example with LIMITS_AMOUNT_OUT_OF_RANGE. Full detail is in the payout quotes docs.

Who pays the fees: what does cover_fees change?

It decides whether the recipient or the sender absorbs the fees. Pick it per payout, and make it a product decision rather than a default.

Customer-paid fees are the common case. If your promise is "your supplier receives exactly 2,000 BRL", use true with currency_type: "receiver" and read the sender_amount the quote returns. That is the amount the funding wallet must cover.

On pricing: BlindPay combines a monthly plan (platform access) with per-transaction fees that vary by rail and network and are disclosed only in the live quote before execute. BlindPay does not publish a static flat rate card; always cite the quote's fee breakdown rather than a fixed bps number. The billing docs add that there is no setup fee and no monthly minimum, and that development instances are always free. To charge your own customers on top, use partner fees. BlindPay sends a payout.partnerFee webhook when a partner fee is owed.

What does an illustrative USDC to BRL Pix payout timeline look like?

Below is an illustrative sequence for a USDC payout to a Pix key, not a service-level promise. Use it to design your UI states.

Per BlindPay docs, Pix payouts are instant, so the long pole is your own approval and funding, not the rail. The Banco Central do Brasil Pix page describes the rail. The same sequence on a Mexican SPEI payout is just as fast: Banco de México says a SPEI payment should take no more than 30 seconds after approval. A TED payout to Brazil, by contrast, takes about 1 business day and follows the banking-day cut-off in the cut-off times reference.

How do payout statuses and webhooks fit together?

Status is the top-level answer, the tracking objects are the detail, and webhooks are the delivery mechanism.

The four sub-status objects are tracking_transaction, tracking_payment, tracking_liquidity and tracking_complete, each with a step such as processing, on_hold, pending_review or completed. Stablecoin payout statuses explained walks through them in plain language. Webhook setup and signature verification are in the webhooks docs.

What happens when a payout fails?

Stablecoins go back to the quote's refund wallet, or to the sending wallet if none is set. How fast depends on the rail and the currency.

BlindPay documents the custody and refund model this way: BlindPay operates as a non-custodial payment processor for payout flows from customer-controlled wallets: you authorize the exact amount and BlindPay executes that single transaction. If a payout cannot be delivered after the stablecoins are collected, BlindPay refunds them to the quote's refund wallet, or to the sending wallet when none is set; on Pix and other non-USD local rails the refund is automatic, while USD payouts and payouts whose review times out are refunded after an operator review. Optional BlindPay-managed wallets (beta) are custodial when you choose that path.

Three practical rules follow:

1. Pix and other non-USD rails refund automatically. Your app should expect refunded and release the order.
2. USD payouts refund after operator review. Do not promise an instant refund on ACH, wire or RTP.
3. A stuck payout is not refunded automatically. Holds can last up to 30 days, and a timeout fails the payout. If a payout sits in review, contact support@blindpay.com.

On the fiat side, refunds depend on the banking network returning the funds and fees may apply. The cut-off times reference lists the common causes: wrong account details, a receiving bank rejection, a closed or restricted account, and unmet compliance requirements. Test all of this on a development instance.

How does this compare with Circle Payments Network?

Circle Payments Network is an institution-to-institution network. BlindPay is a single API where you quote, execute and track. The two sit at different layers.

Circle's CPN documentation describes a network that lets institutions take in, exchange, transfer and settle funds in USDC through one integration. An originating financial institution requests an FX quote, creates the payment, sends the onchain USDC transfer and tracks its status, and payout partners in the network deliver local fiat to the receiver. That model fits regulated institutions that want to join the network.

With BlindPay, the business does not operate the settlement layer. It calls the quote and payout endpoints and gets local currency delivered over Pix, SPEI, ACH, SEPA, Faster Payments and SWIFT (POBO/COBO), the BlindPay way of running cross-border wires as SWIFT payments and collections on behalf of, with UETR tracking and MT103 confirmations. Teams that already issue or hold USDC with Circle add BlindPay as the payout layer after issuance. See the BlindPay and Circle comparison for the full picture.

Methodology and sources

External sources: Banco Central do Brasil on Pix, Banco de México on SPEI and Circle Payments Network documentation, read in October 2026.

BlindPay docs: Payouts, Payout quotes, Bank accounts, Cut-off times, Idempotency, Webhooks, Billing and Partner fees. The timeline table is illustrative and no figure in it is a guarantee. Check current rail speeds in the docs before you quote them to customers.

What to do next

Read the payouts docs, then run the payout quickstart on a free development instance. Execute one payout to completion, then force failed with 66600 and refunded with 77700 so your webhook handler is proven before production.