Five fields, one screen
How to read your XRP transaction field by field
You can read your XRP transaction yourself, without waiting on anyone's support queue, because every field a deposit or withdrawal screen shows is either part of the public ledger record or a plain restatement of it.
You do not need anyone's help to read your XRP transaction. A deposit or withdrawal screen is showing you a small set of fields, each one either taken directly from the ledger or restating something the ledger already recorded, and once you know what each field is for, the screen stops being a mystery.
This page walks through those fields in the order they usually appear, and then covers the one question they are most often used to answer: whether a payment is genuinely stuck or simply not yet credited.
The destination address
The address a transfer was sent to. On the ledger, this is the account the payment belongs to, full stop — the ledger does not know or care which individual customer of that account the payment was meant for, which is exactly why the next field exists.
The destination tag
A numeric field, separate from the address, used when many depositing accounts share one address — a casino's own deposit address is a common example — so the receiving system can tell whose payment is whose. The ledger itself does not require this field to be filled in; whether it matters for a specific transfer depends on whether the destination account is shared. The full detail of what this field does and does not do is on the destination tag page.
The amount
The XRP amount that was sent. This is a ledger fact, verifiable independently of whatever a casino's own interface later displays as a converted dollar figure, and it is the number worth comparing against a block explorer if a displayed balance ever looks wrong.
The network fee, in drops
A small charge, measured in drops — the smallest unit XRP divides into, where 1,000,000 drops make one XRP — paid to the ledger itself rather than to any operator. This fee is unrelated to whatever a casino's own terms say about a withdrawal fee, and it appears on every transaction regardless of which account sent it.
Confirmation and ledger-close status
A status field showing whether the transfer has been included in a closed ledger yet. The ledger closes and settles a transfer in a few seconds, and once that status reads as settled, the ledger's own part of the job is finished — what happens next belongs to whichever system, wallet or operator, is watching that address on the other end.
Telling a genuinely stuck payment from one that is simply not yet credited
These look the same from the outside — nothing has changed on your screen — but they are different situations, and the fields above are exactly what separates them. If the ledger-close status still shows as unsettled, the transfer has not yet reached a closed ledger; that is a ledger-side state, and it resolves itself as the network processes it, independent of any casino.
If the ledger-close status shows the transfer as settled, but a casino balance has not reflected it, the ledger's own job is done — what is happening now is the operator's own process for recognising the transfer and crediting an account, which is a separate step this site does not attach a speed word to, because it is not a network fact and no operator's own document on file states a figure for it.
A payment that is genuinely stuck, as opposed to one that is simply working through an operator's own process, is a narrower and less common situation, with its own set of signs worth checking one at a time rather than assuming from a delay alone. That is covered in full on the stuck payment page.
A worked example: reading your own XRP transaction end to end
Say a transfer is sent to a casino's published deposit address, with a destination tag attached because that address is shared among many depositors. The five fields above tell the whole ledger-side story of that transfer without needing anyone's help: the destination address confirms which account it was for, the destination tag confirms which depositor within that account it was for, the amount confirms exactly how much XRP moved, the network fee confirms the small, fixed charge paid to the ledger itself, and the ledger-close status confirms whether the network considers the transfer final.
None of those five fields say anything about a dollar value, because the ledger itself has no concept of one — that conversion, where it happens, is a separate step covered on conversion. None of them say anything about an operator's minimum deposit either; that is a cashier rule, not a ledger fact, and it sits in that operator's own document rather than in the transaction itself. Bitcasino.io's help-centre table, for instance, prints a 0.31 XRP minimum deposit — a fact worth knowing before sending a transfer, but not something any of the five fields above will show you after the fact.
Once you can read your XRP transaction this way, field by field, a support conversation becomes much narrower and more useful. Instead of asking generally whether a deposit “went through,” you can state plainly that the ledger-close status shows settled, the amount matches what you sent, and the destination tag was included correctly — which leaves the operator's own crediting process as the only remaining question, and the only one that operator's own support desk can actually answer.
What the fields cannot tell you
The five fields above are complete for what they cover, but they do not cover everything a reader might want to know about a transfer. They will not tell you how long an operator's own crediting process typically takes, because that is not a ledger fact and this site does not print a speed figure for any operator without a dated document behind it. They will not tell you whether an operator's own document names XRP in a deposit or withdrawal list at all — that is a separate research question, covered by the meter described on what best means here, not something visible on a transaction screen.
They also will not resolve a dispute about a casino's own internal accounting, such as whether a balance was converted at the right rate or credited to the right account. The five fields settle exactly one kind of question — what happened on the ledger — and knowing where that question ends is as useful as knowing how to answer it.
Knowing the boundary also changes what is worth writing down before contacting anyone. A note of the destination address, the amount, the ledger-close status, and the time you sent the transfer is a complete, checkable record of the ledger side of events. A note of what a casino's own screen showed at the same moment, and when it changed, is the matching record for the operator side. Keeping the two separate, rather than one merged timeline, makes it far easier to see exactly where a gap between them, if any, actually sits.
Why you can read your XRP transaction yourself, in five minutes
Every field above is either public, on the ledger itself, or a plain restatement of something public. That means a support queue is not the only place to find out what happened to a transfer — a block explorer showing the same address, amount, and status will tell you the ledger side of the story directly, and comparing that against what a casino's own screen shows is usually enough to tell which of the two clocks — the ledger's or the operator's — is the one still running.
Cross-checking a stuck payment against what an operator's own document promises starts at best ripple casinos.