How to send a BlindPay stablecoin payout in 2026

BlindPay’s operator documentation sets out a three-step process for converting stablecoins to fiat and sending bank payouts. Operators must add and approve the recipient bank account, create a single-use payout quote that locks the exchange rate and fees for five minutes, then execute the payout so stablecoins leave the funding wallet and fiat lands in the recipient bank account.

The bank account step requires storing an approved bank account identifier in BlindPay’s system. Every subsequent quote and payout references that bank account identifier. Operators should confirm the bank account has an approved status before creating quotes.

A payout quote is created through BlindPay’s quotes endpoint. The quote response provides a quote_id, an expires_at timestamp five minutes after creation, and a breakdown of sender_amount, receiver_amount and flat_fee. request_amount is an integer in minor units (for example, 10000 represents $100.00); decimal floats are rejected. cover_fees is set on the quote and cannot be changed after authorization. If a quote expires or is already used, a new quote is required.

Execution depends on the funding source. For BlindPay custodial managed wallets, no on-chain signing is required: operators provide the managed wallet address with the quote_id to the payouts endpoint and BlindPay processes the conversion. For external wallets, operators must perform an authorization step specific to the blockchain. For EVM chains including Ethereum, Base, Polygon and Arbitrum, operators call approve on the ERC-20 token contract for the amount supplied in the quote. Stellar requires calling an authorize endpoint to receive an unsigned XDR, signing it with a Stellar SDK, submitting it to Horizon, and posting the signed transaction back to BlindPay. Solana requires preparing and signing a per-payout token delegation before creating the payout. BlindPay’s tutorials use testnets and the USDB test token for development; production instances use mainnet networks and USDC or USDT according to the provider matrix.

BlindPay supports multiple bank rails: ACH, wire and RTP for U.S. payouts, SWIFT for international transfers, Brazil’s Pix, Mexico’s SPEI, Argentina transfers_bitso, Colombia ach_cop_bitso, and SEPA for Europe. The payouts reference documents list minima for some rails: SWIFT requests must be at least $100, and SEPA quoting shows a minimum equivalent of 11 USDB when quoting by sender amount or 10 EUR when quoting by receiver amount. Not every BlindPay instance has every rail or chain enabled; operators should confirm instance capabilities before launching in production.

Payouts emit webhooks for lifecycle tracking. Operators should subscribe to payout.new, payout.update and payout.complete. Top-level payout statuses include processing, on_hold (used for compliance review on many rails including all SWIFT and typically ACH, wire and RTP), completed, failed and refunded. BlindPay’s documentation states it does not automatically return stablecoins when a payout fails or becomes stuck and instructs operators to contact support rather than assuming automated refunds. Development instances provide test sentinels: specific request_amount values cause forced failed or refunded outcomes for testing.

Common operational pitfalls include authorizing against an expired quote, attempting to reuse a quote_id for multiple payouts, and hardcoding production tokens into sandbox scripts when development only accepts USDB. Managed-wallet Stellar support is limited in the current documentation; operators needing Stellar managed-wallet funding should follow the external-wallet Stellar path.

Required items before production include a BlindPay instance API key, an approved customer profile and bank account, a funded managed or external wallet on the quoted network, and a configured webhook endpoint. BlindPay’s documentation recommends testing with one development customer, one approved bank account, one funded managed wallet using USDB, and one payout.complete listener before moving to production.