Why customers send the wrong amount of crypto
An underpaid crypto payment is one of the most common support questions for any business that accepts crypto. With a card, the processor charges the exact amount. With crypto, the customer sends the payment themselves, typing or pasting the amount into a wallet or an exchange, and a few ordinary things can get in the way. When a customer sent the wrong amount of crypto, it is almost always one of these.
Exchange withdrawal fees
This is the big one. Some exchanges take their withdrawal fee out of the amount the customer enters. The customer types 100 USDT, the exchange keeps its fee, and the deposit address receives a little less than 100. As far as the customer can tell, they did everything right, yet the invoice is short.
Rounding
Wallets and exchanges don't all show the same number of decimals. A customer asked for 0.00412783 BTC might send 0.0041, and one asked for 49.99 USDC might send 49.9. The difference is small, but the payment is still short.
Old quotes and price changes
For coins whose price moves, such as Bitcoin or Ether, an amount in coins is only right for a while. A customer who works out the amount from a price somewhere else, copies it from an earlier invoice, or sends long after opening the page can end up short or over.
Split and repeated payments
Some customers pay from two wallets because neither holds enough on its own. Others send a second time because the first transfer seemed stuck, which becomes an overpayment once both arrive.
Sending the wrong coin or using the wrong network is a different problem, and a more serious one, because those coins may be delayed or lost for good. Our guide to accepting USDT payments explains how to keep customers on the right network.
How the locked rate and time window work
Every Crypto Merchant invoice is priced in a currency such as US dollars. When the customer picks a coin and network on the invoice page, the price is converted at live prices and the rate is locked at that moment. The page then shows a deposit address made for this invoice, a QR code, and the exact amount to send. Stablecoins such as USDT and USDC count as one US dollar each, so for them the amount is simply the price.
- The invoice stays open for a limited time, shown as a countdown. You choose how long in your payment settings.
- Until a payment is detected, the customer can switch to another coin.
- If a payment is first seen while the invoice is still open, the locked rate applies, even if the network takes a while to confirm it.
- If the countdown ends before any payment is seen, the invoice expires. Expired invoices cost you nothing.
The tolerance and the underpayment rules below are measured in US dollars at the locked rate. A Bitcoin payment that is short because the customer rounded is judged on the same dollar terms as a USDT payment, and the customer doesn't have to chase a moving price while paying.
How underpaid crypto payments are handled
When the confirmed payment comes to less than the invoice asks for, what happens depends on the underpayment tolerance you set. The check uses confirmed coins only, so a payment that is still confirming shows as confirming first.
Short by no more than your tolerance: paid
If the shortfall is within your tolerance, the invoice counts as paid. You receive what actually arrived, minus the 1% fee, and absorb the small difference. The customer doesn't need to do anything, and the order goes ahead as normal.
Short by more than your tolerance: underpaid
If the payment is short by more, the invoice becomes underpaid. What the customer sent is not credited to you yet. It is held for the customer, who chooses what to do on the invoice page:
- Top up. Send the rest to the same deposit address. Once the total is within your tolerance, the invoice turns paid and is credited to you as normal.
- Refund. Get back what they sent, to a wallet address they enter. The network fee for the refund is taken from the refund, and the invoice becomes refunded.
You don't have to work out the shortfall, chase the customer for a second payment or send coins back by hand: the invoice page gives the customer both options. Your part is to answer the customer clearly if they write to you, and to ship only once the invoice is paid.
An example
Say an invoice is for $50, paid in USDT, and your tolerance is $2. If 49.20 USDT arrives, the invoice is short by $0.80, which is within the tolerance, so it counts as paid and you receive 49.20 USDT minus the fee. If 47.50 USDT arrives, it is short by $2.50, so the invoice becomes underpaid. The customer can then send the missing 2.50 USDT to the same address, or ask for the 47.50 USDT back.
Choosing your crypto payment tolerance
The tolerance is a US dollar amount you set in your payment settings, and Crypto Merchant recommends at least $1. Think of it as the most you are willing to absorb on one order to spare the customer a second transaction.
- Too low, or zero. Customers who lose a little to an exchange fee or to rounding end up underpaid and have to send again, paying another network fee. That is friction at the worst moment, right at checkout.
- Too high. You give away the difference on every order where someone sends short.
- Order size matters. A $2 tolerance is a lot on a $10 order and almost nothing on a $500 one. Set it with your typical order in mind.
- Your customers' exchanges matter. If many customers pay straight from an exchange, look at what those exchanges charge to withdraw on the networks you accept, and set the tolerance a little above that.
You can change the tolerance at any time, so start with the recommended minimum and raise it if you see many invoices underpaid by small amounts.
Crypto overpayment refunds: what happens to the extra
Overpayments are rarer, but they happen: a customer rounds up, sends twice, or tops up more than needed. A crypto overpayment refund works differently from an underpayment, because the invoice is already settled. It counts as paid either way, and you receive the invoice amount minus the fee. The extra isn't yours, and what happens to it depends on its value:
- More than $5. The customer can withdraw the extra to their own wallet from the invoice page.
- $5 or less. The extra goes to the Crypto Merchant platform pool and is not returned, either to you or to the customer.
The invoice shows how much was overpaid, and the API returns it as overpaid_amount. If a customer writes to say they sent too much, point them back to their invoice page, the same link they paid from, to withdraw the extra if it is above the limit. You don't need to send anything yourself.
Late payments and expired invoices
If the countdown ends before any payment is seen, the invoice expires and costs you nothing. A customer who still wants to pay should start again from your checkout page or payment link and pay the new invoice. Deposit addresses can be reused for other invoices after a cool-down, so customers should never send to an address from an expired invoice.
Sometimes a customer does pay, but the payment doesn't show up before the invoice expires, for example because their exchange held the withdrawal for a while. They can report it from the invoice page. The address is then taken out of rotation and kept under watch, and the support team checks the payment. Keep in mind that the locked rate is only guaranteed for payments first seen while the invoice is open.
What you see as the merchant
Every case above shows up as an invoice status in the portal and, if you use webhooks, as an event sent to your server.
| What happened | Status | Webhook | Where the coins go |
|---|---|---|---|
| Payment seen, not yet confirmed | confirming | invoice.confirming | Waiting for confirmations |
| Exact amount, or short within tolerance | paid | invoice.paid | Your balance, minus the fee |
| Short by more than the tolerance | underpaid | invoice.underpaid | Held for the customer to top up or refund |
| Customer took a refund | refunded | invoice.refunded | Back to the customer, minus the network fee |
| Overpaid by more than $5 | paid | invoice.paid | Invoice amount to you, extra claimable by the customer |
| Overpaid by $5 or less | paid | invoice.paid | Invoice amount to you, extra to the platform pool |
| No payment before the countdown ended | expired | invoice.expired | Nothing to move, and no fee |
The rule for fulfilling orders is simple: ship on paid, and only on paid. An underpaid invoice can still become paid if the customer tops up, so give the customer a chance to choose before you write the order off.
If you're a developer, the invoice object includes received_amount, received_usd and overpaid_amount, so you can show the customer exactly what arrived. See the API reference for the full object. Webhooks are signed with HMAC-SHA256 and retried for about two days. Events can arrive more than once and out of order, so use the event ID to skip ones you have already handled.
How to help customers send the right amount
You can't control a customer's wallet, but a few habits cut down on wrong amounts:
- Ask customers to send the exact amount shown. If they pay from an exchange, they should check what it deducts as a withdrawal fee and add that on top.
- Suggest they use the copy buttons or scan the QR code instead of retyping the amount or the address.
- Ask them to pay in one transfer, from one wallet.
- Offer stablecoins. With USDT or USDC, the amount is simply the price, which leaves less room for mistakes. Our guide to stablecoin payments for business covers the options.
- Remind them to choose the same network in their wallet as on the invoice.
- Set a tolerance that fits your typical order, so small, honest shortfalls don't hold up the sale.
If something still looks wrong, the customer can use the options on the invoice page, and you can write to [email protected] with the invoice link. If you haven't set up your store yet, creating an account is free, and these rules work the same from your first invoice.