Underpayment Coverage

Overview

Why small shortfalls happen

Suppose a merchant expects payment equal to $80. The customer calculates a crypto amount, but exchange-rate rounding, wallet display precision or confusion about fees causes a slightly smaller transfer. An underpayment rule answers a narrow question: how much less than the requested amount can be accepted automatically? It does not change what the invoice originally asked for. If an invoice tolerates a particular shortfall, the missing value is still a real economic difference that the merchant has chosen to absorb or treat under its commercial policy.

How the underlying system works

Small shortfalls can result from conversion, rounding or a payer sending slightly less than requested. An invoice system must decide whether to reject the result, request additional payment or accept a bounded difference. The tolerance should be explicit and retained with the original invoice; changing a merchant-wide setting later must not silently rewrite the decision made for an earlier invoice.

The key accounting distinction is that accepting an underpayment does not create missing funds. If an invoice requests 100 units and a policy accepts 98, the merchant still received 98, not 100. The remaining amount may be recognized as a business concession or exception under the merchant's rules. Store the observed transfer, configured tolerance, resulting provider status and fulfillment decision separately.

How the rule is applied

First the service records the original invoice amount and its accepted currencies. Next it calculates the received value under the provider's documented valuation rules and checks the correct network and timing. Then it compares the actual receipt with the amount due and the allowed shortfall. If the difference is within the configured coverage, the workflow may mark the payment acceptable; beyond that limit, it may remain underpaid or wait for another transfer. For OxaPay, the invoice request exposes under_paid_coverage, described in its API documentation as an acceptable payment inaccuracy setting. The unit and interpretation should be taken from the live API contract rather than assumed from the field name.

Do not confuse tolerance with fees or refunds

A coverage setting is not a discount for the customer, a substitute for confirmation, or a statement that the missing coins arrived. It also is not the same as letting the payer cover processor fees. A merchant should set a small, deliberate tolerance based on order margins and customer experience, not blindly accept large shortfalls. Preserve the original expected value, received value and accepted difference in reporting. Otherwise finance may see paid orders whose receipts are systematically lower than sales invoices without knowing why.

Further reading and related concepts

Reference documents: OxaPay — Generate Invoice.

Related glossary topics: Crypto Invoice, Mixed Payment, Invoice Fee Payer.