XRPL Partial Payment Verification: How to Check the Amount Actually Delivered
Private research candidate - not approved for publication.
XRPL partial-payment verification starts with a distinction that is easy to miss when reviewing a Payment transaction: the amount written into the transaction instructions is not always the amount the destination actually receives. A Payment with the partial-payment flag can succeed while delivering less than the transaction's stated delivery ceiling. That behavior is part of the protocol, not evidence by itself that a transaction is malformed. For an investigator, exchange integration, accounting workflow, or deposit monitor, the practical consequence is that the transaction instruction and the observed outcome must be examined separately. A reliable review therefore asks two questions in order: was the payment processed as a partial payment, and how much value did the destination actually receive according to the transaction metadata? Treating those as separate questions avoids using an instruction field as if it were an observed settlement amount.
The flag is the first structural signal. XRPL documentation defines a partial payment as a Payment transaction with the tfPartialPayment flag enabled. In current API terminology, the field historically called Amount is named DeliverMax in API v2 and later, which makes its role clearer: it represents a maximum delivery target rather than guaranteed evidence of what arrived. A partial payment may complete after delivering a positive amount that satisfies its applicable constraints, including DeliverMin when that field is present. This means a reviewer should not classify the nominal transaction amount as the received amount merely because the transaction ultimately succeeded. The transaction object tells you what was requested or bounded; the metadata tells you what the ledger says actually happened. Keeping those roles separate is the foundation for correct partial-payment analysis.
The strongest amount field for this workflow is delivered_amount in transaction metadata. XRPL's metadata documentation explicitly recommends using delivered_amount to determine how much reached the destination instead of deciding case by case whether the transaction's Amount or DeliverMax can be trusted. The Payment reference makes the same operational point: delivered_amount records the currency amount actually received by the destination account. This is useful even beyond obvious partial-payment cases because a verification routine can use one consistent output field for successful Payment transactions instead of switching logic based on assumptions about the instruction fields. In an evidence-first investigation, that makes delivered_amount the observed settlement value, while Amount or DeliverMax remains part of the transaction's submitted intent and constraints. The two should be displayed and reasoned about as different pieces of evidence.
Amount verification is not enough unless finality is checked as well. XRPL transaction metadata is authoritative only when the transaction belongs to a validated ledger version. A provisional result can change before consensus places the transaction into a validated ledger. For that reason, a deposit or forensic workflow should not combine an unvalidated status with a delivered amount and label the result final. Robust monitoring guidance also states that only transactions from a validated ledger are final. The safe order is therefore: identify the transaction, confirm the ledger result is validated, inspect the transaction result, and then interpret delivered_amount. This ordering prevents a user interface or automation from presenting a provisional observation as immutable ledger evidence. It also keeps transaction finality separate from the separate question of how much value was ultimately delivered.
A practical verification workflow can be expressed as a small evidence checklist. First, confirm that the record is the intended Payment transaction and preserve its hash so later checks refer to the same transaction. Second, inspect whether tfPartialPayment is enabled instead of guessing from the size of the transfer. Third, require a validated-ledger result before treating the outcome as final. Fourth, inspect the result code and the metadata associated with that validated transaction. Fifth, read delivered_amount as the amount received by the destination. Finally, retain the transaction's Amount or DeliverMax alongside the delivered amount when context matters, but label it as an instruction or ceiling rather than a settled amount. This procedure is deliberately conservative: it does not infer intent from the partial-payment flag, and it does not infer the received value from a field that the protocol does not define as the final delivered amount.
There is an historical edge case worth preserving in any implementation that analyzes old ledger data. XRPL documentation notes that delivered_amount may be unavailable for a partial payment that was included in a validated ledger before 2014-01-20. In that narrow case, the metadata can contain the string unavailable rather than a normal currency amount. The documentation explains that the actual delivery then has to be reconstructed from the AffectedNodes in the transaction metadata. A robust research page should state this limitation instead of silently converting unavailable into zero or treating the transaction as if no funds moved. This distinction matters because zero, unknown, and unavailable are different evidence states. Modern transactions normally provide the convenient delivered_amount field, while historical exceptions require deeper metadata interpretation before an amount conclusion is supported.
Partial-payment verification also benefits from separating protocol facts from investigative conclusions. The presence of tfPartialPayment proves that the transaction used the protocol's partial-payment behavior; it does not by itself establish fraud, abuse, or malicious intent. Likewise, a difference between DeliverMax and delivered_amount demonstrates that the submitted ceiling and the actual delivered value differ, but intent must be evaluated from additional evidence if that question matters. The evidence that can be stated directly is narrower and more useful: whether the partial-payment flag was set, whether the transaction is final in a validated ledger, what result the metadata reports, and what delivered_amount says the destination received. This keeps the analysis reproducible because another reviewer can inspect the same transaction hash and metadata and reach the same protocol-level observations without relying on an unsupported label.
For an XRPL deposit or wallet-investigation workflow, the final output should therefore make the verification chain visible rather than collapsing it into a single success badge. Show the transaction hash, validated status, Payment type, partial-payment flag state, transaction result, submitted Amount or DeliverMax when relevant, and the metadata delivered_amount. If delivered_amount is unavailable for the historical exception, state that explicitly and require AffectedNodes review before reporting a received amount. The core rule is simple: successful submission is not the same thing as final settlement, and the payment instruction is not always the same thing as the amount received. By anchoring the result to validated-ledger metadata and the delivered_amount field, an XRPL research workflow can report what the ledger actually supports while preserving the limits of that evidence.