iGaming Payment Reconciliation: From Bet to Bank

Nothing in that sequence is necessarily wrong. The cashier event, internal wallet entry, processor settlement and bank receipt are four records of related activity—not four copies of one record. Reconciliation is the work of proving how they connect and explaining every difference that remains.

The four ledgers do not share one clock

An operator normally needs to align at least four views:

The rows rarely land at the same moment. A deposit may be authorised before it is settled. A weekend’s activity may be grouped into a later payout. A refund or chargeback creates a new financial movement after the original deposit. Fees and foreign-exchange adjustments can make the net settlement smaller than the gross value processed.

That is why “the deposits total £100,000 but the bank received £97,000” is not yet an exception. It is a reconciliation question. The gap needs to be decomposed into known fees, debits, timing differences, reserves or genuinely unmatched items.

Authorised, credited and settled are different states

Provider terminology varies, but the lifecycle principle is stable. Adyen’s reporting map separates states such as authorised and sent for settlement from settled, refunded and charged back. Its settlement report includes movements after capture, while its accounting report covers a wider part of the payment lifecycle.

An operator’s player ledger has another decision to make: when is the deposit available to the player? Some integrations credit only after a final provider event. Others may credit earlier under controlled conditions and later resolve a failed capture. That rule belongs to the operator’s cashier design and risk policy; a webhook name alone does not define it.

Our map of payment orchestration in iGaming shows how routing and callbacks sit between the visible cashier and the processor. Reconciliation tests the result after those paths have run. It should be able to distinguish a provider decline, a missed callback, a duplicated internal entry and a payout that is merely still in transit.

References are the spine of the match

The strongest reconciliation design carries an internal merchant reference into the payment request, preserves the provider’s unique reference on every later event and connects both to a batch or payout identifier.

Adyen’s transaction-level reconciliation guide tells merchants to use the PSP reference and merchant reference to identify a transaction. It also shows why one transaction can produce several entries: a gross credit, processing costs, a net credit and perhaps a later refund or chargeback.

Stripe uses a different object model. Its reporting and reconciliation documentation describes balance transactions as immutable records of everything affecting the Stripe balance. A refund creates a new balance transaction that negates the original rather than rewriting history. For automatic payouts, the payout parameter can retrieve the transactions included in the batch.

Checkout.com gives another implementation example: its guidance uses a unique payout ID to connect a settlement statement with the bank deposit. The provider’s bank reconciliation article describes that reference as the link between the financial report and bank account.

The field names differ. The control does not: no team should be matching payments by amount and date alone when stable references exist.

Net settlement is a calculation, not a missing balance

Suppose a processor batch contains deposits with a gross value of £10,000. The bank payout might include:

• the batch’s settled credits;

• less processing, scheme and interchange fees;

• less refunds and chargebacks booked into the batch;

• plus or minus adjustments or foreign-exchange effects; and

• a timing difference for payments not yet settled.

Adyen’s guide instructs merchants to add net credits and subtract net debits until the result equals the batch payout. Its worked structure identifies commission, markup, scheme fees and interchange separately. This is provider-specific documentation, but it illustrates why gross cashier volume should not be compared directly with bank cash.

Stripe’s payout reconciliation report similarly groups transactions into automatic payout batches and separates items not settled by the end of the reporting period. It also warns that instant payouts do not carry the same automatic transaction-to-payout identification, because the account holder controls their timing and amount.

The clean result is not “every day nets to zero”. It is “every movement is matched, classified or carried forward with an owner and reason”. An unsettled payment can be legitimate. An unexplained payment cannot stay unexplained indefinitely.

The player balance is not the bank balance

Gambling adds a liability layer that a generic merchant does not have in the same form. A customer may deposit, place an open bet, win, leave winnings in the account or request a withdrawal. Each action changes what the operator owes or may owe without necessarily causing an immediate movement in the acquiring bank account.

In Great Britain, the Gambling Commission’s customer-funds guidance includes cleared deposits held for future gambling and unpaid winnings within customer funds. It says stakes committed to open bets are not customer funds for those protection requirements. That is a regulatory definition for British licensees, not a universal accounting chart, but it makes the boundary visible: player money changes legal and operational state inside the product.

This is also why a withdrawal cannot be reconciled as the reverse of the original deposit. The amount may include winnings, the destination route may differ and account checks can happen before release. Our feature on why withdrawals take longer than deposits follows those separate clocks.

Exceptions need queues, not spreadsheets without owners

The practical output of reconciliation is an exception queue. Useful categories include:

• internal credit exists but no provider success event can be found;

• provider settled the payment but the player ledger was not credited;

• the same provider reference appears against more than one internal entry;

• a refund or chargeback is missing from the operator ledger;

• the processor batch balances but the bank payout is absent;

• currency, fee or rounding fields explain most—but not all—of a residual; and

• an event is still within the documented settlement window.

Each category needs an owner, ageing rule and source of truth. Payments operations may own provider-to-bank breaks. The cashier team may own callback and wallet mismatches. Finance may own fee and currency classification. Fraud or compliance teams may investigate particular cases, but an exception should not be labelled “fraud” merely because it is unmatched.

Reconciliation also needs replay. If a webhook is delayed or an internal consumer fails, the team should be able to rebuild the expected ledger state from durable provider records without creating a second credit. Stripe’s immutable balance-transaction approach is one example of why append-only financial events make that reconstruction easier.

A close is only as good as its evidence

A reliable daily or periodic process can answer four questions in order:

1. Did every player-ledger payment map to a provider transaction?

2. Did every provider financial movement map to an internal entry or documented timing item?

3. Did the net batch equal the payout reported by the provider?

4. Did that payout match the bank statement?

If the fourth answer is yes but the first is no, the cash may be right while a customer balance is wrong. If the first three are right but the bank entry is missing, the player experience may be intact while treasury has a settlement problem. Those are different incidents with different urgency.

Payment reconciliation is therefore not the last spreadsheet after the “real” payment work. It is the control that proves the cashier, ledger, processor and bank are describing the same economic activity—each at its own level, with no unexplained money between them.