Track an XRP Transaction: Pending, Failed or Not Credited

Start with the sender's withdrawal or payment history. An internal reference can help support locate a request, but it may not be a blockchain hash.

1. Open the outgoing payment and copy its network transaction hash, if one exists.
2. Confirm that the transfer used the XRP Ledger, rather than another chain's XRP representation.
3. Search the hash on the XRP Ledger mainnet view of XRPSCAN (xrpscan.com) or Bithomp (bithomp.com), then open the transaction record.
4. If no hash is available, check whether the sender has actually broadcast the payment.

Searching the recipient address can help locate a payment, but a shared account may receive many transfers. Match the amount and time as well as the address before deciding that a record is yours.

The word success is useful only in context. A preliminary response from submission can change before the transaction is included in a validated ledger.

A Validated Successful Payment

Look for validation and the final transaction result, commonly displayed as tesSUCCESS for a successful payment. Then inspect what was delivered and to whom; validation alone is not enough to identify the intended beneficiary.

An ordinary XRP payment typically settles on the ledger in about 3–5 seconds, but the sender's queue and a hosted recipient's credit checks can take longer. If an app remains pending for minutes, establish which stage is waiting instead of assuming the ledger itself is still processing the same payment.

For Payment records, use the actual delivered amount shown by the explorer or metadata. The maximum requested amount in a partial or cross-currency payment can differ from the amount actually delivered, so a headline amount is not always the right evidence.

A Validated Unsuccessful Transaction

A final tec result can mean the intended action failed while the ledger still applied the transaction cost. It should not be described as a successful payment merely because it appears in a validated ledger.

The XRP fee and reserve explanation helps interpret the balance change. Record the result code before asking the sender to investigate or attempting another transfer.

A Pending or Missing Record

Pending may describe a platform queue, an unvalidated submission or a wallet display waiting to refresh. These are different states, with different contacts able to help.

If the sender has not broadcast a transaction, the receiving platform cannot locate it on-chain. If a submitted payment has no final result yet, establish its outcome through the sender before retrying; absence from one explorer is not proof that it can never execute.

A submitted transaction may include LastLedgerSequence, the last ledger in which it can be validated. Ask the sender to confirm that this limit has passed and that the transaction is absent from the complete relevant ledger history before treating it as expired. Without such a limit, an unvalidated signed transaction can remain eligible for later execution.

A hosted service can use one XRPL account for many customers. Its destination tag tells that service which internal balance should receive a payment.

Get the tag from that recipient's current deposit screen or the exchange instructions for this payment. Do not generate a tag yourself or reuse a value assigned to another recipient.

An X-address can encode a tag alongside the account. Do not manually add, remove or reinterpret fields unless the receiving instructions and sending wallet support that format.

Suppose a hosted platform supplies a shared address and a destination tag for a deposit of 50 XRP. The sender broadcasts a payment to the correct address, but the transaction contains no tag.

If the account enforces the ledger's tag requirement, the payment may be rejected. If it accepts the payment without that enforcement, the transfer can succeed on-chain while the platform cannot automatically match it to your customer balance.

For the successful case, the relevant record would show TransactionType: Payment, validated: true, TransactionResult: tesSUCCESS, a delivered amount of 50 XRP, the correct destination and no DestinationTag. These are illustrative field values, not a real customer's transaction. The combination points to recipient-side reconciliation, rather than another source payment.

In the successful case, sending another payment does not edit the first one's tag. Prepare a support request containing:

• The transaction hash and final explorer result.
• The destination address and the tag actually recorded, including its absence.
• The tag the platform instructed you to use.
• The delivered amount, time and your platform deposit reference.
• The sender's withdrawal record if further proof of origin is requested through a verified channel.

Manual credit or recovery depends on the recipient's controls and policies. Do not pay an unsolicited recovery agent or disclose signing credentials to speed up the process.

Responsibility follows where the problem sits. Keep an exchange's source transfer, conversion status and receiving transfer separate when investigating a multi-step conversion.

The Sending Wallet or Platform

Contact the sender about a withdrawal still queued without a hash, an unexpected deduction, a failed submission or uncertainty about rebroadcasting. A receiving platform cannot alter the sender's queue.

For an exchange such as XRP to ETH, the XRP deposit and Ethereum payout have different hashes. Searching the XRP hash on an Ethereum explorer will not show the later delivery.

The Receiving Service

Contact the recipient when the ledger confirms the correct payment but its customer account remains uncredited. Include the evidence above and check its stated minimum and processing requirements.

The comparison of XRP destination tags and Stellar memos is useful if you are moving between platforms that handle both networks. Similar labels do not establish that the same field value applies.