Definition and scope
Why delivered_amount Matters addresses a distinct part of payments and transfers. Use transaction metadata—not the requested Amount alone—to determine what the recipient actually received.
XRPL payments range from direct XRP transfers to routed cross-currency delivery, escrows, checks, and payment channels. This collection focuses on what users and applications must verify before signing and what the validated ledger proves afterward. A payment workflow is complete only after a validated ledger proves the result. Service crediting and recovery remain off-ledger responsibilities.
How it works
delivered_amount in validated transaction metadata identifies the quantity actually delivered by a Payment. It is especially important for partial and cross-currency payments where the transaction's Amount field alone can mislead.
- delivered_amount: verify this field, object, or component against the cited protocol documentation.
- metadata: verify this field, object, or component against the cited protocol documentation.
- tesSUCCESS: verify this field, object, or component against the cited protocol documentation.
- partial payment: verify this field, object, or component against the cited protocol documentation.
Practical example and checks
A deposit service waits for validation, confirms tesSUCCESS, reads delivered_amount using a protocol-aware parser, verifies the destination and asset, then credits that exact value.
For production use, preserve the exact signed or queried data, record the network and validated ledger reference, and compare the result with the current primary documentation before changing off-ledger state.
Open the related live demo or evidence lab →Limits, risks, and common confusion
Older historical transactions may report the unavailable sentinel instead of a value, requiring documented fallback logic. Never infer delivery solely from balance snapshots that include unrelated changes.
A payment workflow is complete only after a validated ledger proves the result. Service crediting and recovery remain off-ledger responsibilities.
Current network status
Enabled on XRPL Mainnet. The underlying protocol capability is available on XRPL Mainnet. Individual services can still impose additional rules, limits, or trust assumptions.
Status reviewed 2026-08-23. Amendment-dependent behavior must be rechecked against the network's live feature state before operational use.