How to Reconcile Crypto Payments: A Step-by-Step Guide for Merchants

A 1% exchange rate drift on a $10,000 invoice creates a $100 discrepancy. At 1,000 invoices per month, manual reconciliation becomes a full-time job. At 10,000 invoices, it becomes impossible.

Crypto payment reconciliation is the process of making two records agree: what your application says was paid, and what the blockchain confirms was settled. Three sources of discrepancy drive most reconciliation problems, and each has a defined handling pattern. Here is how to work through all three.

The Three Sources of Reconciliation Discrepancies

Every crypto payment reconciliation problem traces back to one of three root causes. Understanding them lets you build the right handling logic before the first discrepancy appears, not after.

1. Underpayment

The customer sent less than the invoiced amount. This happens for several reasons including wallet rounding errors, user mistakes when entering the amount, partial sends, or wallets that subtract network fees from the sent amount rather than adding them on top.

Your application needs a policy for each sub-case:

• Within tolerance: Define a tolerance window, typically 1% to 2%, within which you treat the payment as complete. A customer who was invoiced $100.00 in USDC and sent $99.20 is within 1% tolerance. Treat it as paid.
• Below tolerance: Either hold the order pending a top-up payment, issue a partial fulfillment, or prompt the customer for the shortfall. The right choice depends on your product type. Digital goods and subscriptions typically either reject below tolerance or prompt for top-up, while physical goods may allow partial fulfillment.
• Refund flow: If you choose to refund an underpayment rather than fulfil, you are returning funds to a customer-controlled wallet address. Capture the wallet address at payment time, because refunds to a gateway-generated deposit address are not recoverable.

2. Overpayment

The customer sent more than the invoiced amount. This is less common than underpayment but happens regularly, especially when customers manually enter amounts or convert from fiat at slightly different rates than your gateway used.

Three standard handling options:

1. Credit the overpayment: Add the excess to the customer's account balance for future purchases. This is the lowest-friction option and customers generally accept it.
2. Return the excess: Send the overpaid amount back to the customer's wallet. This requires the wallet address captured at payment time and incurs a network fee on the return transaction, so factor this into your policy for small overpayments.
3. Absorb it: For very small overpayments under a defined threshold such as $0.50, absorb the amount and treat as exact. Returning $0.30 to a customer can cost more in gas than the amount itself.

3. Exchange Rate Drift

When you invoice a customer in fiat-equivalent terms, for example "$50 USD worth of USDC", your gateway calculates the crypto amount at the current exchange rate and generates the invoice. Between invoice creation and payment confirmation, the rate can move.

For stablecoins such as USDC and USDT, drift is minimal because the peg holds within fractions of a cent under normal market conditions. For volatile assets like BTC and ETH, a 1 to 5% drift during a 15-minute invoice window is common.

Gateways handle this in two ways. A rate lock window freezes the rate for a defined period such as 15 or 30 minutes, so if the customer pays within that window at the quoted amount, the payment is accepted regardless of whether the rate has moved. Your revenue in the original asset is fixed, though your fiat-equivalent may differ slightly. A tolerance band accepts payments within plus or minus X% of the invoiced crypto amount, and payments outside the band trigger the underpayment or overpayment flow above.

For reconciliation purposes, your records should capture both the invoiced fiat amount and the confirmed crypto amount. The variance between them is normal operating variance, not a discrepancy requiring investigation.

Underpayment Handling in Practice

A practical underpayment handling flow for most merchant types:

1. Gateway fires a payment_confirmed event with the confirmed amount and the invoiced amount.
2. Your application computes the delta: confirmed_amount / invoiced_amount.
3. If delta >= 0.99 (within 1% tolerance): mark order as paid, proceed with fulfillment.
4. If delta < 0.99: mark order as underpaid, trigger your shortfall flow (prompt customer, partial fulfil, or hold).
5. Log the delta, the absolute shortfall amount, and the trace ID for the reconciliation export.

The tolerance threshold is a business decision, not a technical one. Higher tolerance means fewer customer service touchpoints but slightly lower revenue recovery per order, which is why most merchants set 1 to 2%.

Overpayment Handling in Practice

The critical precondition for any return-excess flow is capturing the customer's sending wallet address at payment time. Without it, you cannot return funds. Most gateways do not auto-capture the sender address, so your integration needs to extract it from the on-chain transaction data that the gateway provides in the webhook payload or via the transaction API.

For credit-the-account flows, your application needs a customer balance model that can hold fractional crypto amounts or their fiat-equivalent at the time of credit. Decide at credit time whether to value the overpayment at the confirmation-time rate or carry it as a crypto balance.

Automation: What to Build vs What to Export

Not everything needs to be automated in your application. Automated handling at the application level includes:

• Tolerance-based accept/reject logic (build this)
• Overpayment credit for amounts above your absorb threshold (build this)
• Order state machine transitions on webhook events (build this)

Beyond that, some reconciliation work belongs at the accounting layer via exports:

• Monthly reconciliation against bank/exchange statements
• FX variance reporting (invoiced fiat vs received crypto at settlement-time rate)
• Refund and return flows for overpayments above a threshold
• Audit trail for compliance

What to Export from Your Gateway Each Month

A clean monthly reconciliation needs these fields per transaction:

The Role of Trace ID in Reconciliation

At low volume, reconciliation is a spreadsheet exercise. At high volume, meaning hundreds or thousands of daily transactions across multiple chains, it requires a reliable identifier that crosses every system boundary.

A trace ID spans the full payment lifecycle from invoice creation through to on-chain confirmation and settlement. Because of this, it lets you answer the reconciliation question precisely: which on-chain transaction corresponds to which order in my application, confirmed at what time, for what amount?

Without trace IDs, this mapping relies on timestamp correlation and amount matching. Both approaches break when two orders have similar amounts or when network delays cause transactions to arrive out of sequence.

AIO assigns a trace ID at invoice creation that persists through detection, confirmation, webhook delivery, and settlement. When you export your monthly payment data, the trace ID is the join key between your gateway records and your order management system.

For the full integration picture, the merchant integration guide covers how to structure your payment flow from invoice to fulfillment. The trace ID guide explains how to use it for debugging and reconciliation at scale.

Accept Crypto Payments: Merchant Guide · Trace ID in Payment Processing