Skip to main content
Structure / Money movement

Payments intelligence

A deposit and a withdrawal are not mirror images. They travel similar rails in opposite directions, but the return leg passes through checks that have no counterpart on the way in — which is why the two feel so different to the person waiting.

Withdrawal and payment disputes The evidence checklistHow the industry stack is built

01Definitional diagram

The deposit path and the withdrawal path

A generic model of the roles involved in moving money to and from a gambling account. It names no company, describes no specific arrangement, and reports no figure — it exists to give the parties in a dispute their proper names.

The deposit path and the withdrawal pathDeposits travel from the player, through the payment method, through a payment service provider or acquirer, to the operator wallet. That same wallet is where the outbound leg begins: a withdrawal request is queued against it, then passes a bonus and wagering check, an identity and source-of-funds review, and a payout approval step, before reaching a payment service provider or acquirer and finally the player. The three checks in the middle of the withdrawal path have no counterpart on the deposit path, which is what makes the two directions asymmetric. The travelling highlights show the direction of each leg and nothing else — no rate, duration or volume is depicted. Both legs are written out in full beneath the diagram.DEPOSIT — INBOUNDPlayer instructs a payment — You choose a method — card, bank transfer, wallet or voucher — and authorise a sum. Authorisation is normally immediate and, on most methods, instantly reversible only through the provider, not the operator.PlayerInstructs paymentThe payment method issues it — Your bank, card issuer or wallet provider authorises the transaction against your available funds and applies its own limits and fraud rules.Payment methodCard · bank · walletA processor or acquirer routes it — A payment service provider or acquiring bank sits between the method and the merchant, converting a consumer payment into a merchant settlement. This party is usually invisible in the interface and is frequently not named anywhere the player sees.PSP / acquirerRoutes and settlesThe operator wallet is credited — The balance appears in the account. The credit is generally applied on authorisation, before the money has actually settled to the merchant — which is why deposits feel instant.Operator walletBalance creditedWITHDRAWAL — OUTBOUNDWithdrawal requested — The request is created against the account balance. On most platforms this is a queued instruction, not a transfer: nothing has left anywhere yet.Operator walletRequest queuedBonus and wagering check — The balance is tested against any promotional conditions attached to it. Where part of a balance is restricted, part of a withdrawal can be held while the rest proceeds.Bonus checkWagering conditionsNO INBOUND EQUIVALENTIdentity and source-of-funds review — Verification is often triggered by the first withdrawal rather than at sign-up, so a check that could have happened months earlier lands at the point of payout. Documents are requested, reviewed and sometimes re-requested.Identity reviewKYC · source of fundsNO INBOUND EQUIVALENTInternal approval and payout batch — An approved withdrawal joins a payout run. Batch timing, cut-offs and weekend processing are operator-side decisions that the player cannot see and normally cannot query.Payout approvalBatch and cut-offNO INBOUND EQUIVALENTProcessor or acquirer executes it — The same class of intermediary that handled the deposit pays out, sometimes on a different rail and sometimes not the one the deposit arrived on. A payment can stop here, at a party the player has no relationship with.PSP / acquirerExecutes payoutFunds reach the payment method — The receiving bank, card scheme or wallet posts the credit on its own schedule. Until it does, the money is in transit and neither end can point to where it is.PlayerCredit postedTHE SAME WALLET — WHERE THE INBOUND LEG ENDS, THE OUTBOUND LEG BEGINSTHE ASYMMETRY — THREE GATES WITH NO DEPOSIT-SIDE COUNTERPARTDEFINITIONAL MODEL · ROLES ONLY · NO COMPANY, TIMING OR FEE IS DEPICTED · MOTION SHOWS DIRECTION, NOT SPEED
Roles, not companies. One organisation may occupy several of these roles at once, and a single deposit may cross more intermediaries than are drawn here. The asymmetry is the point: the outbound leg carries checks the inbound leg does not. The highlight travelling each lane shows the direction money moves and nothing more — the speed it moves at is drawn identically on both legs, because this platform has measured neither.
Deposit — the inbound leg
  1. 01

    Player instructs a payment. You choose a method — card, bank transfer, wallet or voucher — and authorise a sum. Authorisation is normally immediate and, on most methods, instantly reversible only through the provider, not the operator.

  2. 02

    The payment method issues it. Your bank, card issuer or wallet provider authorises the transaction against your available funds and applies its own limits and fraud rules.

  3. 03

    A processor or acquirer routes it. A payment service provider or acquiring bank sits between the method and the merchant, converting a consumer payment into a merchant settlement. This party is usually invisible in the interface and is frequently not named anywhere the player sees.

  4. 04

    The operator wallet is credited. The balance appears in the account. The credit is generally applied on authorisation, before the money has actually settled to the merchant — which is why deposits feel instant.

Withdrawal — the outbound leg
  1. 01

    Withdrawal requested. The request is created against the account balance. On most platforms this is a queued instruction, not a transfer: nothing has left anywhere yet.

  2. 02

    Bonus and wagering check. The balance is tested against any promotional conditions attached to it. Where part of a balance is restricted, part of a withdrawal can be held while the rest proceeds. This step has no counterpart on the inbound leg.

  3. 03

    Identity and source-of-funds review. Verification is often triggered by the first withdrawal rather than at sign-up, so a check that could have happened months earlier lands at the point of payout. Documents are requested, reviewed and sometimes re-requested. This step has no counterpart on the inbound leg.

  4. 04

    Internal approval and payout batch. An approved withdrawal joins a payout run. Batch timing, cut-offs and weekend processing are operator-side decisions that the player cannot see and normally cannot query. This step has no counterpart on the inbound leg.

  5. 05

    Processor or acquirer executes it. The same class of intermediary that handled the deposit pays out, sometimes on a different rail and sometimes not the one the deposit arrived on. A payment can stop here, at a party the player has no relationship with.

  6. 06

    Funds reach the payment method. The receiving bank, card scheme or wallet posts the credit on its own schedule. Until it does, the money is in transit and neither end can point to where it is.

02Live counts

Payment-related case files

All case files

Published case files whose issue category describes a failure of money movement. Each figure is a count of rows in the record set at the moment this page rendered — none is estimated, projected or rounded.

No published case file currently sits in a payment-related category. A private report becomes a public case file only after reviewer verification, redaction and the reporter's explicit consent — an empty count reflects what has cleared publication, not what has been reported.

03Published work

Payment analysis

All payment analysis

GambleLABS’ own writing on routing, intermediaries, settlement and the mechanics of a stalled payout.

04Next

If a payment has stopped

Disputes

Delayed, blocked, or somewhere in between

What separates a withdrawal that is queued from one that has been stopped, why an intermediary makes a two-party dispute into a three-party one, and what a dispute needs before anyone will look at it.

Withdrawal and payment disputes

Evidence

What to preserve, and when

A structured, printable checklist organised by category, with the reason each item matters. Capture it before you complain — account access is frequently lost afterwards.

The evidence checklist

Report

Put it on the record

A report to GambleLABS is private by default and cannot recover funds. What it does is make a pattern visible across operators, intermediaries and jurisdictions.

Encrypted at restConsent required to publish
Report a case