How to verify an XRP payment result, destination tag and delivered amount

Chapter 01

Understanding XRPL transaction engine codes

Settlement on the XRP Ledger occurs in 3 to 5 seconds through consensus validation. However, determining whether a transaction actually achieved its intended purpose requires inspecting the transaction metadata, specifically the Transaction Result Engine Code.

When a transaction is submitted to rippled, it returns an engine result categorized into prefix classes: - tesSUCCESS: The transaction was applied to a validated ledger and achieved its stated objective successfully. - tec (Transaction Engine Claimed): The transaction failed to achieve its primary objective (such as paying a non-existent account or breaching a trust line limit), but it was still included in the ledger to claim the transaction fee, preventing denial-of-service spam. - tef / tem / tel: The transaction failed locally, had malformed syntax, or was rejected before ledger inclusion, meaning no transaction fee was deducted.

Automated systems and payment gateways must verify that a transaction is included in a validated ledger and returned tesSUCCESS. Relying on a provisional response from an unvalidated ledger or treating a tec result as a successful payment can lead to crediting uncompleted deposits.

Chapter 02

The critical role of Destination Tags for hosted accounts

A central operational feature of XRPL transactions is the Destination Tag—an optional 32-bit unsigned integer (ranging from 0 to 4,294,967,295) embedded in the payment payload.

Centralized crypto exchanges, custodial brokers, and payment gateways generally maintain a single pooled on-chain XRP address for all customer deposits rather than generating millions of separate on-chain accounts. When an exchange instructs a user to deposit XRP, it provides its master address along with a specific Destination Tag corresponding to the user's internal account balance.

If a user sends XRP to an exchange address without the required Destination Tag—or enters an incorrect tag—the funds still successfully settle into the exchange’s master wallet on the blockchain. However, the exchange’s automated settlement systems cannot credit the deposit to the user's account without manual investigation, support intervention, and verification fees. Self-custody wallets sending to personal accounts do not require destination tags, but accounts can enable the asfRequireDest flag to programmatically reject any incoming payment that lacks a tag.

Chapter 03

The partial payment trap: Amount versus DeliveredAmount

One of the most dangerous edge cases in cryptocurrency accounting is the Partial Payment feature on the XRP Ledger. By default, an XRPL payment is all-or-nothing: if the sender specifies 1,000 XRP, exactly 1,000 XRP must be delivered or the transaction fails.

However, if a transaction includes the tfPartialPayment flag, the transaction is permitted to succeed even if it delivers less than the quoted Amount field—for instance, if liquidity along a cross-currency path was insufficient. - In a partial payment, the top-level Amount field in the transaction JSON reflects the maximum amount the sender intended to deliver. - The actual amount credited to the destination account is recorded exclusively in the metadata field: meta.delivered_amount.

Malicious actors have historically targeted exchanges and merchants by broadcasting a partial payment with an Amount of 100,000 XRP while configuring the payment to deliver only 0.000001 XRP. Systems that naively read the header Amount instead of verifying meta.delivered_amount credit the attacker with 100,000 XRP of account equity. Production verification systems must always inspect delivered_amount to confirm real settlement value.

Chapter 04

Account reserve requirements and delete account mechanics

Unlike accounts on EVM networks that exist purely as cryptographic balances, an account on the XRP Ledger requires an on-chain reserve to exist in the ledger state: - Base Reserve: Currently 10 XRP. An address cannot receive its first payment or exist on-chain unless the first transaction sends at least the base reserve amount. This reserve is locked to cover the storage cost of the account in the ledger. - Owner Reserve: Each object owned by an account (such as trust lines, offers, or signer lists) locks an additional 2 XRP.

If a user wishes to close an XRPL account and recover the locked reserve, they must execute an AccountDelete transaction. Account deletion burns a higher transaction fee (currently 2 XRP) and transfers the remaining reserve balance to another destination address, provided the account has removed all trust lines and open offers first.

Chapter 05

Operational payment verification checklist

When sending or integrating XRP payments, enforce this verification checklist:

1. Always send a small test payment when depositing to a new centralized exchange address before moving significant capital. 2. Confirm the destination exchange requires a Destination Tag, and copy both the address and the tag accurately. 3. In software integrations, inspect meta.TransactionResult === "tesSUCCESS" and require validated: true. 4. Read the exact settlement value from meta.delivered_amount rather than the top-level Amount field. 5. Review our parent XRP news desk and crypto exchange comparison guide for verified custody and transfer methodology.

Chapter 06

Destination Tag data format and binary serialization

The XRP Ledger uses 32-bit unsigned integers (representing values from 0 to 4,294,967,295) as Destination Tags to differentiate individual user payments directed to a single shared custodial account. Because establishing a standalone XRPL account requires locking an unspendable base reserve of XRP (currently 10 XRP) onto the ledger state, centralized exchanges, custodial payment gateways, and merchant processors utilize a single omnibus master account to receive deposits on behalf of millions of individual clients.

A standard XRPL payment payload specifies: - TransactionType: Payment - Account: rSourceAddress123456789... - Destination: rExchangeOmnibusAddress987... - DestinationTag: 1084592 - Amount: 50000000 (denominated in drops, where 1 XRP = 1,000,000 drops) - Fee: 12 (network drops burned for ledger inclusion)

When a user initiates an exchange deposit, the sending wallet encodes the assigned Destination Tag into the binary transaction blob. Upon consensus validation, the receiving exchange's automated ledger monitoring software parses the validated transaction, extracts the Destination Tag, and credits the internal user account associated with that integer ID.

Chapter 07

Recovery procedures and custodial ticket resolution

Sending XRP to a custodial exchange without including the mandatory Destination Tag (or entering an incorrect tag) results in the funds arriving successfully at the exchange's omnibus address on-chain, but failing to credit to the user's internal account. Because the transaction has already achieved permanent, immutable consensus finality on the ledger, it cannot be reversed or cancelled by the sender or network validators.

Key information required when submitting a custodial deposit recovery claim: 1. Validated Transaction Hash (64-character hexadecimal string). 2. Exact Ledger Index Sequence Number in which the payment was validated. 3. Sending XRPL Public Address. 4. Receiving Exchange Omnibus Address. 5. Exact Amount Transferred (in drops).

To prevent deposits from becoming stranded, account owners can enable the "RequireDest" account flag ("asfRequireDestTag") on their XRPL accounts. When this flag is enabled, the protocol automatically rejects any incoming payment transaction that omits a Destination Tag, returning an immediate consensus error ("tecNO_DST_TAG") and preserving the sender's funds in their wallet.