More Than One in Six Crypto Payments Arrives for the Wrong Amount. Here Is What Happens Next

Every merchant evaluating crypto payments asks the same second question. The first one is how it works. The second one is what happens when it does not.

It is a fair question and almost nobody answers it with numbers, because almost nobody has the denominator. We do. So here is the honest version, measured across 1,598,636 paid orders created in the twelve months to the end of August 2026.

The short answer: crypto payments fail differently from card payments. They do not bounce and they do not get clawed back weeks later. They arrive for the wrong amount, or they arrive late, or they do not arrive at all. Each of those has a number, and most of them have a lever.

Weighing up the risk before you switch? Open an account and see it for yourself.

How often the amount is wrong

Of every paid order in the window, 82.5% arrived for exactly the invoiced amount. The rest split two ways.

• 179,892 orders arrived with too much, 11.25% of paid orders, or roughly one in nine.
• 110,011 orders arrived with too little. 98,939 of them were still settled as paid, and 11,072 were not.

Put together, more than one payment in six lands for an amount other than the one on the invoice. That sounds alarming until you look at how far off they are, which is what the rest of this post is about.

Overpayment is the common failure, and it is tiny

86.3% of overpayments are under one euro. Well over half are under ten cents.

That is not a market of people fat-fingering an extra zero. It looks like rounding. Wallets that round up, people typing a clean number instead of copying eight decimal places, sends that carry a little more than they needed to. Fewer than one overpayment in a hundred is over twenty euros.

So what happens to it? The order completes normally. The shopper gets an email about the excess and can request it back, supplying the wallet address and the network the refund should go out on.

There is a floor, though. A refund is only issued if the refundable amount is above 2 EUR. That puts 91% of all overpayments below the line, so most of that table never qualifies for a refund at all. Nine cents was never coming back.

Underpayment usually settles anyway. When it does not, it is rarely close

Short payments are less common than overpayments and, most of the time, just as harmless. Nine in ten short orders were still settled as paid, and the median shortfall on those was under two cents. Rounding again, only in the other direction.

The ones that matter are the other 11,072. A payment landed, it was not enough, and the order ended up canceled, expired or invalid. That is 0.69% of paid volume.

The first thing to know is a naming trap that catches integrations. There is no “underpaid” status. The statuses are new, pending, confirming, paid, invalid, expired, canceled, refunded and partially refunded. Underpayment is an amount carried on the order, not a state it sits in. If your code is switching on a status that does not exist, it will never fire.

The second thing is the lever. Underpaid Cover lets you set a tolerance between 0% and 10%, separately for each merchant tool you use (API, payment button or POS). The default is 0%. A payment that lands short by less than your tolerance settles as paid instead of failing. Here is where to find the setting.

There is a condition on it that is easy to miss and changes the answer. The tolerance only applies if the payment arrives inside the twenty-minute payment window. Short and on time is covered. Short and late is not, so a late, slightly short payment will not settle itself.

And there is a limit worth knowing before you expect too much from it. Of the 11,072 short orders that failed, 70.9% were short by more than 10%, further than the highest tolerance the setting offers. No tolerance setting would have caught those. Underpaid Cover is for near misses, and near misses are the minority of what actually fails.

Outside the tolerance, nothing is lost automatically. The shopper is emailed the remaining amount and can top up the same invoice until it expires.

Refunds run at 0.30%, and a refund is not a chargeback

4,811 orders were refunded or partially refunded. That is 0.30% of paid orders.

Be careful what you compare that to, because the comparison people reach for is the wrong one. A card chargeback is a customer going to their bank and the bank pulling the money back out of your account, with a fee and a dispute process attached, sometimes months later. That does not happen here. Our accept page puts it in one line: crypto payments are push-only, meaning funds can’t be reversed.

A refund is the other thing entirely. You decide to send money back, and you send it as a new outbound payment. It is a business decision rather than a bank’s, and it runs through the merchant refund feature rather than a dispute desk.

So the honest way to read 0.30% is not “crypto has a 0.30% chargeback rate”. It is closer to the opposite. Nothing forces a reversal on this rail, and merchants still chose to refund three orders in every thousand, because customers cancel things and merchants make it right. The fraudulent chargeback simply has nowhere to happen.

The orders that never happen at all

One more number, and it is the biggest one on the page. In the same twelve months, 5,822,936 orders were created and never funded.

We are deliberately not calling that an abandonment rate, and neither should anyone quoting it. An order is created when a checkout is requested, and not every checkout request is a human deciding to buy something. Treating the ratio as a conversion figure would be tidy and wrong.

What it does tell you is where the attention belongs. The money you lose on a crypto checkout is almost never lost to a payment arriving wrongly. It is lost before any payment arrives at all, which is a checkout conversion problem, not a payments one.

The operational checklist

If you take five things from this, take these.

• Set Underpaid Cover deliberately rather than leaving it at the 0% default. It catches near misses that arrive on time, and it will not catch a payment that is 30% short.
• Do not switch on an underpaid status. It does not exist. Read the underpaid amount on the order.
• Poll for it. Changes to the underpaid amount do not trigger a callback. Callbacks fire on seven of the nine statuses, and a changing amount inside a status is not one of them. The integration guide covers the polling side.
• Do not close expired orders permanently in your own system. An expired order can still be settled from the merchant side, so your integration should be able to handle an order going from expired to paid.
• Expect overpayments and expect them to be small. One in nine, almost all under a euro, and 91% of them below the 2 EUR refund floor.

Crypto payments are not fragile. Over a year and 1.6 million settled orders, the thing that routinely goes wrong is that somebody sends nine cents too much, or two cents too little. That is a very different risk profile from the one most finance teams are bracing for, and it is worth saying out loud before the conversation starts.

Ready to see how this behaves with your own orders? Start with us.