Insights on Crypto Payments, Infrastructure, and Operations

Underpayment Recovery

Pronunciation: UN-dur-pay-ment ree-KUV-er-ee

Definition

Underpayment recovery is the controlled process for resolving a payment that remains below the required amount after validation. Options include requesting a top-up, accepting the shortfall, applying account credit, canceling fulfillment, or refunding received funds. Recovery must preserve the original invoice, every transaction, quote and fee evidence, customer communication, approvals, and final accounting. Retrying or adding funds should not create a new unrelated payment or silently rewrite the initial discrepancy.

Overview

What it means in plain English

Underpayment recovery is the controlled process for resolving a payment that remains below the required amount after validation. Options include requesting a top-up, accepting the shortfall, applying account credit, canceling fulfillment, or refunding received funds. Recovery must preserve the original invoice, every transaction, quote and fee evidence, customer communication, approvals, and final accounting. Retrying or adding funds should not create a new unrelated payment or silently rewrite the initial discrepancy.

How it works and why it matters

Underpayment recovery begins after the system has confirmed an attributable payment and calculated a shortfall under the applicable quote and fee rules. Its purpose is to reach a documented final outcome without losing the original obligation or duplicating value. The appropriate path depends on amount, product reversibility, customer risk, asset, network, and operational cost.

A top-up path gives the customer the remaining amount, supported asset and network, destination or invoice reference, and a deadline. The system links additional transactions to the same invoice and recalculates the total only after confirmation. A new quote may be necessary if the first quote expired, but the pricing change must be explicit.

The merchant can instead accept the difference under its underpayment policy. That decision records the authorized shortfall and accounting treatment while leaving the issued invoice amount intact. Larger or unusual differences may require manual approval rather than automatic fulfillment.

Cancellation or refund is appropriate when the order cannot be fulfilled or the customer declines to complete payment. Refunds need a verified destination, correct asset and network, fee disclosure, approval, transaction tracking, and reconciliation. Returning funds to an address inferred from a transaction can be unsafe when custodial senders or smart contracts are involved.

Recovery records should include required amount, received transfers, shortfall, quote evidence, cause, chosen action, communications, approvals, refund or top-up identifiers, fulfillment state, and final ledger posting. Late transfers after resolution enter an exception queue instead of reopening the order silently.

Metrics such as recovery rate, time to resolution, customer abandonment, refund cost, accepted loss, and root cause help teams improve checkout instructions and adjust underpayment tolerance without hiding recurring integration problems.

Worked example

An invoice needs 100 USDT but receives 94 USDT. The checkout identifies the six-unit shortfall and asks the customer to send the remainder using an approved top-up flow. The merchant links the second transfer to the original invoice and preserves both transaction records.

Practical checks and common confusion

Recovery is not necessarily a refund. Distinguish tolerance rules, partial acceptance and an actual balance owed. If the customer pays the second amount after expiry or on another network, apply an explicit exception policy instead of creating duplicate revenue.

Overpayment Handling Underpayment Policy

Example

An invoice needs 100 USDT but receives 94 USDT. The checkout identifies the six-unit shortfall and asks the customer to send the remainder using an approved top-up flow. The merchant links the second transfer to the original invoice and preserves both transaction records.

Comparison

Recovery is not necessarily a refund. Distinguish tolerance rules, partial acceptance and an actual balance owed. If the customer pays the second amount after expiry or on another network, apply an explicit exception policy instead of creating duplicate revenue.

Key Takeaway

Recovery is not necessarily a refund.

Sources

  1. OxaPay API Reference: Generate Invoice — OxaPay (2026-08-01)
  2. OxaPay API Reference: Payment Status Table — OxaPay (2026-08-01)