Card payments are all-or-nothing: the bank approves the exact amount or declines it. Crypto is different. The customer types or scans an amount in their wallet and sends it themselves, and sometimes the amount that arrives is not quite what the invoice asked for. Exchange withdrawal fees, rounding and slow wallets are the usual reasons. A good gateway handles each case so you do not have to.
Why amounts differ
- Exchange withdrawal fees. Some exchanges deduct their fee from the amount sent, so $49.00 becomes $48.20 on arrival.
- Rounding. Wallets may round to fewer decimals than the invoice shows.
- Manual typing. Customers who copy the amount by hand sometimes make mistakes.
- Timing. A customer opens the checkout, gets distracted and pays an hour later, after the rate lock has ended.
The invoice statuses
Cryptomo gives every case its own status, so your store always knows what happened:
| Status | Meaning | What to do |
|---|---|---|
paid | Paid in full (within your tolerance) | Ship the order |
paid_over | More than required arrived | Ship; refund the difference if you wish |
partially_paid | Less than required arrived | Wait: the customer can send the rest before expiry |
paid_late | Paid in full after the invoice expired | Treat as paid (the rate may have moved) |
expired | Time ran out before full payment | Do not ship; any partial amount is shown |
Underpayments
When less arrives than required, the invoice becomes partially paid and the checkout shows the customer exactly how much is still missing, at the same address. Most customers fix it within minutes.
Underpayment tolerance. You can set a small tolerance per store, for example 1%. Payments that are short by less than this are accepted as paid, which avoids holding a $100 order over a few cents of exchange fees.
If the invoice expires while only partly paid, the order is not fulfilled and the partial amount is shown on the invoice. You can refund it to the customer from the dashboard, or ask support to accept it as paid if you are happy with the amount.
Overpayments
When more arrives than required, the invoice becomes paid over and your webhook treats it as paid. The extra amount is recorded, so you can refund the difference if the customer asks.
Late payments
Rates are locked only for the invoice window. If the full amount arrives after expiry, the invoice becomes paid late: you received the coins, but the market price may have changed. For stablecoins like USDT and USDC this rarely matters; for volatile coins you may want to check the value before shipping a high-value order.
After an invoice expires, its address stays reserved for a cooldown period, so a late payment is still matched to the right order.
Wrong coin or wrong network
If a customer sends a different token, or uses the wrong network, the payment may not be detected automatically. Contact support with the transaction hash; some cases can be recovered, others cannot. Showing the network clearly at checkout prevents most of these. Read our USDT network comparison.
Setting it up in your store
- Plugins already map statuses to orders: WooCommerce puts partial payments on hold and cancels expired orders; WHMCS marks the invoice paid only when it is fully paid.
- API users should treat
paid,paid_overandpaid_lateas paid, and make the webhook handler idempotent. See verifying webhooks. - Invoice window: a longer window helps customers who pay from exchanges; a shorter one limits rate exposure on volatile coins.
Summary
Different amounts are normal in crypto. With clear statuses, a sensible tolerance and automatic handling in your plugin, they become routine instead of support tickets. Open your dashboard to review your store's tolerance and invoice settings.
