Amount-Based Payment Matching

Overview

Amount-Based Payment Matching compares an observed Paid Amount with the Expected Amount stored for an invoice or order. The comparison can require exact equality or apply a documented tolerance for rounding and conversion precision.

Amount is rarely a unique identifier. Two customers can owe the same value, a payer can split one payment, and unrelated deposits can arrive at the same static address. The matcher should narrow candidates using asset, network, destination, time window, and customer context.

Amount Tolerance must be applied consistently. A payment within tolerance can qualify for acceptance, but the system should retain the actual variance and policy version rather than rewriting the received amount to the expected value.

Matching should occur only after transaction validity and delivery are verified. A pending mempool observation, failed contract call, wrong token, or transfer to another destination must not satisfy the invoice merely because the numeric amount matches.

When several candidates remain, the system should avoid automatic credit and request a stronger reference or manual review. Confidence, selected evidence, rejected candidates, and the final decision should remain auditable.

To reduce collisions, some systems assign slightly different expected amounts to simultaneous deposits. This technique can improve matching but creates customer confusion, precision issues, and possible overlap after rate changes. It should be used only with bounded time windows and must not replace a unique reference where the network supports one.

Matching algorithms should be evaluated with historical collisions and simulated concurrent payments. Precision can appear high in low-volume testing but fall sharply when many customers use the same assets and rounded invoice amounts.