Deposit & Withdrawal Approvals

What it does

Two independent queues — one for deposits, one for withdrawals — where pending transactions wait for a staff decision. Confirming a genuine deposit credits the player’s wallet; approving a withdrawal releases their money. Each queue is a separate menu with its own permission, so deposits and withdrawals can be staffed by different teams.

Where to find it

Transaction → Deposits and Transaction → Withdrawals

Common tasks

Deposits

Open Deposits. It opens on the Non-QR tab — the deposits an operator actually decides on.
Check the player’s proof of payment against your receiving account before approving.
Approve to credit the wallet, or reject and choose a reason — the player is notified either way.
The QR tab is for monitoring only: QR/PSP deposits settle automatically through the payment callback, so their rows carry no approve or reject action.

Abandoned deposits

A player cannot cancel a Non-QR deposit themselves, and it never expires on its own. A player may hold only one pending deposit at a time, so a deposit they started and never paid blocks them from making another until you decide it.

Reject a Non-QR deposit when the player tells you they will not pay it, or when it has sat with no payment in your receiving account. Rejecting frees the player to deposit again straight away. The player’s deposit screen tells them to contact customer service to cancel, so expect these requests through your support channel.

QR/PSP deposits need nothing from you here: an unpaid one expires by itself and the player can then deposit again.

Withdrawals

Open Withdrawals - a single queue of withdrawals waiting on an operator, plus any payout waiting on its gateway (see below).
Confirm the request is valid, then approve and choose how to pay it out (see below), or reject with a reason.

Reject reasons

Every reject needs a reason. Pick the one that matches what you found; the note under it is for the details (which slip, which accounts) and is optional except for Other. The reason and the note are recorded on the transaction’s history.

Reasons come in two groups, and the difference matters: fraud is counted apart from everyday problems, so do not pick a fraud reason for a payment that simply could not go through.

Fraud - the player broke one of the fair-play rules shown on your terms page: linked accounts, hedging, betting over a bonus’s maximum bet, playing an excluded game with a bonus, a fake or reused slip, paying from or to someone else’s account, failed verification.
Operational - nothing the player did wrong: a bank or wallet you cannot pay, an account number that does not exist, a payment that never arrived, an amount that does not match its slip, a duplicate, a request to resubmit or to cancel, a payment gateway failure, or a mistake when the transaction was entered.

Deposits and withdrawals each offer only the reasons that apply to them. The agent API and MCP access keys follow the same rule: a reject without a reason is refused.

Choosing the payout route

When you approve a withdrawal, pick the Pay out via option:

One of your own bank accounts: you pay the player out of band (bank transfer, etc.), and approving marks it paid - the row goes straight to Disbursed. You must pick the account the money actually leaves by; the account is recorded on the transaction and is what the Company Bank column and the per-bank cash-out totals report. There is no generic “mark as paid” option: a payout with no account named cannot be matched against a bank statement later. If the list is empty, add a payout account first.
A payment gateway (e.g. AutoPeer, QPay): the gateway handles the payout automatically. The withdrawal shows PSP Processing until the gateway confirms settlement, then flips to Disbursed. Nothing is expected of you while it reads PSP Processing — the gateway is paying the player.

Before you decide, the withdrawal shows Awaiting Payout: the money is locked but still yours to send. The two labels are deliberately different — Awaiting Payout is a job on your desk, PSP Processing is a job on the gateway’s. The remainder case below is the one that comes back to you after a gateway has taken it.

The player receives the same amount whichever route you choose — they don’t pick the method.

A gateway only appears in the list once it’s switched on for withdrawals (Transaction → Payment Setup → Payment Gateway → enable withdrawals).

A payout waiting on its gateway

A gateway may be unable to take a payout yet: its payout balance does not cover it, or the destination bank is in a maintenance window. The withdrawal then waits, still PSP Processing, and is tried again by itself. It stays in the Withdrawals queue with the reason under its status, so a stuck payout does not disappear from your view. It is not counted in the number beside the menu: there is nothing to decide, and it goes out by itself.

Its only action is Retry now, which tries the payout on the next payout run instead of waiting for the scheduled retry. It is never sent twice. Once that try is due the button goes away: the row leaves the queue when the gateway takes the payout, or offers Retry now again if it still has to wait.

These rows have no approve or reject, and they must not be paid by hand: the gateway will send the money.

Settling a P2P remainder

P2P gateways like AutoPeer match a withdrawal against other players’ deposits. Sometimes only part of it matches automatically — the matched part is paid to the player by their match, and the unmatched remainder is handed back to you to pay.

These rows show Awaiting Remainder in the queue. To finish one:

Pay the remaining amount to the player out of band (the row shows how much).
Click Settle remainder and confirm. This marks the withdrawal fully paid.

You only ever pay the leftover — never the whole amount twice.

Sending a deposit slip to AutoPeer

AutoPeer deposits are peer-to-peer too: the player transfers straight to another player’s account and uploads the transfer slip themselves. When that upload fails — the wrong image, a timeout, a slip the check couldn’t read — the deposit sits unpaid even though the money already moved.

For those, you can send the slip on the player’s behalf. AutoPeer deposit rows carry a Slip button:

Click Slip to open the deposit’s slip panel.
Attach the player’s transfer slip (JPG, PNG, or WebP, up to 5MB), and add a remark if it will help whoever reads the row next.
Click Send to AutoPeer.

AutoPeer checks the slip and credits the player automatically — you never credit the wallet by hand. Every slip sent is listed in the panel with who sent it and when.

This only works while the deposit is still awaiting payment. Once it has been paid, failed, or expired, AutoPeer no longer accepts a slip for it and the panel tells you so — send the player through a fresh deposit instead.

Finding a payout by bank

On a withdrawal view, Payment Method offers only the rails a player’s bank can actually use - Bank Transfer and E-Wallet. It used to list every channel in the catalogue, including deposit-only ones that no withdrawal can match, so filtering by them returned nothing.

Two filters answer the questions that one could not:

Payment Gateway - who moved the money: manual for a payout you sent by hand, or the gateway that sent it (AutoPeer, MyPays24, and so on).
Company Bank - which of your own accounts a hand-paid withdrawal left by. Blank on gateway payouts and on rows with no payout decision yet; blank never means the money came from nowhere.

The Deposit / Withdraw report carries the same Company Bank column and filter, plus per-bank cash-out totals for reconciling against a bank statement - see that page for how those totals are scoped.

When two of you work the same queue

A decision takes effect the moment you click it: the row leaves the queue and the count beside the menu drops straight away, without waiting for the server. The confirmation message follows a moment later, once the money has actually moved.

On a deposit that carried a promotion, the bonus is granted just after the cash rather than in the same instant. A player who looks immediately can see the cash arrive first.

If a colleague decided the same row first, yours is refused - the row comes back into the queue with a message saying it has already been decided, and the list reloads - once your decisions have all landed - so you can see what is still waiting. Nothing is credited twice: a transaction can only be decided once, and the second click is turned away rather than applied.

Settling a remainder can be refused for a second reason: the remainder may already have been resolved while the row sat in your queue - by a colleague, or by the payout rail confirming it on its own. The message names both, because from the panel the two look the same.

Payout gate

Each row shows the payout gate’s verdict: Gate: pass, Gate: hold, or Gate: not evaluated. On a hold, the checks that did not pass are listed under it. Click the verdict to see every check with its reason and evidence, and Re-evaluate to run the checks again, for example after a player finished an open game.

The verdict never stops you approving or rejecting. It stops an API key (MCP access): a key can approve a withdrawal or a manual deposit only when the gate passes it. The checks and their limits are set on the Payout gate card in Withdraw Forms.