---
title: "What to do when a blockchain payment goes wrong: a 6-step incident playbook"
seoTitle: "Blockchain payment incident playbook: 6 steps"
description: "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."
date: "2026-10-03"
updated: "2026-10-03"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "What should I do first when a blockchain payment goes wrong?"
    a: "Stop sending more money down the same route, then find out where the funds are. Pause retries for that corridor or network, pull the payout ID, quote ID, and transaction hash, and check the payout status. Most incidents get worse because a team retries blindly and creates a duplicate, not because the first payment was lost."
  - q: "Can a blockchain payment be reversed if something goes wrong?"
    a: "An on-chain stablecoin transfer can't be reversed once it is final. The bank leg is different: a fiat payout can fail, be returned by the receiving bank, or be held for review, and the provider then decides what happens to the funds. That is why an incident starts by locating which leg the money is on."
  - q: "What happens to my funds if a BlindPay payout fails?"
    a: "If a payout can't 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. USD payouts and payouts whose review times out are refunded after an operator review, so contact support instead of waiting."
  - q: "How did the USDC depeg in March 2023 affect payments?"
    a: "After Silicon Valley Bank failed on March 10, 2023, Circle said $3.3 billion of USDC reserves, about 8% of the total, were stuck there. USDC traded as low as 86 cents, per a December 2025 Federal Reserve note. The peg recovered after US authorities protected all SVB depositors. Teams holding USDC over that weekend carried the price risk."
  - q: "What should a business do if a blockchain network halts?"
    a: "Stop submitting new payments on that network, keep anything already in flight under watch, and route new payments over another supported network if your provider allows it. Solana's February 6, 2024 outage stopped block finalization for about five hours. Payments resumed when the network restarted, so the main job is to avoid duplicates and tell recipients what is happening."
  - q: "Who should own a blockchain payment incident inside a company?"
    a: "One named incident owner, usually in payment operations, with finance and engineering on call. Operations locates the funds and talks to the provider, engineering checks webhooks and retries, and finance reconciles the ledger once it is over. Compliance joins whenever a payment is on hold or a request for information arrives."
---

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](/resources/more/blockchain-payments-vs-crypto-payments) covers how the rails work. This page is for the moment something already broke.

**Key takeaways**

- Pause first. A retry without an idempotency key is how one failed payout becomes two sent payouts.
- Locate the money by leg: on-chain transfers are final, bank legs can fail, return, or sit in review.
- A depeg or a network halt is a pricing and timing problem, not usually a lost-funds problem.
- Know your provider's refund rules before the incident, not during it.
- Close every incident with a reconciliation and one change to limits, routing, or monitoring.

> **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.

## What counts as an incident in a blockchain payment?

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.

## What are the six steps of the playbook?

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.

1. **Stop the bleeding.** Pause automated retries and new payouts on the affected corridor, network, or recipient. If your system retries on timeouts, make sure every retry sends the same `Idempotency-Key`, or turn retries off until you know the state.
2. **Locate the money.** Pull the payout ID, quote ID, transaction hash, and any bank reference such as a UETR for wires. Read the current status and the tracking fields. You want one sentence: "the funds are on leg X, with party Y."
3. **Classify and assign an owner.** Pick the incident type from the table above and a severity. One payout to one contractor is low. A halted network with 300 payouts in flight is high. Name one owner.
4. **Contain.** Cap exposure while you work. Hold new payouts to the affected recipient, switch new payments to another network, lower internal limits, or stop holding stablecoin balances overnight during a depeg.
5. **Resolve with the right counterparty.** That is the provider's support team for stuck or held payouts, the compliance team for a request for information, the recipient for wrong bank details, and nobody for a confirmed transfer to a wrong wallet address you don't control.
6. **Close and learn.** Reconcile your ledger against the provider's final statuses, tell affected recipients what happened, and write down one change to limits, routing, monitoring, or onboarding.

Steps 1 and 2 should take minutes. If they take hours, the gap is in your logging, not in the blockchain.

## How do you find where the money is?

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](/resources/more/how-to-track-a-crypto-off-ramp-payout) lists the reference each rail gives you. The [party map in who is involved in a blockchain payment](/resources/more/who-is-involved-in-a-blockchain-payment) shows who is responsible at each step.

## What should be in a blockchain payment risk register?

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](/resources/more/stablecoin-depeg-risk-payments) covers limits in detail.

## What happened in real blockchain payment incidents?

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](https://www.federalreserve.gov/econres/notes/feds-notes/in-the-shadow-of-bank-run-lessons-from-the-silicon-valley-bank-failure-and-its-impact-on-stablecoins-20251217.html). On March 12, the Treasury, the Federal Reserve, and the FDIC [announced](https://www.federalreserve.gov/newsevents/pressreleases/monetary20230312b.htm) 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](https://solana.com/news/02-06-24-solana-mainnet-beta-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.

## What happens to the funds when a payout fails?

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](/docs/payouts). The [payout statuses guide](/resources/more/stablecoin-payout-statuses-explained) 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](/docs/kb/on-hold-transactions) says a transaction may be refunded if the request isn't answered within 24 hours.

## How do you avoid making the incident worse?

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.

- **Retries.** Send the same `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](/docs/learn/idempotency). The [idempotency keys guide](/resources/more/stablecoin-api-idempotency-keys) shows the pattern.
- **Webhooks.** If your webhook handler was down, replay missed events instead of guessing state. BlindPay's [webhook docs](/docs/learn/webhooks) describe a hosted portal where a teammate can browse delivery attempts and replay events.
- **Recipient messages.** Tell the recipient which leg the payment is on and when you'll update them next. Skip estimates you can't verify.

The most common root causes are in [common stablecoin payout mistakes](/resources/more/stablecoin-payout-mistakes): wrong network, expired quotes, and bad bank details.

## How does BlindPay help during an incident?

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.

- Payout statuses plus tracking sub-statuses for the payment, transaction, and liquidity steps.
- Signed webhooks for every state change, with a hosted portal to replay deliveries.
- `Idempotency-Key` support on mutating requests, so retries can't double-send.
- SWIFT (POBO/COBO) payouts carry a UETR once the wire is confirmed, so every bank in the chain can trace the same payment.
- Nine supported networks, listed in [supported chains](/docs/kb/supported-chains), so a halt on one network doesn't have to stop new payouts on a corridor.

BlindPay is backed by Y Combinator and handles about $2.5 billion in annualized volume across 100+ countries.

## What to do next

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](/resources/more/what-happens-if-a-stablecoin-payment-provider-fails) covers the provider-side risk.

Read the [BlindPay payouts docs](/docs/payouts) to map every status and refund path into your playbook before your next payout run.