What the hash solves
It points to one specific transaction instead of a wallet’s general activity, a cropped image or an unrelated incoming payment.
XRP Payment Verification Guide
How to verify an XRP payment without trusting a screenshot.
A payment claim is not proof. Verify the transaction hash, final ledger status, result code, destination, delivered amount, Destination Tag and memo against the actual payment instructions.
Verification checklist
A valid-looking transaction may still be the wrong payment.
Verification means matching public ledger evidence to one expected payment. Success, destination and amount must all be correct—and some workflows also require a specific tag or memo.
-
Obtain the transaction hash
Use the unique transaction identifier rather than a screenshot, copied balance or unverified wallet notification. -
Confirm validated status
Make sure the result belongs to a validated ledger. Proposed or provisional results are not final. -
Confirm tesSUCCESS
Check the transaction metadata result. A failed transaction did not deliver the intended value. -
Match the destination
Compare the complete destination address with the address in the original payment instructions. -
Verify the delivered amount
Determine what actually reached the destination instead of relying only on the amount requested by the transaction. -
Match the payment context
Confirm any required Destination Tag, memo or agreement identifier before crediting the payment.
Start with the ledger record
The transaction hash identifies the exact event.
Every XRPL transaction has a unique hash. Paste that hash into a trusted XRP Ledger explorer or query it through an XRPL API to inspect the transaction and its metadata.
What the hash does not prove
Finding a real transaction does not automatically prove it matches your agreement. Its result and payment fields still need inspection.
Never verify from an image alone.
Screenshots can be altered, reused or taken from a different transaction.
Public ledger data is the evidence.
Finality and result
Validated and successful are separate checks.
First confirm that the ledger result is final. Then verify that the transaction succeeded. Neither check replaces inspection of the actual payment fields.
| Field or status | What it tells you | What it does not tell you |
|---|---|---|
validated: true |
The result belongs to a finalized ledger. | Whether the transaction succeeded or matched your agreement. |
tesSUCCESS |
The transaction was successfully applied. | Whether it used the correct destination, amount, tag or memo. |
TransactionType: Payment |
The transaction used the Payment transaction type. | Whether the payment satisfied your expected instructions. |
| Transaction hash | The unique ledger transaction being inspected. | Whether the sender’s interpretation of it is accurate. |
The rule: a finalized success is necessary, but you must
still confirm that the successful transaction is the payment you expected.
Verify value received
Check the delivered amount—not merely the requested amount.
Transaction instructions can describe an intended amount. Transaction metadata records the outcome. When determining what reached the destination, inspect the delivered amount from the metadata.
Destination
Match the entire receiving address. A transaction sent somewhere else cannot satisfy the expected payment merely because the amount matches.
Delivered amount
Confirm the actual value credited to the destination. Do not assume that a displayed requested amount proves equal value was delivered.
Asset
Verify whether the payment delivered native XRP or another XRPL asset. Matching numbers in different assets are not equivalent payments.
Sender
When sender identity matters, compare the source account with the expected payer wallet rather than inferring identity from a message.
Associate payment with purpose
The correct address may serve many agreements.
Destination Tags and memos can connect a ledger payment to a specific customer, contract or purpose. They provide context used by applications and hosted payment systems.
Destination Tag
A Destination Tag is a numeric identifier. When required, compare it exactly with the tag provided by the payment workflow.
Memo
A memo can carry additional transaction context. Confirm any required value or identifier rather than treating all incoming payments alike.
Do not improvise payment instructions.
Copy the destination, tag, memo and amount from the active agreement. An
address or tag sent separately in chat may belong to another purpose.
Common mistakes
A real transaction is not necessarily the correct transaction.
Trusting a screenshot
Images do not establish ledger finality, delivered value or payment context. Inspect the actual transaction.
Checking success but not finality
A provisional response can change. Confirm that the result appears in a validated ledger.
Reading Amount instead of delivered_amount
The requested amount is not always the best evidence of what reached the destination. Use the transaction metadata outcome.
Ignoring the Destination Tag
A shared receiving address may use tags to distinguish agreements. The wrong tag can prevent correct off-ledger attribution.
Matching only the number
Verify the asset as well as the amount. Native XRP and issued assets use different representations.
Crediting the same transaction twice
Store or record the transaction hash so one successful payment cannot be reused as evidence for multiple obligations.
Official technical references
Verify the verification method.
These XRP Ledger Foundation resources document transaction finality, metadata, delivered amounts and Destination Tags.
Frequently asked questions
Verifying XRP payments.
How can I verify an XRP payment?
Look up the transaction hash using an XRP Ledger explorer or API. Confirm that it is validated, its result is tesSUCCESS and its destination, delivered amount, tag and memo match the instructions.
Does tesSUCCESS prove the correct payment was received?
No. It proves that the transaction succeeded in a validated ledger. You must still verify the destination, delivered amount and required payment context against the intended agreement.
Should I verify Amount or delivered_amount?
Use delivered_amount from transaction metadata to determine what value actually reached the destination. Do not rely only on Amount from the transaction instructions.
Why does a Destination Tag matter?
It can identify a particular customer, agreement or purpose when one XRPL address receives payments for multiple uses.
Proof over payment claims
Connect every funded agreement to verifiable ledger evidence.
Trustless Network uses agreement-specific payment instructions and ledger verification before work moves into its funded state.