Separate callNot the hosted deposit page
Payouts are server-to-server. Plan them as a second integration.
Casino cashier · India
Casino payment gateway for session deposits and withdrawals.
Built for eligible casino and poker-room operators. The cashier problem is a player topping up during a session and later withdrawing winnings. A sportsbook slip is a different page.
Deposits
How an online casino payment gateway takes a deposit.
A casino deposit is often a mid-session top-up, not a one-off checkout. The cashier should show only routes that are open, create the payment from the server, and wait for Success before the balance moves.
Cashier · deposit
Method shownOnly if the route list says it is open
LiveAmount checkedInside that route’s minimum and maximum
OkPostbackSignature checked on the server
SignedBalanceCredits on Success only
SuccessWithdrawals
Player withdrawals leave through the payout API.
Casino winnings are not paid by reusing the deposit page. The payout call has its own limits and notification. Your cage or risk team still decides whether a withdrawal is allowed. The gateway reports the payment state.
Separate call
ReferenceKeep the withdrawal id
Store it next to the player account so support can trace a delayed cash-out in reports.
Cashier mix
Payment methods for online casinos.
Where the casino is approved in India: UPI, UPI QR, UPI links, PhonePe, Paytm and IMPS. Each method has its own direction and its own amount band, and any of them can be switched off without a site release. The cashier reads that list. It does not ship a fixed row of logos. Poker cash games and tournaments use this same cashier. There is no separate poker gateway page, because the payment job does not change.
₹UPI
▣UPI QR
⌁PhonePe
◉Paytm
↗IMPS
During play
The cashier during an active casino session.
A casino deposit is often a top-up while a game is open, not a checkout that ends the visit. The cashier should already know which routes are open, which amount band each route allows, and that a return to the game lobby is not a receipt. Credit the session balance only after Success.
If the player closes UPI before the notification arrives, leave the balance where it was. Do not hold a seat, a bonus, or a pending stake against money the gateway has not confirmed. A later Success can still credit that same payment. A Failed or Rejected result means the player starts a new deposit if they still want to play.
Open routesRead before you render
UPI, UPI QR, UPI links, PhonePe, Paytm and IMPS appear only when the live list says the direction and the amount are allowed for this casino.
Mid-sessionThe game does not confirm money
Returning to the table is a navigation event. The signed postback is the payment event.
Amount bandPer method, per cashier
A minimum that fits IMPS may not fit a UPI link. Check the route before the player types a chip amount.
Same cashier
Poker cash games share this casino cashier.
Poker rooms do not get a second gateway URL. Cash-game buy-ins and tournament entries are still player deposits into a casino-style cashier, and cash-outs are still payouts. The payment job does not change because the table has blinds or a prize pool.
What does change is your own product rule: when a buy-in is allowed, when a tournament entry can be reversed, and when winnings become withdrawable. Those rules stay in the poker room. The gateway only reports whether the deposit or the payout reached Success. A sportsbook slip is not this cashier. That timing problem lives on the betting payment gateway.
A deposit with a table rule
Create the payment first. Seat the player after Success, not when the UPI app opens.
Entry is still a deposit
If the entry is rejected by your room, that is your ledger. It does not rewrite a payment that already succeeded.
Payout API, not the buy-in page
Winnings leave through the server payout call, with its own reference beside the player account.
Status
Real-time transaction status before the balance moves.
The cashier and the finance ledger need the same four results: Pending, Success, Failed and Rejected. Pending means the session balance waits. Success is the only credit. Failed and Rejected close that attempt. A repeated notification with the same merchant reference must not credit the player again.
Deposits can be opened on a hosted payment page or from the server API. Either way the result comes back to your server. Player withdrawals never reuse the hosted page. They are a second integration, with a separate notification URL and separate limits. Map both into the cashier so support is not reading a deposit status to explain a missing cash-out.
Hosted pageDeposit screen off the casino
The player pays there. Your server still waits for the signed result before the chips appear.
Server APIYour cashier stays in place
The backend creates the deposit. Keys stay on the server, with the project identifier.
Payout callA different status line
A successful deposit does not predict the withdrawal. Store the payout reference on its own.
Disputes
Chargeback evidence is a record, not a product.
Keep the payment reference beside the player account and the session it funded. That is what support needs when a deposit is challenged: who played, which method was used, and which status the gateway confirmed. This page does not sell chargeback insurance, a win rate, or a promise that a dispute will close in the casino’s favour.
The same record helps when nothing was disputed and the player simply cannot see the chips. Submit the transaction to the lost-payment search and poll the result. Daily CSV reports are how finance agrees the cashier ledger with the gateway. They are not a second way to take payments.
Reference next to the account
Without that pair, a challenge becomes a story. With it, support can show the status the server accepted.
The deposit that never showed
Poll the search. Do not credit from a screenshot while the result is still open.
Cashier against the file
Match deposits and payouts on separate lines. A missing row is a search, not an assumed Success.
Boundary
What this casino payment gateway does not grade.
The gateway does not decide game results, bonus wagering, or whether a withdrawal clears your cage rules. It reports payment state after you have already decided the player may deposit or may be paid. Eligibility, age and geo checks sit in the casino. Prohibited online money gaming and unlawful wagering are not onboarded.
Sportsbook deposits and in-play top-ups are a different problem, because the market can move before Pending becomes Success. That page is the betting payment gateway. Shared build steps, including the test project, are on payment gateway integration. The category map sits on iGaming payment solutions.
Not a cageYour team releases winnings
The payout API sends the money you already approved. It does not approve the player.
Not a fundNo pooled player balance here
This is gateway technology. It is not a payment aggregator and it does not claim to hold casino funds.
Frequently asked
Questions from a casino cashier brief.
From the signed notification to the operator server, after the status is Success. The player returning to the cashier is not confirmation.
Yes. Poker cash-game and tournament deposits share the casino cashier flow. A separate poker URL is not offered because the payment job is the same.
The operator backend calls the payout API after the cage or risk team allows the withdrawal. The hosted deposit page is not reused. The gateway reports Pending, Success, Failed or Rejected for that payout.
The payment reference beside the player account and the session. That record is the evidence. This page does not sell chargeback insurance or a guaranteed outcome.