For an XRP Ledger partial payment, use validated transaction metadata and the actual delivered_amount to establish receipt. Amount in API v1, or DeliverMax in API v2, can be a maximum rather than what arrived. A successful transaction with a large stated maximum is therefore not enough to justify crediting that amount or returning a supposed overpayment.
The risk is an accounting assumption, not a broken ledger
Partial payments are a legitimate XRPL feature. They allow an applicable payment to complete with a smaller delivered value under its conditions. The scam opportunity arises when a person or integration records the requested maximum as though it were the actual receipt. A genuine transaction hash and a success result do not repair that accounting mistake.
The official partial-payment explanation warns about this distinction. Do not assume that every payment with the partial flag is fraudulent. Equally, do not let a sender's explanation override the amount that actually reached your destination. Verify the record first, then discuss whether it satisfies the intended transfer.
Direct XRP-to-XRP payments cannot use the partial-payment feature. Cross-currency payments involving XRP can have different semantics. This is why a warning titled XRP partial payment should not be read as saying every ordinary native XRP transfer can secretly deliver less through that flag. The transaction type and asset path matter.
Read each field for the question it answers
| Field or evidence | Question it answers | Mistake to avoid |
|---|---|---|
| Destination and routing tag | Where the payment was directed | Matching only a familiar account name |
| Amount / DeliverMax | The delivery instruction or maximum, depending on payment semantics | Always treating it as the receipt |
| DeliverMin, if applicable | A specified minimum for partial delivery | Assuming it was supplied in every payment |
| SendMax | The sender-side spending limit where used | Calling it the receiver's credited amount |
| TransactionResult | Whether the transaction succeeded under its rules | Treating success as proof of the claimed amount |
| validated status | Whether the result is in a validated ledger | Crediting a provisional observation as final |
| meta.delivered_amount | What the destination actually received | Substituting a requested maximum |
| Asset identity and units | Which value was delivered and how to read it | Comparing different issuers or units as one asset |
The Payment transaction reference explains the API naming change: API v1 uses Amount and API v2 uses DeliverMax. Renaming the field makes the maximum clearer, but an old integration or an explorer summary may still use a familiar label. Ask what the displayed number represents instead of assuming a visual Amount heading settles the question.
Obtain the final record independently
Use a trusted explorer or your receiving application's documented record, reached independently of the sender's link. Confirm the network, transaction hash and receiving destination. The official tx method retrieves a transaction record; a lookup should preserve its validation status and metadata rather than reducing it to one large number.
For issued tokens, also compare the asset's issuer and currency identity. A token carrying a familiar currency code is not automatically the asset your order expected. Read units consistently. A native XRP amount and a token value can have different representations, so an unlabelled integer in a copied screenshot is a poor basis for an account adjustment.
If the delivered field is absent, unreadable or marked unavailable, do not substitute DeliverMax as a convenient fallback. XRPL's metadata reference documents historical partial-payment cases where unavailable requires analysis of the affected ledger entries. A nontechnical recipient should escalate an unresolved record rather than invent a delivered amount. An API failure is a reason to leave verification open.
Work through a fictional overpayment claim
Suppose your private order record expects 80 units of an issued token from the specified issuer. Someone points to a successful payment whose stated maximum is 800 units, but the validated delivered amount for your destination is 0.8 units. These are illustrative numbers, not an attack recipe or a report of a real incident. The evidence supports receipt of 0.8, not an 800-unit credit.
If the sender asks for a return of the difference, do not calculate a refund from the requested maximum. First establish what you actually received, whether it was already accounted for and whether any return is due under your process. A genuine receipt of a small amount does not create an obligation to send a much larger amount from your other funds.
A legitimate partial receipt may simply leave an expected transfer incomplete. Keep the correspondence factual: the record shows this asset and this delivered value; the original obligation remains a separate question. Avoid accusing a counterparty solely because the feature was used, and avoid fulfilling a refund request solely because a confident message calls it an overpayment.
Make the receiving workflow difficult to confuse
- Record the expected asset, issuer where relevant, amount, destination and routing requirement before reviewing the supplied payment.
- Retrieve the transaction through your own trusted route and check its validated result.
- Read the actual delivered amount and compare the correct asset and units with the expected receipt.
- Leave missing or ambiguous metadata uncredited until it is resolved; never replace it with a requested maximum.
- Check that the same receipt has not already been allocated before crediting it or considering any return.
- Keep the verified record and a separate decision trail for any account adjustment.
For integration maintainers, the test case is not merely whether a payment reaches a success state. Check how the system handles partial delivery, missing metadata, different API versions and the same receipt presented twice. A manual review screen should show the actual received value prominently enough that staff do not need to infer it from the sender's requested maximum.
The broader transaction-verification guide helps establish the chain record. Keep deposit tags separate from delivered-value verification: correct routing does not prove a claimed amount. Before a no-account swap, follow that order's actual asset and deposit instructions. A payment feature's existence does not establish that a service accepts every possible XRPL payment form.
FAQ
Is an XRP Ledger partial payment automatically a scam?
No; it is a legitimate payment feature. The dangerous assumption is crediting the requested maximum instead of the amount actually delivered under the validated result.
Which amount should I check on a successful partial payment?
Check delivered_amount in the transaction metadata and verify the asset, destination and validation status. Do not substitute Amount or DeliverMax merely because the transaction succeeded.
Can a direct XRP-to-XRP transfer be a partial payment?
The partial-payment feature is not available for direct XRP-to-XRP payments. Cross-currency payments involving XRP are a different case, so examine the actual payment type.