Why crypto payments fail or never reach the order, how to check a transaction, what can be refunded, and how merchants can prevent failures at checkout.
A failed crypto payment is almost never a mystery. Either the transaction never reached the network, it reached the network but never confirmed, or it confirmed for the wrong amount, token or network and your system could not match it to an order. Each case has a different check and a different fix. This guide walks through where payments break, how to verify what happened in a few minutes, what can and cannot be refunded, and how to design a checkout that fails less often.
In card payments, a failure usually means a decline. In crypto there is no issuer to decline anything, so “failed” is a loose word that customers use for very different situations. It helps to separate them.
The most useful distinction is between states that can still change and states that cannot. In Circle’s documentation, terminal states such as complete or failed are final, and a transaction cannot move out of them. Everything before that, such as pending or processing, is still in motion.
A wider definition comes from payments operations. One industry playbook treats a blockchain payment incident as any payment that does not reach its expected end state on time. That includes payments stuck in processing, held for review, failed, returned, sent to the wrong destination, sent twice, or exposed to a stablecoin price move.
For a merchant, the practical list looks like this:
| What the customer says | What probably happened | Can it still resolve? |
|---|---|---|
| “I paid, nothing happened” | Transaction not broadcast, or waiting for confirmations | Yes, often on its own |
| “It says underpaid” | Fees were deducted from the amount, or the rate moved | Yes, with a top-up |
| “It says expired” | Payment arrived after the invoice window closed | Yes, by manual or automatic reconciliation |
| “I sent the wrong coin or network” | Funds went to an address on a different chain | Sometimes, with provider help |
| “I was charged twice” | Duplicate send or duplicate notification | Yes, with a refund or credit |
| “The platform says failed but my wallet shows sent” | Status mismatch between wallet and checkout | Yes, after checking the hash |
A crypto checkout has more moving parts than most people assume. Thinking of it as a chain of five handoffs makes troubleshooting much faster, because you only need to find the link that broke.
Notice that only two of these five steps involve the blockchain itself. Most “failed” payments are caught in steps 1, 2 and 5, which are about integration and customer behavior.
The following causes cover the large majority of tickets a crypto merchant handles. Understanding how trust and verification work across a distributed ledger also helps explain why these situations occur, and there is useful background on secure digital transactions with blockchain for teams new to the technology.
This is the number one cause. A customer pays from an exchange account, and the exchange deducts its withdrawal fee from the amount sent. The invoice expected 100 and 99.2 arrived. Trezor’s support documentation notes that the service or wallet used to send a payment may deduct fees from the final amount, leaving it underpaid, and that this usually happens when paying from an exchange.
The fix is to tell customers, right on the checkout page, to send the full amount net of fees and to prefer a personal wallet when possible. On the merchant side, decide in advance what to do with small shortfalls. Our deeper guide to underpaid crypto payments covers tolerance thresholds and top-up flows.
USDT exists on several networks, and the same address format can be valid on more than one of them. A customer who selects one network on your checkout and withdraws on another may lose access to the funds or need manual recovery. Industry guidance lists wrong network, expired quotes and bad bank details as common root causes of stablecoin payout mistakes, and the first two apply to inbound payments too.
Show the network name next to the coin in large type. Display a short warning on the payment page. Where your gateway supports it, create one address per coin-and-network pair rather than a generic address.
Crypto invoices lock a rate for a limited window. If the customer pays after it closes, the amount may no longer match, especially for volatile coins. Stablecoins reduce this problem a lot, which is one reason many US merchants lean on them. See our U.S. guide to accepting stablecoin payments for the trade-offs.
A customer who picks the cheapest fee setting during a busy period may see the transaction sit unconfirmed for hours. Nothing has failed yet, but the customer believes it has. Your status page should say “waiting for network confirmation” and show the hash, not a vague “processing”.
The money is on the chain and confirmed, but the order remains unpaid. The usual suspects are a webhook endpoint that returned an error, a firewall blocking the gateway’s IP range, a signature check that fails after a deploy, or a handler that creates a second order when the same notification arrives twice. We cover this in detail in Webhooks and Idempotency and in our piece on why replay checks alone will not stop duplicate orders.
Sometimes a transaction is perfectly valid but gets paused by a limit, either on the sender’s exchange or in the merchant’s own risk rules. Know your own thresholds. Our note on crypto payment limits for merchants explains how to set them without blocking honest buyers.
You do not need special tools. You need the transaction hash and two screens.
If the explorer says the hash does not exist, the transaction was never broadcast or was dropped. The customer’s funds are usually still in their wallet, and the fix is for them to resend, with a sensible fee.
A payment that has confirmed on the blockchain cannot be reversed. There is no chargeback system and no issuer to call. What you can do is send a new payment in the other direction. That changes how you should think about “refund”: it is a fresh transaction with its own network fee.
Processor documentation reflects this. Trezor’s guidance says overpaid amounts may be refunded minus transaction fees, that some amounts are non-refundable when processing costs exceed the amount, and that for a wrong-token or wrong-network payment the customer should contact support to check whether a refund is possible.
For merchants, a workable refund policy covers four cases:
Put the policy on the checkout page in two sentences. It prevents more tickets than any support macro.
The same technical causes show up everywhere, but the cost of a failure differs.
E-commerce. The risk is an abandoned cart after a confusing payment page. Show the exact amount, the network, a countdown and a copyable address. Send an email with the status link so the customer can return to the page. See our overview of crypto payments for e-commerce.
Freelancers and invoices. Invoices stay open longer, so rate lock is the issue. Invoice in a stablecoin, or re-quote on open, and allow a small tolerance for fees.
SaaS and subscriptions. Crypto has no pull payments by default, so recurring billing is a series of reminders and fresh invoices. Add a grace period before cutting access, and notify before expiry. Cards fail too, as we explain in getting paid when cards fail.
Games. Players expect instant delivery. Grant items on the confirmation count you are comfortable with, set lower thresholds for cheap items, and send alerts to your team. Our guide to payment alerts in Discord shows one way to do it.
Marketplaces. Failures can hit the buyer side and the seller side. A stuck payout should not block other sellers. Split commissions automatically and batch payouts, as covered in crypto mass payouts and payouts at scale.
The best habit is boring: write down what happens when something goes wrong. An operations playbook should classify incidents such as stuck payouts, network halts and wrong destinations, and assign an owner to each class. A one-page version is enough:
On the engineering side, idempotency is the single most valuable control. The same playbook notes that using the same idempotency key on every retry of a mutating call prevents creating a second payout. Apply the same logic to inbound notifications: key each one on the payment ID, and make repeat handling a no-op.
We see the same pattern across merchants. The blockchain rarely fails. What fails is the handoff between a customer’s wallet, a gateway and a store’s order system. That is why we built our gateway around reconciliation: every payment has one record that shows what was expected, what arrived, on which network, with how many confirmations, and what your store was told.
Two habits separate merchants with few failed payments from those with many. First, they treat underpayments as a normal event with a defined tolerance, not an error. Second, they make their webhook handler safe to run twice. Neither requires a large team.
We also think onboarding friction is a hidden cause of failures. Merchants who wait weeks for approval tend to rush integrations or skip testing. Because our onboarding is no-KYC with instant approval, you can run test payments on day one, break things on purpose and see how each failure looks before a real customer does.
— Dustin
Our gateway supports 110+ cryptocurrencies through hosted checkout, payment links, e-commerce plugins and API, with reconciliation tools that show each payment’s state. Published pricing runs on volume tiers from 2% at Standard down to 0.1% at Enterprise, or a flat $0.10 per payment. You can review the options on our crypto payments page or look at the flat per-payment gateway. For payouts, see mass payouts.
If you want to convert incoming coins before they reach your books, auto-conversion to stablecoins reduces exposure to price moves between invoice and settlement. Confirm the current terms on the site before you plan around them.
Usually the two systems are looking at different things. Your wallet shows that a transaction was signed and broadcast, while the checkout waits for confirmations or checks the amount. Take the hash, open it in the explorer for the right network and compare address, amount and confirmations.
If it never confirmed, the funds normally stay in your wallet. If it confirmed to the right address, it cannot be reversed, and the merchant would have to send a new payment as a refund, usually minus network fees. For wrong-network sends, contact the merchant or gateway support with the hash.
It depends on the network and the fee paid. A low-fee transaction can wait in the pending pool for hours, while a fast chain confirms in seconds. Set an escalation time in your playbook, and check the explorer before telling a customer to resend.
The usual cause is on the notification side: a webhook that returned an error, was blocked, or failed a signature check. Replay the notification from your gateway dashboard after fixing the endpoint, and make sure your handler is idempotent so a repeat does not create a second order.
Show the exact amount, coin and network on the checkout page, tell customers to cover exchange withdrawal fees, set a small underpayment tolerance, and make webhook handling idempotent. Then write a one-page playbook so each failure type has an owner.
Open a free CryptoPayr account and take your first crypto payment the same day.
Get started for free
Learn how to sell digital goods for crypto: pick a payment model, automate delivery, handle fees, refunds and taxes, and start accepting Bitcoin and more.
What a self-hosted crypto gateway is, what it takes to run one, what it costs, and when a hosted or white-label gateway is the smarter choice for your business.
What zero confirmation crypto payments are, why they stall, the double-spend risk, and a practical way for merchants to decide when to accept one and when to wait.