When a blockchain payment goes wrong, stop retrying, find which leg the money is on (your wallet, the network, the provider or the recipient's bank), name the type of incident, and take it to the party that controls that leg. A confirmed network transfer cannot be undone, but the bank legs around it can still fail, return or pause.
The costly mistakes come early: a team retries a payout that was already on its way and pays a supplier twice, tells the recipient a time it cannot verify, or opens a ticket with no identifiers in it. Network finality and legal reversibility is covered separately; this post is about what to do while the payment is still open.
Why most incidents are timing problems, not lost money
A cross-border payment that touches a stablecoin is rarely one event. In a stablecoin corridor such as USDC to BRL, the money sits in a wallet, moves over a blockchain network, is converted in an off-ramp, and then travels on a local rail such as Pix (Brazil's instant payment system, run by the Central Bank) to the recipient's bank, in the regions shown on the operator map. Each leg has a different owner and a different failure mode, and only one of them is final.
"Where is the money" is a more useful question than "what went wrong". Funds in a wallet, in review at a provider or waiting on a bank cut-off are delayed, not lost. Funds sent to an address nobody can sign for are the one case where waiting changes nothing.
What are the nine ways a blockchain payment goes wrong?
Nine incident types, grouped by who can act: the provider, the recipient's bank, you, or nobody. The owner differs for each, which is the reason to classify before acting.
Nine incident types, what the sender sees, where the money usually is, who can act and what Lumx returns.
Incident | What you see | Where the money usually is | Who can act | What Lumx returns |
Stuck payout | Status does not move past the expected window | With the provider or the bank rail | The provider | The current status in the transaction lifecycle, and a webhook on each change |
Held for review | A hold and a request for context | With the provider, pending review | You answer, compliance decides | A request for information (RFI) from compliance, raised by email or Slack; a transaction RFI API is planned between the end of 2026 and Q1 2027 |
Failed payout | A failed status and an error | Check your wallet balance and the transaction record; the status alone does not say | The provider | A failed status, a webhook and a message to contact support |
Held or returned at the recipient's bank | Provider says complete, recipient says nothing arrived | With the recipient's bank | The recipient's bank | A complete status once funds leave the banking partner |
Wrong bank details | Recipient cannot find the credit, or the bank refuses it | A rejected credit or a wrong account | You, before sending; the recipient, after | A destination error before money moves, such as |
Wrong address or wrong network | The transfer confirmed but the owner never received it | At the address that received it | Nobody, unless its owner cooperates | A transaction hash and a block explorer link in the receipt |
Duplicate payment | Two payouts for one invoice | Both delivered, or one still in flight | You, against the payee | The same |
Expired quote or rate move | The call is refused, or the delivered amount differs | Not moved yet | You, by quoting again | An expired-rate or already-used-rate error, such as |
Network halt or stablecoin price fall | Transfers do not confirm, or the stablecoin trades below one dollar | In your wallet | You and your treasury | A locked quote fixes the conversion rate until it expires, nothing more |
Wrong bank details and duplicate payments are cheaper to prevent than to repair; the reason codes are in payout rejection reason codes.
When the provider says complete and the recipient says nothing arrived, the recipient's bank controls what happens next, because it can hold or return a credit under its own rules. Lumx marks the off-ramp complete once the funds leave its banking partner, so the next step is to take the bank reference to the recipient's bank and send the same reference to operations@lumx.io. Tell the recipient the leg you have confirmed, what you are doing next, and no time you cannot verify.
The six steps, in order
Run the same six steps for every incident, small ones included.
Stop. Pause automated retries and new payouts on the affected corridor, network or recipient. If your system retries on a timeout, every retry must carry the same idempotency key, or retries stay off until you know the state.
Locate. Pull the payout ID, the quote ID, the transaction hash and any bank reference. You want one sentence: the funds are on leg X, with party Y. The status for each rail is in payout statuses and tracking.
Classify. Pick the incident type from the table above and name one owner. One payout to one supplier is low severity; a halted network with hundreds of payouts in flight is not.
Contain. Cap the exposure: hold new payouts to the affected recipient, lower internal limits, or move new payments to another supported network.
Resolve with the counterparty that holds the leg. That is the provider for a stuck or held payout, your compliance contact for a request for information, the recipient for bank details, and nobody for a confirmed transfer to an address you do not control.
Close. Reconcile your ledger against the final statuses, tell the affected recipients what happened, and write down one change to limits, routing, monitoring or onboarding. The ledger side is in reconciling stablecoin transactions.
On Lumx, step 2 is a read, not a search. Every transaction has a type and a status that moves through a fixed lifecycle (an off-ramp goes from TRANSFERRING_STABLECOIN to TRADING to TRANSFERRING_FIAT to SUCCESS), and every status change can be pushed to your system as a webhook. An API error response carries a requestId, and a failed transaction carries its transaction ID. Those two, plus the transaction hash for any network transfer, are the three identifiers to send to operations@lumx.io.
Time windows that decide the outcome
Before treating a payout as stuck, check it against the published windows. The ones below are the ones Lumx publishes, and they are processing targets, not contractual guarantees.
Windows that explain a payout that looks late, with the source in the Lumx docs.
Window | Value | Why it matters in an incident |
Pix and SPEI | No cut-off, 24/7/365, instant | If a Pix or SPEI payout is late, it is not a cut-off, so check the status |
ACH | 2:00 PM ET cut-off, 1 to 2 business days | A request after the cut-off or on a US holiday waits for the next business day |
FEDWIRE | 3:00 PM ET cut-off, same business day | An off-ramp triggered late in São Paulo can miss it |
SWIFT (USD) | 3:00 PM ET cut-off, 1 to 5 business days | Intermediary banks add hours or days |
Transaction RFI | 24 hours to respond | After that the transaction may be refunded to the sender |
Idempotency key | 24 hours | After that the same key can be used for a new request |
Payment window on a floating-rate collection | 1 day on Pix and SPEI, 7 days on other rails | A deposit after expiry is refunded to the sender on the same rail |
The per-rail detail, with limits, is in cut-offs and limits by rail. Lumx treats an off-ramp as complete once the funds leave its banking partner, so a recipient's bank that holds a credit for its own review is a separate conversation from a Lumx status. Lumx returns UETR and MT103 confirmations on every SWIFT payout and a per-rail reference on every transfer.
What a price fall of a stablecoin does to a payment in flight
A price fall is a pricing and timing problem, not a lost-funds problem. The best public record is March 2023: according to a Federal Reserve FEDS Note, Circle said at 10 p.m. on Friday, March 10 that it could not withdraw $3.3 billion of USDC reserves from Silicon Valley Bank, around 8% of reserves, and at its trough USDC traded at 86 cents. On March 12, the Treasury, the Federal Reserve and the FDIC announced that all depositors at the bank would be fully protected, with access to their money from Monday, March 13.
Anyone who held USDC over that weekend carried price risk; conversions completed before it did not.
On Lumx, a locked quote fixes the conversion rate until it expires and does not protect a balance sitting in a wallet. An autoconversion rule converts a fiat deposit to stablecoin at market on arrival, which shortens the holding period without locking a rate.
I would spend the first fifteen minutes of any incident locating the payment and nothing else: no message to the recipient, no second attempt, no ticket that contains a guess. A team that writes to the recipient before it knows which leg holds the money usually has to retract the message, and a retraction costs more trust than a late first message. The runbook I would want a client to have before volume starts fits on one page: who owns the incident, which three identifiers get pulled first, and the single sentence the recipient hears.
When the wrong destination cannot be fixed
Two cases have no repair, and a runbook should say so in plain words. The first is a confirmed transfer to an address whose owner is not you and will not cooperate. The network has no operator with a button, and the provider does not control the receiving address. The second is a transfer on a network or in a stablecoin the receiver does not support.
Both are prevented, not repaired: register the destination before the first payment, confirm the network and stablecoin it expects, and send a small test first for large amounts. The differences between networks, and which stablecoins run on which, are in how the networks differ.
A stablecoin payout is also the wrong tool when your flow routinely undoes payments, as escrow-style arrangements do. A rail with a built-in reversal fits better; see when not to use blockchain payments for the other cases.
On Lumx, a customer's wallet exists on each supported network, and the wallet record lists the network and the stablecoins it holds: USDC and USDT on Ethereum and Polygon, USDC only on Base, USDT only on Tron, and Stellar for the BRL on-ramp to USDC only. A destination for a payout is registered under the customer, with the holder relationship stated, before any money moves. Lumx does not promise to recover a transfer sent to the wrong address or on the wrong network. If it happens, send operations@lumx.io the transaction ID and the transaction hash, and do not plan around getting the money back.
What an incident looks like on a Lumx payout
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
Take a USDC payout to a supplier through the global payments product. It is an off-ramp from the customer's wallet to a registered destination, followed through four statuses. If it fails, the failed status and webhook arrive with the message "Please contact support" and the transaction ID. Before retrying, check the wallet balance and the transaction record, then send operations@lumx.io the transaction ID and the requestId. A timeout on an RFI (request for information, a compliance hold that asks for details before a transaction clears) and a late deposit are the cases the docs say are refunded to the sender; Lumx does not state a wallet re-credit or a timeline for other failures, so do not promise one to the recipient. If the transaction is flagged by monitoring, it is held, and Lumx compliance contacts the team by email or Slack with the transaction details. The usual questions are the relationship between sender and receiver, the purpose of the payment and the expected outcome. The 24-hour window applies to every transaction, and without an answer it may be refunded to the sender.
Two inputs cause holds that are easy to avoid. Banking partners read the purpose field on every on-ramp and off-ramp for screening, and a value that does not match what the funds are for can hold up the transaction or raise an RFI. And an inconsistent payee shows up as a destination error before money moves, for example HOLDER_TAX_ID_MISMATCH.
On the collection side, the on-ramp for a Pix or SPEI (Mexico's interbank transfer system, run by Banxico) deposit has a payment window of one day at a floating rate. A deposit that arrives after it expires is not processed and is refunded to the sender on the same rail, so the fix is a new on-ramp. Lumx coverage lists which networks and rails are live per currency, and the same logic applies to USDC to MXN flows over SPEI.
Methodology and sources
Product behavior was read on November 1, 2026 from the Lumx documentation: the transactions, wallets and destinations pages, the webhooks reference, the errors catalog and the RFI, idempotency and cut-off pages.
The March 2023 USDC episode was read in the Federal Reserve FEDS Note of December 17, 2025 and in the Treasury, Federal Reserve and FDIC joint statement of March 12, 2023, both at federalreserve.gov.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: huanyu chen on Unsplash.
What should I do when a blockchain payment goes wrong?
Stop retries on the affected route, then find which leg holds the money: your wallet, the network, the provider or the recipient's bank. Collect the payout ID, the transaction hash and any bank reference before you contact anyone, and name one owner for the incident. With Lumx, the transaction status and the status webhooks your system received show the leg, and the identifiers to send are the transaction ID, the request ID and the transaction hash.
Can money sent to the wrong address or the wrong network be recovered?
Usually not by the network or the provider, because a confirmed transfer cannot be undone and neither controls the receiving address. Recovery depends on whoever holds the keys agreeing to send it back. Lumx does not promise recovery of a transfer sent to the wrong address or on the wrong network, so send operations@lumx.io the transaction ID and the transaction hash, and prevent it by registering destinations and checking the network before the first payment.
Why is my payout stuck, and how long is normal?
Check the rail first. Pix and SPEI have no cut-off and run every day of the year, while ACH, FEDWIRE and SWIFT have cut-offs in US Eastern time and wait for the next business day after them. Lumx publishes the cut-off and settlement window for each rail, and a payout that is on hold shows up with an RFI from compliance, which has a 24-hour response window.
What if my system retried and paid twice?
Prevention is the idempotency key. If two payouts did go out, locate both by transaction ID and recover the second from the payee, because a delivered payout is not reversed by the sender. On Lumx, the same key and body returns the cached response with an X-Idempotency-Cached header set to true, a different body returns a 409, and a key whose first request is still processing also returns a 409. Keys last 24 hours, and failed responses are cached too.
What should I do when a payment is held for a request for information?
Answer on the channel the request came from, with the relationship between sender and receiver, the purpose and the expected outcome, inside 24 hours. A slow reply is what turns a hold into a refund to the sender. On Lumx, compliance reaches out by email or Slack, and releases the transaction once it has reviewed your answer.
