Paid Amount
Pronunciation: PAYD uh-MOWNT
Also known as: Actual Paid Amount, Received Payment Amount, Delivered Amount
Definition
Paid amount is the quantity of the pay currency actually delivered by the payer and recognized by the payment system for a transaction or payment session. It can differ from the expected amount because of underpayment, overpayment, multiple transfers, token mechanics, or matching errors. The value must be derived from verified blockchain evidence and stored with asset, network, destination, transaction, and confirmation context.
Overview
How it works
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.
What matters in practice
The paid amount is the actual value credited against a payment obligation, which may differ from a requested amount, a raw blockchain transfer or a quoted fiat equivalent. A payment system must specify measurement currency, network, token decimals, fee payer, rate timestamp and treatment of multiple transfers. Some chains deduct a fee from the sender's separate balance; others route fees through custodial or provider accounts. Do not compare human-readable tokens to integer base units without decimal conversion. Every adjustment should have a visible accounting reason.
Related glossary concepts
Example
An invoice asks for 100 USDC and receives transfers of 60 and 39 USDC. Its observed gross transfers total 99 USDC, but the credited paid amount is determined by the merchant's matching and fee rules. A separate provider fee may affect settlement without changing what the customer paid.
Comparison
Requested amount, received amount, paid amount, credited amount and net settlement amount are related quantities, not synonyms.
Key Takeaway
Paid amount is the verified value actually delivered, and it must remain distinct from the requested amount, gross reporting value, and merchant net proceeds.
Sources
- OxaPay API Reference: Payment Information — OxaPay (2026-08-02)
- OxaPay API Reference: Payment Status Table — OxaPay (2026-08-02)
- XRP Ledger Documentation: Robustly Monitoring for Payments — XRP Ledger (2026-08-02)