What each stablecoin payout status means, which are final, why an on-chain confirmation isn't a completed payout, and how to test every failure.
A stablecoin payout moves through a small set of statuses. At BlindPay it starts as processing, can pause at on_hold for review, and ends in exactly one terminal state: completed, failed, or refunded. Your product needs a clear answer for each, because each one means something different to the person waiting for money.
Most payout bugs aren't in the happy path. They're in the states nobody designed a screen for.
These are BlindPay's statuses, from the payouts reference. Other providers use different names for the same ideas; map yours before you build.
| Status | What it means | Terminal? | What to tell the user |
|---|---|---|---|
processing | Stablecoins are being pulled from the funding source and the fiat transfer is in flight | No | "Sending." |
on_hold | Held for review | No | "Under review. No action needed unless we ask." |
completed | Fiat landed in the recipient's bank account | Yes | "Paid." |
failed | The payout did not complete, for example a rejected compliance check or a review timeout | Yes | "Didn't go through." Plus next step. |
refunded | The stablecoins returned to the funding source instead of being converted | Yes | "Returned to your balance." |
Three terminal states, and they're not interchangeable. failed and refunded both mean the recipient wasn't paid, but only refunded tells you where the money is.
Because a payout has two legs, and the blockchain only sees the first one.
The on-chain leg pulls stablecoins from the funding source. That confirms in seconds and is final. The fiat leg sends local currency to a bank account over Pix, SPEI, ACH, RTP, SEPA, or SWIFT. That takes minutes to days depending on the rail, and it's the only leg the recipient cares about.
So if your UI flips to "paid" when you see a transaction hash, you're early. Sometimes by five business days. Use completed for "paid." Timing by rail is in how long a stablecoin payout takes, and the difference between an API accepting a request and money becoming final is in stablecoin API SLAs and settlement finality.
Compliance. on_hold isn't an error. It's a review step, and for some rails it's routine:
on_hold. When the recipient isn't the sender's own account, it waits there until supporting documents are submitted and approved.on_hold as a standard step, for compliance review after the stablecoins are collected.A hold can take up to 30 days to resolve. Approval resumes the flow. A timeout without a decision fails the payout. Design the on_hold screen for days, not seconds. More in on-hold transactions.
The top-level status tells you where the payout is. The tracking_* objects tell you which stage it's in. A BlindPay payout carries tracking_transaction, tracking_payment, tracking_complete, tracking_liquidity, and tracking_partner_fee, each with a step of processing, on_hold, pending_review, or completed.
Use them for a detailed status view: "stablecoins collected, bank transfer in progress." Don't drive business logic from them. Your ledger should move on status, and only on terminal values.
Provider-neutral pseudocode. Every transition is driven by an event you received, never by a timer guessing.
The first check is the important one. Events can arrive late or out of order. A stale processing event must not undo a completed.
They go different directions.
Refunded means the stablecoins came back to the funding source instead of being converted. Common causes: wrong beneficiary details, a closed or restricted account, or the receiving bank rejecting the transfer. Stablecoin refunds process right away. Credit the balance back in your ledger and ask the sender to check the recipient's details.
Failed means the payout didn't complete, and at BlindPay it does not automatically refund. If a payout reaches failed or sits past its review window, contact support rather than assuming it resolves on its own. In your product, a failed payout should open an internal ticket, not just show a red badge.
Either way, once a payout is terminal, it stays terminal. To try again, create a new quote and a new payout. On a stablecoin rail, a confirmed transfer can't be clawed back, which is why whether stablecoin payments are reversible is really a question about the fiat edges.
Every row in this matrix, on a development instance, before your first real payout.
| Scenario | How to trigger it | What should happen |
|---|---|---|
| Happy path | Any normal amount | completed, recipient notified |
| Failed payout | Quote request_amount of 66600 ($666.00) | failed, ticket opened, no auto-credit |
| Refunded payout | Quote request_amount of 77700 ($777.00) | refunded, balance credited back |
| Expired quote | Wait past expires_at, then execute | Rejected, new quote fetched |
| Reused quote | Execute a second payout on the same quote_id | Rejected, no second payout |
| Duplicate event | Replay a webhook from the dashboard | State unchanged |
| Out-of-order event | Send an old processing after completed | State stays completed |
| Insufficient funds | Execute with less balance than sender_amount | Handled either way: rejected at create, or created and then failed at collection |
The first three rows come straight from BlindPay's sandbox behavior. The rest are your code's job. What a sandbox can and can't simulate is covered in stablecoin API sandbox vs production.
Check the funding balance against the quote's sender_amount before you execute. It's cheaper than finding out from a failure.
BlindPay is a stablecoin API for cross-border payouts and collections: USDC or USDT in, local currency out over Pix, SPEI, ACH, RTP, SEPA, and SWIFT (POBO/COBO) to 100+ countries, with no pre-funding. Every payout reports a single top-level status plus per-stage tracking, and signed webhooks fire at each transition. Retries stay safe with idempotency keys.
Open your payout UI and list every status you show today. If on_hold, failed, and refunded don't each have their own screen and their own ledger action, add them. Then run the test matrix above on a free development instance. The payouts reference has the full lifecycle, and the payout quickstart gets you to your first test payout.
This article is for general information only and is not legal, tax, or financial advice.
AP2, ACP, and x402 each verify that an AI agent had permission to spend. What each covers, who backs it, and the reconciliation gap none close.
Seven stablecoin payment platforms compared for US fintechs in 2026: production readiness, compliance, settlement speed against ACH, and evaluation.
How to choose a stablecoin payment provider in 2026: the four provider types, a comparison of 10 options, and the questions that decide the fit.