A successful submission response can still be provisional
XRPL distinguishes a preliminary submission result from an outcome recorded in a validated ledger. A tentative success does not settle the question of whether the intended payment succeeded. Conversely, an initial problem does not always establish a final failure. Read the status in the context of the particular transaction, rather than treating every green wallet notification as the same event.
For a person funding an exchange, the practical consequence is simple: uncertainty about the first payment is not proof that a second payment is necessary. Keep its transaction hash and inspect the final record through the walletโs supported history or an appropriate ledger viewer. Do not create another transfer merely to make a pending display disappear.
What each piece of evidence establishes
| Observation | What it supports | What remains unproven |
|---|---|---|
| Submission returned tesSUCCESS | A tentative execution was successful at submission | Final inclusion and the resulting payment outcome |
| A transaction hash is displayed | You have an identifier to investigate | That the intended XRP transfer completed |
| Record is validated with tesSUCCESS | The transaction has a final successful ledger result | That a separate SOL payout has already happened |
| Validated record contains a tec-class result | The transaction has a final failed result | A successful delivery of the intended exchange deposit |
| A viewer cannot find the hash | That viewer did not return the record | Final failure across all relevant ledger history |
Resolve the original transfer before deciding what to do next
- Identify the exact XRP payment
Retrieve its hash from the sending wallet or withdrawal history. An exchange order number is a different identifier. Note which service supplied the displayed status, because a local wallet message and a final ledger record answer different questions.
- Read validation and execution together
A validated flag indicates a final ledger context; the transaction result tells you whether execution succeeded. Do not stop after spotting only one of those fields. If the interface hides the detail, use its supported transaction view or ask the wallet provider to explain the specific record.
- Compare a successful payment with the order instruction
After establishing the final outcome, check the actual destination and applicable recipient detail against the intended order. A final successful transaction sent elsewhere does not prove that this exchange deposit was funded. Keep the amount and network context attached to the same record.
- Escalate the unresolved stage without a duplicate deposit
Provide support with the order reference, XRP hash and the observed status. If the deposit is identified but the issue concerns SOL delivery, ask for the payout reference separately. Do not merge the funding and receiving legs into one alleged confirmation.
If the result remains unclear
- A missing record is a limited observation
- XRPL documentation explains that a server may not hold every ledger needed to resolve an older transaction. A not-found response alone does not establish permanent failure. Ask the sending provider to reconcile its history before treating the amount as safe to resend.
- Keep diagnostic requests read-only
- A request for a hash or a status explanation does not require sharing a seed phrase, private key or signing a new payment. Clarify the existing event first. This page does not prescribe transaction replacement, sequence changes or a fixed waiting period.
Questions about XRP payment status
- Does tesSUCCESS immediately prove my XRP deposit completed?
- A tentative submission result does not. Establish the validated ledger outcome and compare the payment with the intended order instruction.
- Is a validated transaction always a successful payment?
- No. A validated ledger can also contain failed transactions with tec-class results. Read the execution result as well as validation.
- Should I resend because a viewer cannot find the hash?
- Not on that observation alone. Its available ledger history may be incomplete. Ask the sending provider to resolve the original transaction first.
XRPL documentation
Reviewed: