Why Crypto Checkouts Do Not Convert, and What to Fix

A shopper picks the crypto option, the invoice opens, and then nothing happens. The order sits there until it expires.

If your dashboard shows more orders created than orders paid, that gap is not fraud and it is not a mystery. It is a checkout problem. Crypto checkout conversion behaves like any other conversion problem, with its own specific failure modes, and hardly anyone measures it that way.

Plenty has been written about why card payments decline and what that costs you. The crypto equivalent gets far less attention, partly because card intuition does not transfer. A card either authorises or it does not. A crypto payment can arrive late, arrive short, arrive twice, or never arrive while the customer is sure they sent it. We have improved the checkout experience before. What nobody has written down is where the drop-offs actually happen, and which of them you can close from your own side.

Seeing more orders created than orders paid? Get a checkout you can actually configure.

The two clocks

Every order runs on two timers, not one, and most merchants only know about one of them.

In the new status, the shopper has two hours to choose a payment currency and network. Once they choose, the order moves to pending and a much shorter clock starts. From that moment they have 20 minutes to complete the transfer. Miss either window and the order goes to expired.

The second one is what catches people. Twenty minutes is comfortable for someone with a funded wallet already open on the same device. It is not comfortable for someone who has to move funds off an exchange first, or who opens the invoice, realises their wallet is empty, and plans to come back.

That window is short for a reason. The less time between quoting an amount and receiving it, the less room the market has to move underneath both of you. However, it also means the invoice page is a terrible place for a shopper to start working out where their crypto actually lives.

Neither window is yours to change. There is no expiry parameter when you create an order, so the fix has to sit upstream. One line at the moment they select crypto, telling them to have a funded wallet ready, does more for your completion rate than anything on the payment page itself.

Underpayment, and the tolerance you probably have not set

Underpayment is the failure mode that looks like a failure and usually is not.

First, a naming thing that trips up integrations. There is no “underpaid” order status. The statuses are new, pending, confirming, paid, invalid, expired, canceled, refunded and partially_refunded. Nine of them, and underpayment is not one. It is a property of an order rather than a state of it, carried as an amount, so if you are writing logic that switches on status, do not go looking for one that does not exist. Work from the crypto payment API integration guide instead.

Then the lever you do have. Underpaid Cover lets you set a tolerance of up to 10%, and you set it separately for each merchant tool you run, so the API, the button and the POS each carry their own number. If a payment lands short by less than your tolerance, the order is marked paid automatically and the shopper never hears about it.

One condition is easy to miss, and it matters. The cover only applies if the payment actually arrives inside that 20 minute window. A payment that is both short and late is a different case, and it lands in the expired pile further down this page.

Outside your tolerance, the shopper gets an email with the remaining amount and can top up the same invoice until it expires. We made the case for accepting underpaid orders a long time ago and the logic has not aged. A short payment is a customer who tried.

Which number to pick is a judgement call, and it is your money either way. Size it against your average order value rather than reaching for a round figure, because a tolerance that is barely noticeable on a 500 EUR order is a real cost on a 15 EUR one.

Overpayment, the quieter problem

Overpayment runs the other way and it is gentler than it sounds. The order completes. The shopper is emailed about the excess and pointed at a refund request, and only the excess is ever in play, never the order itself.

The awkward case is the very small overpayment. Refunds have to clear a minimum refundable amount before they can be sent at all, and a genuinely tiny excess can sit below that line, which means it is not going anywhere. Nobody wins there. Put a sentence about it in your refund policy rather than letting support improvise case by case.

Expired does not always mean lost

Two things are true here at the same time, and your support team needs both of them.

The payment address is single use. Every order gets a fresh one, and funds sent to an address from an older order are not linked to the order they used to belong to. If your team instinct is to tell a customer to send it to the address they already have, that instinct is expensive.

However, an expired order is not automatically a closed one. A late payment can still be settled to you, for a window you configure yourself, per merchant tool, the same way the tolerance works. Check your own setting rather than assuming a default.

Which creates the integration consequence people miss, and it runs the opposite way to what you would expect. Do not count on being told. A callback fires when the order expires. The later move to paid is not something you should rely on reaching your server, and a change in the underpaid amount does not send one either. What you can always do is ask: retrieve the order and the current values are there. So if your system treats expired as final and stops asking, you will eventually be holding money against an order your own database closed days ago.

Worth knowing while you are in that code. The payment callback fires on seven of the nine statuses, not all of them. new and partially_refunded do not send one.

The form nobody budgets for

Here is a drop-off point that has nothing to do with wallets or timers.

Before a payment can be processed, we have to collect some basic details from the shopper, because the law requires it. Email, first and last name, date of birth, country of residence. It is not a long form. It just arrives at the worst possible moment, after the person has already decided to buy and while the clock is running.

You can take most of it off their hands. When you create the order through the API, pass what you already know about them in the shopper object and those fields come through pre-filled. If your customers have accounts with you, you are almost certainly holding every one of those values already. There is no reason to make somebody type their own name again with 20 minutes on the clock.

Network choice, and the fee the shopper did not expect

The first clock exists because picking a currency and a network is a real decision, not a formality. Shoppers stall there, and some of them stall permanently.

Whatever they pick, moving the funds costs them a network fee on top of what they owe you. That fee goes to the network. We do not set it and we do not receive it. On a large order nobody notices. On a small one it can be a visible share of the total, and the same asset moved over a different network can cost a very different amount.

There is a second-order effect worth knowing about. Some wallets take that fee out of the amount the customer typed rather than adding it on top, which is one of the everyday reasons an order arrives slightly short. That is exactly the case Underpaid Cover exists to absorb, and it is the best argument there is for setting a tolerance above zero.

What you control here is expectation. Say plainly, before the invoice loads, that the network fee is theirs and sits on top of the order total.

The mobile wallet handoff

On desktop, paying an invoice is copy, paste, confirm. On mobile it is an app switch, and every app switch is a place to lose somebody. Your customer leaves the checkout, opens a wallet, approves, comes back. If anything goes wrong in between, they are no longer on your page to see it.

The 20 minute window is running the whole time.

Two things help. Do not open the invoice somewhere the shopper cannot easily get back from, which mostly means being careful with in-app browsers and orphaned tabs. And shorten the handoff itself wherever you can, which is what wallet connection standards are for and what our WalletConnect announcement was about.

A configuration checklist

• Set Underpaid Cover deliberately, per merchant tool, sized against your average order value.
• Pre-fill the shopper details you already hold when you create the order, instead of asking for them at the worst moment.
• Tell shoppers to have a funded wallet ready before they reach the invoice, not on it.
• State that the network fee is theirs and sits on top of the order total.
• Keep asking about expired orders instead of closing them for good, because the late move to paid may never reach your server.
• Write a refund line for very small overpayments so support is not improvising.
• Never tell a customer to reuse a payment address from an older order.

None of this touches what you actually end up holding at the end, which is a separate decision with its own trade-offs. We go through that one in a companion post on choosing a settlement currency.

Frequently asked questions

How long does a customer have to pay a crypto invoice?

Two hours to choose a payment currency and network, then 20 minutes to complete the transfer once that choice is made. The second clock only starts on the choice, so a shopper who opens the invoice and wanders off still has the longer window to come back. Neither window can be set when you create the order.

What happens if a customer pays less than the invoice amount?

If the shortfall falls inside the Underpaid Cover tolerance you set, up to 10%, and the payment arrives inside the 20 minute window, the order is marked paid automatically. Outside that, the customer receives an email with the remaining amount and can top up the same invoice until it expires.

Can a customer pay an expired invoice?

The payment address is single use, so funds sent to an old address are not linked to the order they used to belong to. The order itself is a different question. A late payment can still be settled to you for a window you configure per merchant tool, which is exactly why an expired order should not be treated as closed inside your own system.

What happens when someone overpays?

The order completes, the shopper is emailed about the excess, and the refund goes through a request rather than automatically. Only the excess is refundable. Very small overpayments are the difficult ones, because a refund has to clear a minimum refundable amount before it can be sent.

Who pays the blockchain network fee, us or the customer?

The customer pays it, on top of your order total, and it goes to the network rather than to us. Some wallets take that fee out of the amount the customer typed instead of adding it on top, which is one of the everyday reasons an order arrives slightly short.

The bottom line

Crypto checkout does not fail for mysterious reasons. It fails because a shopper ran out of time, got asked for their date of birth with the clock running, sent slightly the wrong amount, got surprised by a fee, or lost the thread during an app switch. Every one of those has a setting, a piece of copy, or a line of integration logic sitting behind it.

Start with the two you can change this week. Set Underpaid Cover to a number you have actually thought about, and stop treating expired orders as final.

Think your crypto checkout is leaking orders it should be keeping? Look at what our crypto payment checkout gives you to configure, and if you are not with us yet, start here.