What Happens When a Customer Underpays or Overpays?

Customers send the wrong amount. Not often as a share of payments, but constantly in absolute terms once you are doing volume, and the way your platform handles it is the difference between a rule and a queue of support tickets.

Why it happens

Almost never fraud. The causes are dull.

• Fee deducted instead of added. The customer sends 100, their wallet takes the network fee out of it, and 99.7 arrives. This is the most common cause by a wide margin.
• Manual entry. Somebody typed the amount by hand and got it slightly wrong.
• Price movement. A quote in fiat, paid in a volatile asset a few minutes later.
• Two payments for one invoice. They sent half, got distracted, sent the rest.

Underpayment

You need a tolerance and a rule, decided once.

Inside tolerance, accept it. Failing a 500 dollar order over 30 cents costs you more than the 30 cents in every direction that matters.

Outside tolerance, hold it and tell the customer what is short. The good pattern keeps the payment open so the balance can be topped up rather than voiding it and forcing them to start again.

Overpayment

Less common, more awkward, because you now hold money that is not yours.

Credit the difference against a future order if you have an account relationship, or refund it. Whichever you choose, make it automatic. Overpayments sitting in an unresolved state are how balances stop reconciling.

The token you did not expect

Somebody sends an asset you have not configured, or the right token on the wrong chain. This is where platforms differ most.

The bad outcome is silence: the funds arrived, nothing in your dashboard acknowledges them, and the customer insists they paid. The good outcome is that the deposit is recorded as an unknown transaction and can be bound to your account after review. Nothing is lost, it simply needs a human for a moment.

Ask any prospective provider this exact question. The answer tells you how carefully the system was built.

The operational point

Every one of these should be a configured rule, not a decision somebody makes on the day. Rules are consistent, auditable and cost nothing to apply. Case-by-case judgement is slow, inconsistent between staff, and impossible to reconcile at the end of the month.

Set the tolerance, set the overpayment behaviour, decide who reviews unknown deposits, and then stop thinking about it.

Frequently Asked Questions

What happens if a customer sends the wrong amount of crypto?

It depends on your configured rules. A slight underpayment can be accepted, a large one held for review, and an overpayment credited or refunded. What matters is that the rule is set in advance rather than decided case by case.

Why do crypto underpayments happen?

Usually because the customer's wallet deducted the network fee from the amount sent rather than adding it on top. Manual entry errors and price movement between quote and payment account for most of the rest.

What happens if someone sends a token you do not support?

On a well-built platform it is recorded rather than lost. AIO logs it as an unknown sub-transaction which can be bound to your account after review, so the funds are recoverable.

Should I set a tolerance for underpayments?

Yes. A small tolerance, often a fraction of a percent, avoids failing genuine payments that fell a few cents short because of a fee deduction. Set it once and stop treating those as exceptions.