Paid Amount

Overview

Paid Amount records what was actually received or delivered, not what the invoice requested. The value should come from verified transaction output, balance change, token event, or protocol metadata appropriate to the network.

It is compared with Expected Amount to determine exact payment, underpayment, or overpayment. Amount Tolerance can permit a limited shortfall, but the original paid amount should remain unchanged in the record.

Payment systems must avoid reading the wrong field. Top-level transaction value can differ from a token transfer amount, and some protocols expose delivered amount separately from the requested amount. Contract logs and execution success can both matter.

Where several transfers relate to one invoice, the product must define whether paid amount represents the first acceptable transfer, the sum of matched transfers, or another rule. Unrelated deposits must not be aggregated merely because they reached the same address.

The paid amount should remain linked to transaction identifiers, block evidence, confirmation state, and any manual acceptance decision. This allows finance and support teams to reconstruct why the payment was credited and how the final state was reached.

For tokens with transfer fees, rebasing behavior, or partial-payment features, the transaction’s requested amount can differ from what the destination actually receives. Payment processors should use the protocol field that represents delivered value and confirm the post-transaction balance effect where needed. The raw transfer request and delivered result should both remain available for disputes.

When payment information comes from several providers, the system should define one authoritative delivered-value field and compare secondary sources for anomalies. Conflicting amounts should stop automatic credit until the chain-specific evidence is reconciled.