A blockchain payment stalled, failed, or hit a depeg. A 6-step incident playbook, a risk register, and how to find where the money is right now.
When a blockchain payment goes wrong, stop sending, find which leg the money is on (wallet, chain, provider, or bank), classify the incident, contain it, resolve it with the right counterparty, and reconcile. Most damage comes from blind retries and missed deadlines, not from lost funds. A written playbook turns a panicked afternoon into a 30-minute routine.
Blockchain payments fail in fewer places than wires, but they fail differently. The hub guide on blockchain payments vs crypto payments covers how the rails work. This page is for the moment something already broke.
Key takeaways
Definition: A blockchain payment incident is any payment that does not reach its expected end state on time: stuck in processing, held for review, failed, returned, sent to the wrong destination, sent twice, or exposed to a stablecoin price move while in flight.
Anything that leaves a payment outside its expected state or timing. In practice, seven incident types cover almost every case a payments team sees.
| Incident | What you see | Where the money usually is |
|---|---|---|
| Stuck payout | Status stays processing past the normal window | With the provider or the bank rail |
| Held for review | Status on_hold, an email or request for information arrives | With the provider, pending compliance |
| Failed or returned payout | Status failed or refunded | Refunded to a wallet, or pending an operator review |
| Wrong destination | Recipient says nothing arrived, details or address were wrong | With the wrong bank account, or at a wrong wallet address |
| Duplicate payment | Two payouts for one invoice | Both delivered, or one still in flight |
| Network halt or congestion | Transactions not confirming on one chain | In the sender's wallet or in the mempool |
| Stablecoin depeg | Market price of the stablecoin drops below $1 | Wherever you hold stablecoins at that moment |
The list matters because each type has a different owner and a different fix. Mixing them up is the most common way an incident drags on.
Stop, locate, classify, contain, resolve, close. Run them in order every time, even for small incidents, so the habit holds when a big one lands.
Idempotency-Key, or turn retries off until you know the state.Steps 1 and 2 should take minutes. If they take hours, the gap is in your logging, not in the blockchain.
Map the payment to its legs and check the evidence for each one. A blockchain payment has up to five legs, and only one of them is truly irreversible.
| Leg | Evidence to check | Who can act on it |
|---|---|---|
| Sender wallet | Wallet balance, pending approvals or delegations | You |
| On-chain transfer | Transaction hash on a block explorer, confirmations | Nobody once final |
| Provider | Payout status and tracking fields, webhook history | The provider |
| Bank rail | Bank reference, UETR on SWIFT payments, rail status | The provider and the banks |
| Recipient account | Recipient confirmation, bank statement | The recipient's bank |
The guide to tracking an off-ramp payout lists the reference each rail gives you. The party map in who is involved in a blockchain payment shows who is responsible at each step.
A register lists each risk, how it shows up, what makes it likelier, how you reduce it, and who owns it. Build it before the first incident and review it quarterly.
| Risk | How it shows up | Likelihood factors | Mitigation | Owner |
|---|---|---|---|---|
| Issuer and depeg | Stablecoin trades below $1 | Reserve concentration, weekend timing, holding period | Short holding periods, caps per stablecoin, support USDC and USDT where the corridor allows | Treasury |
| Network halt or congestion | Transactions stop confirming | Single-network dependency | A second supported network for the same corridor | Engineering |
| Wrong address or bank details | Funds don't arrive, or arrive at the wrong account | Manual entry, recipient changes details | Signed wallet registration, payee verification, re-approval on detail changes | Operations |
| Expired quote or rate move | Execute call rejected, rate differs | Slow approvals, batch runs | Re-quote logic, approval on intent rather than on quote | Engineering |
| Compliance hold | on_hold, request for information | New recipients, large or unusual amounts | Answer requests fast, keep invoices ready | Compliance |
| Duplicate payment | Two payouts for one obligation | Retries on timeouts | Idempotency keys, one internal ID per obligation | Engineering |
| Bank return | Payout fails at the receiving bank | Closed accounts, name mismatch | Verify accounts before first payout | Operations |
The depeg row deserves its own page. Stablecoin depeg risk for payment companies covers limits in detail.
Two public incidents show the pattern: the money was not lost, but timing and price moved fast. Both are well documented by primary sources.
USDC, March 2023. Silicon Valley Bank failed on Friday, March 10, 2023. That evening Circle announced it could not withdraw $3.3 billion of USDC reserves from SVB, around 8% of total reserves, and at its trough USDC traded at 86 cents, according to a December 2025 Federal Reserve note. On March 12, the Treasury, the Federal Reserve, and the FDIC announced that all SVB depositors would have access to their money the next day, and the peg recovered.
The lesson for payments: anyone holding USDC over that weekend carried price risk, while anyone who converted at a locked quote did not.
Solana, February 2024. On February 6, 2024, at 09:53 UTC, Solana mainnet block finalization halted. Consensus resumed at 14:55 UTC, about five hours later, per Solana's own outage report. Transactions sent during the halt simply didn't confirm.
The lesson: a halt is a timing incident. The fix is to stop new submissions, avoid duplicates, and route new payments over another network.
It depends on the provider's rules and the rail, so read them before you need them. A failed bank leg does not always mean an automatic refund.
At BlindPay, a payout moves through processing, can pass through on_hold, and ends as completed, failed, or refunded, as listed in the payouts docs. The payout statuses guide explains each one.
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.
Two practical rules follow. A payout that reaches failed or sits in review does not refund itself, so contact support@blindpay.com instead of waiting. And a request for information on a held transaction has a short clock: the on-hold transactions guide says a transaction may be refunded if the request isn't answered within 24 hours.
Don't retry without idempotency, don't send a "test" payment to the same broken destination, and don't promise the recipient a time you can't see. These three mistakes turn one incident into three.
Idempotency-Key on every retry of a mutating call. BlindPay replays the original response instead of creating a second payout, and keeps the key for 24 hours, per the idempotency docs. The idempotency keys guide shows the pattern.The most common root causes are in common stablecoin payout mistakes: wrong network, expired quotes, and bad bank details.
BlindPay gives you the state of every payout in one place, so step 2 of the playbook is an API call instead of a hunt. The rest of the playbook stays yours.
Idempotency-Key support on mutating requests, so retries can't double-send.BlindPay is backed by Y Combinator and handles about $2.5 billion in annualized volume across 100+ countries.
Copy the six steps and the risk register into your runbook, name an incident owner, and test the playbook once with a forced failure on a development instance. If you're still choosing a provider, what happens if a stablecoin payment provider fails covers the provider-side risk.
Read the BlindPay payouts docs to map every status and refund path into your playbook before your next payout run.
Seven places blockchain payments beat bank rails: contractor payroll, remittances, B2B suppliers, marketplaces, 24/7 treasury, bill pay, and PSP payouts.
Push means the payer sends an ACH transfer. Pull means you debit a connected account. How each funds a USD to USDC on-ramp, the fees, and the return risk.
AP2, ACP, and x402 each verify that an AI agent had permission to spend. Here is what every protocol covers, who backs it, and the reconciliation gap none of them close.