Casino wallet reconciliation matches the entries in a player's account with the payment service provider's records and the operator's bank statement. The totals need an explained bridge, rather than forced equality: bets change the wallet, payment fees change settlement, and money can cross a reporting cut-off while still in transit.
This guide is for casino finance, payments and platform teams investigating an unexplained balance. It uses an invented transaction set and named documentation checked on 19 October 2026. It does not audit an operator, recommend a processor or replace accounting and jurisdiction-specific compliance advice.
What the three records actually measure
The player ledger records account movements. In Great Britain, UK Gambling Commission RTS 1 requires accessible balance and transaction information, including relevant deposits, withdrawals and gambling results. That customer-facing history is not the operator's bank statement. The British requirements should not be assumed to apply worldwide.
A PSP journal records payment events and the amounts owed between the provider and merchant. Bank records show booked cash movements. An authorised payment and a settled payment are different stages in Adyen's documentation; even its Settled status does not by itself establish that the merchant has received a payout.
The practical starting point is therefore one identified operation across its records. A total labelled "deposits today" cannot be compared meaningfully with an unidentified bank credit covering another batch or period. The PAM system supplies account context; the reconciliation must still establish the corresponding external payment.
A small casino wallet reconciliation example
Assume one cash-only player account starts at £0. A confirmed £100 deposit is credited, a £20 stake is booked, and the completed game returns £35 including the stake. The resulting wallet balance is £115: £100 minus £20 plus £35. These invented amounts illustrate bookkeeping, not an expected gambling return.
The player then requests £40. Our model moves that amount into a pending-withdrawal bucket, leaving £75 available. The provider debits £40 for the outgoing payment, but the transfer is subsequently returned. Once that return is confirmed and reconciled, the £40 is restored to the available balance. This is a failed external payment, not a feature allowing the player to cancel a pending withdrawal.
The table uses generic event descriptions, not a claim about every provider's API. The model assumes that all external entries below are included in one completed reporting batch, in GBP, with a single invented £2 merchant fee. There are no bonuses, foreign-exchange conversions, reserves, chargebacks or other transactions.
| Event | Available wallet | Pending withdrawal | Provider-side entry assumed in the example |
|---|---|---|---|
| Deposit confirmed and credited | £100 | £0 | £100 incoming credit |
| £20 stake booked | £80 | £0 | No external payment |
| £35 gross game return credited | £115 | £0 | No external payment |
| £40 withdrawal reserved | £75 | £40 | No completed debit yet |
| Outgoing payment debited | £75 | £40 | £40 debit |
| Failed payment returned and wallet restored | £115 | £0 | £40 return credit |
| Merchant processing fee booked | £115 | £0 | £2 fee debit |
The provider-side batch bridge is £100 minus £40 plus £40 minus £2, giving £98. Its later transfer to the operator's bank account produces one £98 bank credit in this model. Do not count that merchant payout as another customer deposit. It moves the reconciled provider balance into the bank.
The £115 player balance and £98 bank credit answer different questions. The first includes a £15 net game result; the second is a cash movement after a £2 fee. We have deliberately not specified the operator's opening bank balance. This example cannot establish whether total customer liabilities are adequately funded.
Link operations before comparing totals
Keep the internal payment identifier connected to the provider's transaction reference, any subsequent modification and the settlement batch. Then connect the batch payout to its bank reference. A withdrawal return needs a link back to the original outgoing payment; a new credit of the same amount is insufficient evidence on its own.
Adyen's Settlement details report provides a concrete reporting example. It distinguishes merchant and PSP references, gross and net amounts, and modification references. Its MerchantPayout entry identifies the transfer to the merchant's bank, with a payout reference and batch information that can be matched to the statement.
Those fields illustrate the evidence to request from a provider. They do not establish that Adyen supports a particular casino, licence, country or payment method. The contract and actual integration determine the available reports and identifiers.
For each reconciliation run, retain:
- The legal entity, merchant account, currency, period and reporting time zone.
- The wallet entry and its internal payment or game-round identifier.
- The provider reference, event type, related modification and batch.
- The bank booking, payout reference and explanation of each remaining difference.
- The exception owner, next review point and evidence supporting closure.
Separate timing differences from missing postings
Start by checking the reporting basis. A wallet event time, provider booking time and bank value date can fall on different days. Adyen's report uses the account's configured time zone and separates transaction creation from optional booking-date fields. A cut-off difference should be documented and followed into the next relevant report, rather than removed with an unsupported adjustment.
Next separate gross amounts from fees and other batch adjustments. The £2 fee in our model belongs to the merchant's settlement bridge; we explicitly assumed no corresponding player fee. Its existence does not justify silently reducing the player's £115 balance. Real reports can contain additional entries, so a convenient gross-minus-fee formula is not a complete reconciliation policy.
Finally check event completeness and duplicate postings. Has one confirmed deposit been credited twice internally? Does a returned payment have a linked wallet correction? If the provider shows only a request or an intermediate status, record the unresolved state. A timeout or an absent bank line does not establish the outcome. The payment-orchestration guide covers routing and uncertain responses; this check follows the resulting accounting entries.
Treat a residual difference as an exception with an explanation or an investigation, not as revenue. Settlement evidence should determine the correction. Preserve the original entry and the linked adjustment so another reviewer can reconstruct the decision.
A pending withdrawal can remain a liability
Available-to-play cash and the amount owed to customers can diverge. The British regulator's customer-funds segregation guidance says funds in transit to a customer must remain in the customer-funds calculation until received. Reducing the visible available balance is therefore not, on its own, evidence that the liability has ended.
In our model, the pending stage has £75 available and £40 still owed through the withdrawal process. After the confirmed return, the pending bucket is cleared and the £115 becomes available again. The reversal changes where the obligation is recorded; it does not create £40 of new income.
Reconciliation also does not certify insolvency protection. Questions about eligible accounts, segregation and total coverage need a separate review under the applicable licence and arrangements. See the distinction between customer-funds segregation and insolvency protection.
Frequently asked questions
Should the player wallet equal the bank balance?
No. A player balance is one account-level obligation, while a bank statement records cash across the relevant account and period. Gambling results, fees, pending payments and other customers can all affect the bridge. Compare identified entries and their reporting scope before deciding that a difference is an error.
Does a PSP's settled status mean the bank has been credited?
Check the provider's definition. Adyen distinguishes receipt of funds by the processor from payout to the merchant. Its settled status is therefore insufficient proof of a merchant bank credit. Use the settlement batch, payout record and bank booking together, rather than treating a status label as a bank receipt.
What should happen when a withdrawal payment is returned?
Confirm the return and its connection to the original payment, then follow the operator's documented correction process. The worked model restores the reserved £40 once and retains both references. A missing bank entry alone does not prove a return, and the example does not promise when a customer will receive another payment.
Close with an explained balance
An explained reconciliation ends with traceable postings and a defined list of unresolved items. Before closing a batch, make sure someone can follow the same operation from the wallet to the provider and, where cash moved, to the bank.