PayID deposit not showing at the casino: trace it without paying twice

First: is the money actually gone?

Open your banking app before you open a support chat, and read the status of the payment rather than the balance. Three statuses, three completely different situations.

• Completed. The payment left and settled. Something downstream is the issue, and the rest of this page applies.
• Pending or scheduled. The money has not gone anywhere. Nothing is wrong at the casino, and raising it with support just adds noise. Some banks hold a first-time payment to a new recipient, and a daily payment limit can defer one too.
• Failed, returned or reversed. The payment did not go through. The funds come back to you, usually within a business day, and you need to find out why it failed before re-sending — a bank-side gambling block is a common cause. See why your bank declined the casino payment.

This sounds obvious and it is where roughly half of these cases end. A balance that looks reduced in an app is not the same thing as a payment that settled, and "it says it's gone" usually means "the available balance moved", which happens on pending items too.

The fifteen-minute rule, and why a second payment is the worst move

Real-time payments usually credit in seconds, but a cashier's own reconciliation can run on a short cycle, and first-time payments to a new recipient are sometimes held briefly for checks. Give it ten to fifteen minutes from a completed status before treating it as a problem.

During those fifteen minutes, do not send a second payment. This is the single most expensive thing a reader does on this page, for reasons that compound:

• Now two transfers have to be traced instead of one, and both carry the same reference, so even a correct match becomes ambiguous.
• If the first one lands after the second, you are credited twice, and operators treat an unexplained double credit as something to investigate before paying anything out.
• If the reference was wrong, you have now made the same mistake twice, and the second payment does not fix the first.

If the money has to move today, the right escalation is a support ticket with the four fields below, not another transfer.

The reference string is what matches your transfer to your account

This is the mechanism, and understanding it makes everything else obvious.

A PayID or bank transfer is a push payment: you initiate it from your own bank, so the operator does not know it is coming. Nothing in the transfer identifies you to the operator except the data you typed — and the field that carries the identification is the payment reference, sometimes labelled description, message, or payment details.

The cashier generates that reference for your account, and it is normally unique to you, sometimes unique to that single deposit. Reconciliation is then a string match. Which is why:

• Adding a word, your name, or a note breaks the match at the operators that match exactly.
• Dropping a character, changing case, or removing a dash can break it.
• A reference generated for a previous deposit may not match a new one if the cashier issues them per transaction.
• An empty reference field leaves the operator with an amount and a sender name and nothing to tie them to.

Copy, never retype. If your banking app strips characters or limits the field length, say so in the ticket — the operator has seen it before and can match manually. The long-form version of this mechanism is on payment reference tracing and PayID casinos in Australia.

The four fields support needs, and the screenshot that holds all four

A ticket that contains these four things gets resolved in one exchange. A ticket without them produces three days of back-and-forth.

• The exact amount sent, to the cent, in the currency sent.
• The destination — the PayID identifier or the BSB and account number you paid to.
• The reference exactly as it was sent, including spacing and case. If it was blank, say it was blank.
• The timestamp, with the date and time your bank recorded, and the time zone if your app shows one.

One screenshot of the completed transaction detail in your banking app normally contains all four. Take that screenshot rather than typing the values out: a transcription error in a ticket about a transcription error is a long afternoon. Redact the rest of the transaction list if you prefer — none of it is relevant.

Then, word for word, something like: "A PayID transfer of A$[amount] completed at [time] on [date] to [destination] with the reference [reference]. It has not been credited to my account. Screenshot attached. Please confirm whether the payment has been received and, if the reference does not match, what it needs to be. I have not sent a second payment."

That last sentence matters more than it looks. It tells the agent there is exactly one payment to find, which is the information that makes a manual match safe to perform.

A blank reference and a wrong reference are two different fixes

Support will usually ask which it was, so work it out first.

A blank reference is the easier case. The operator has your sender name, the amount and the timestamp, and with the account identifier from you it can normally match manually. Expect it to take a business day rather than minutes, because a human has to do it.

A wrong reference is harder, and how hard depends on what kind of wrong. A typo in a reference belonging to your own account is usually matched without much trouble. A reference belonging to a different account at the same operator is a different problem entirely: the money may have been credited to someone else, and resolving that needs the operator to reverse an internal credit, which it will do slowly and reluctantly. This is the case that takes a week.

Either way, ask for the correct reference format for your next deposit in the same message, and save it. The fix for the next deposit is free; the fix for this one is not.

If support cannot match it: what your bank can trace

Where the operator says it has no record of the payment, the question moves to the banking rail, and your bank can do something the operator cannot: confirm where the money landed.

Ask your bank to trace the payment on the real-time rail. What comes back is the receiving institution and confirmation of settlement, which is exactly the evidence that resolves a dispute about whether the payment was received at all. It will not tell you which internal account at the operator was credited, and it will not reverse anything by itself.

The part readers most often get wrong: there is no chargeback on this rail. Card-style reversal does not exist for a push payment. What does exist is the mistaken-payment process under the ePayments Code, and its limits are specific — it applies to a payment credited to the wrong account because of the payer's error, it requires the sending and receiving institutions to agree, the receiving bank may then debit the recipient, and the funds may not be returned. It is not a route for a dispute about a service you paid for. Notify your bank as early as possible if a mistaken payment is what happened, because the chances fall as the money moves.

Keep the trace result, the ticket numbers and the screenshots together. If this ends in a formal complaint, those three items are the case — and there is no Australian regulator that recovers an individual balance, since the Interactive Gambling Act 2001 is administered by the ACMA against the supply of prohibited services rather than for releasing player funds.

When the problem is the recipient name, not the reference

PayID shows you the registered name of the account before you confirm, and that display is a check worth actually reading. If the name shown bore no relation to the operator — an unfamiliar company, an individual's name — stop and ask support to confirm the destination in writing before sending anything further. Payment details presented in a chat window, in an email, or by anyone who contacted you first are worth verifying against the cashier page itself.

The mirror-image problem happens on the way out: payouts go to an account in the account holder's name, and the name is compared as text, so abbreviations or a different word order on a bank record can fail a match that looks correct to you. That is covered on same-method withdrawals.

If the credited amount is right but smaller than you sent

This is not the same problem and it has a different answer. A deposit can arrive, be credited, and still be short — because a fee was deducted on credit, or because the balance is held in a different currency and the amount was converted.

Both are stated in the cashier rather than by your bank, and both are predictable before you send. The arithmetic and the clauses to look for are on deposit fees and the credited amount, minimum deposit after fees and AUD to USD deposit conversion. If the shortfall matches neither a published fee nor a plausible conversion, then it is a ticket — with the same four fields.

Practical questions

Related decisions