Deposit screen off your estate
The player pays on the hosted page. Your server still receives the signed result. Payouts cannot use this path.
Build · deposits and payouts
Payment gateway integration for a gaming platform.
The build page for eligible casino, betting and gambling products. It covers how the connection is made. It does not resell the cashier, the sportsbook or the gambling deposit story.
Two ways in
Hosted payment page or server API.
Deposits have two entrances. Payouts have one. A hosted payment page can collect a player deposit and still must send the signed result to your server. The server API lets your own cashier create that deposit. Player payouts never use the hosted page: the backend calls the payout API, with its own notification URL, its own limits and its own idempotency key. Plan them as two integrations even when the commercial conversation treats them as one switch.
Your cashier, your backend
Deposits and payouts are separate API integrations. Keys stay on the server, with the apikey header and the project identifier.
No storefront script
There is no drop-in theme for a shop. Gaming platforms connect from the backend.
Notifications
Webhooks, errors and repeat events.
Verify the postback signature with the configured private key. Treat a repeated notification as the same payment. Map Pending, Success, Failed and Rejected into the ledger. Do not credit from the return URL. A signature that fails is an error to log and reject, not a payment to apply. Store the raw result only after the signature checks out, and keep the merchant reference as the idempotency key for both deposits and payouts.
Receive
Accept the notification on the URL you registered for deposits or for payouts.
Verify
Check the signature before you trust the body.
Apply once
Idempotency on the merchant reference stops a double credit.
Before production
A separate test project.
Integration starts with its own API key and project identifier. Statuses can be set on request, so success, failure, pending and duplicates are exercised before a player sees production. Run the hosted deposit, the server deposit and the payout call as three cases. A test that only returns the browser to a thank-you page has not proved the ledger.
Poll availability
Read direction and amount limits on a schedule. Hide a method that is closed.
Lost payment
The search request is for the player who says a deposit never arrived. Poll the result.
CSV reconciliation
Daily files match payment references to the operator ledger. They are not a second integration.
Go live
Checklist before real transactions.
Eligibility closed
Entity, game category and partner approval are done. Methods are the ones that were approved, not a wishlist.
Keys swapped
Test credentials are replaced with production credentials. Notification URLs point at production.
Cashier reads live data
The method row comes from the route list. Hardcoded logos are gone.
Payouts proven apart
Withdrawal calls were tested on their own, not assumed from the deposit flow.
Product context stays on the specialised pages: gambling deposits, the casino cashier, sportsbook methods, and the operator category.