The Amount on That Payment Is Not What You Received.
A Payment can succeed while delivering less than Amount. XRPL.org says to credit delivered_amount, not the Amount field.
The Amount on That Payment Is Not What You Received.
A Payment on the XRP Ledger can succeed while delivering less than the Amount field shows. XRPL.org says to read delivered_amount in the transaction metadata, not Amount, when you credit an incoming payment.
A Payment is a transaction that sends XRP or an issued token to a destination account. Amount is the field on that transaction. A partial payment is a Payment with the tfPartialPayment flag turned on. delivered_amount is the metadata field that records how much actually arrived.
What the Amount field actually is
When a Payment does not use the Partial Payment flag, Amount is the exact quantity that must be delivered after transfer fees and exchange rates. If the network cannot deliver that full amount without exceeding SendMax, the transaction fails. If SendMax is omitted, it is treated as equal to Amount.
When tfPartialPayment is enabled, Amount is a maximum, not a promise. The optional DeliverMin field sets a minimum. The payment can succeed by delivering any positive amount at or above DeliverMin, without exceeding SendMax. XRPL.org notes that in rippled API v2 this field was renamed DeliverMax so the name matches that behavior.
The XRP transaction cost, the Fee field, is always deducted from the sender. It is not part of Amount.
The field that shows what arrived
Successful Payment metadata includes delivered_amount in the same format as Amount. XRPL.org says that is the amount actually delivered.
For a payment that is not partial, delivered_amount equals Amount. When the payment delivers tokens, rounding can make delivered_amount slightly different from Amount.
For a partial payment included in a validated ledger before January 20, 2014, delivered_amount may be the string "unavailable." In that case the docs say to read AffectedNodes in the metadata.
When a payment cannot be partial
Direct XRP-to-XRP payments cannot be partial payments. That case returns temBAD_SEND_XRP_PARTIAL. Cross-currency payments that involve XRP as one of the currencies can be partial payments.
A partial payment also cannot provide the XRP that funds a new address. That case returns telNO_DST_PARTIAL.
Why exchanges and merchants are told to check delivered_amount
XRPL.org documents a Partial Payments Exploit against naive integrations. A sender can submit a Payment with a large Amount and tfPartialPayment enabled. The transaction can return tesSUCCESS while delivering a much smaller amount. If software credits Amount instead of delivered_amount, it can credit the sender in an external system for money the ledger did not deliver. The docs describe that pattern for gateways, exchanges, and merchants. They do not name a current victim in the pages reviewed for this article.
The monitoring guidance adds two related checks. Only a result of tesSUCCESS in a validated ledger is final for changing non-XRP balances. Some payments still enter the ledger and fail, charging an anti-spam fee. A partial payment can be treated as successful if any non-zero amount is delivered, including a minuscule amount.
What remains unknown
CryptoWorkPro has not inspected any specific wallet, block explorer, or exchange screen. Those displays vary. This article does not claim a live exploit against a named venue.
What to check next
For an incoming Payment, XRPL.org's processing rule is to use delivered_amount, confirm tesSUCCESS, and confirm the transaction is in a validated ledger with your account as Destination. Do not treat the Amount field as proof of what arrived.
Sources
- XRPL.org, Partial Payments, retrieved September 28, 2026: https://xrpl.org/docs/concepts/payment-types/partial-payments
- XRPL.org, Robustly Monitoring for Payments, retrieved September 28, 2026: https://xrpl.org/docs/concepts/payment-types/robustly-monitoring-for-payments
Disclosure: This article explains XRP Ledger payment fields from XRPL.org documentation retrieved September 28, 2026. Wallet and explorer displays vary, and CryptoWorkPro has not inspected any specific incoming payment. The featured image is a generated illustration, not a screenshot of a ledger or wallet. This article is not financial, legal, or investment advice. AI-assisted research and writing. Cited sources, not AI alone, support the claims.