iGaming payment gateway integration does not start with API credentials. A licensed operator first needs to answer four questions:
- which licence it holds;
- which markets it serves;
- which payment methods and acquiring are available for that licence and those markets;
- whether a payment provider will approve the business.
Only then does the work move to the checkout, payment confirmation and reconciliation. One distinction runs through the whole project: deposits and withdrawals are separate workflows, often on separate rails under separate rules. This checklist follows that order, from the licence to the first live deposit.
What iGaming payment gateway integration actually involves
iGaming payment gateway integration connects an operator’s cashier to one or more payment providers so that player deposits are authorised, confirmed and recorded against the right account, within the rules of the operator’s licence. Different parties usually own each layer of that flow.
Gateway, PSP, cashier and orchestration layer: who does what
| Layer | What it does | Usually owned by |
|---|---|---|
| Cashier | Deposit and withdrawal screens, limits, player balance | Operator or its platform |
| Payment gateway / PSP | Takes the payment and returns its result and status | Payment provider |
| Acquirer | Connects the merchant to the card networks and settles card funds | Acquiring bank, usually via the provider |
| Orchestration layer | Coordinates several providers and the rules between them | Operator or a specialist vendor |
A gateway is not a cashier, and an orchestration layer is not a gateway. Many operators run several providers behind one cashier.
Why API keys are not the start of integration
Live API credentials normally follow a provider’s approval of the business, once the provider and its acquiring partners have confirmed that they can support the licence, the markets and the business model. Building first and applying second risks integrating a method the operator cannot use in its main market.
Start with the licence and the markets you serve
Licence and geography can decide whether a payment method is available to an operator before any technical integration begins.
Gambling coding and MCC 7995
The Visa Core Rules require an online gambling merchant to hold a valid licence or other appropriate authority. Its transactions must be identified with merchant category code 7995, even when gambling is not its main business. Several regions, including the US and Canada, also require a quasi-cash/online-gambling indicator.
Visa classifies card-absent MCC 7995 as high integrity risk, so an acquirer needs a specific Visa registration, must register each such merchant and must monitor it daily. Issuers act on the code too, and Visa’s rules let them block gambling on commercial cards. Operators should confirm with their provider how transactions will be coded. Our guide to merchant category codes for high-risk businesses explains how codes are assigned.
Market rules that change the payment flow
- Great Britain. UK Gambling Commission licensees must not accept payment for gambling by credit card, including credit-card payments routed through a money service business such as an e-wallet. The rule has applied since 14 April 2020. Debit cards are not covered by the ban.
- United States. Legality is decided state by state. Under Regulation GG, card systems use merchant and transaction codes to identify and decline possibly unlawful gambling transactions, and banks typically ask for the state licence.
- Elsewhere. Some regulators, such as Germany’s, can direct payment providers to stop processing for unlicensed operators.
Each rule changes the build, and provider coverage of any market is confirmed operator by operator.
Commercial approval comes before technical integration
Licensed operators should confirm market and acquiring eligibility with a payment provider before development starts, because live credentials follow approval rather than precede it.
A provider’s review typically covers:
- the licence and its scope;
- the target markets;
- company verification (KYB): registration, directors and beneficial owners;
- the business model and expected processing.
What an iGaming operator has to evidence includes its licence and responsible-gambling policy. Preparing the application documents early means the required information is ready when the provider starts its review.
On Niftipay Card Payments, for example:
- gaming and iGaming applications are reviewed individually, subject to licence and compliance review;
- availability depends on where the business is registered, the markets it sells into and whether acquiring is available for its model there;
- KYB covers beneficial owners holding 25% or more;
- API credentials are issued only after qualification, KYB and approval;
- reviews normally take two to five business days and can take longer for complex models. Approval is not guaranteed.
Designing the deposit flow
A deposit flow takes a player from the cashier to a completed payment and back, and the player balance should change only once the payment is confirmed.
A typical card deposit runs in five steps:
- The player chooses an amount and method in the cashier, which checks verification status and limits.
- The operator’s backend creates the payment with the provider, using its own unique reference.
- The player pays on the provider’s checkout, including any 3D Secure step, and the issuer approves or declines.
- The provider confirms the final status to the operator’s backend.
- The operator credits the balance under its own rules.
A card-payment provider covers steps 2 to 4. The cashier, the player account and the balance stay with the operator.
Hosted, redirect or embedded checkout
- Hosted checkout. Card details are entered on a page run by the payment provider.
- Redirect. This is how the player reaches that page and returns to the operator.
- Embedded forms. Card entry sits inside the operator’s own pages, which brings card data closer to the operator’s environment and can widen its PCI DSS obligations.
Niftipay Card Payments uses a hosted checkout. Card details are entered on a page hosted and operated by Niftipay, which keeps card entry outside the operator’s application environment.
Verification and limits before the payment call
Some controls must run before a deposit reaches any provider. In Great Britain, for example:
- operators must verify a customer’s age before the customer can deposit;
- operators must verify name, address and date of birth before the customer can gamble;
- remote operators must prompt for a deposit limit at registration or first deposit, and block further deposits once it is reached.
These are licence obligations carried out in the operator’s platform, not gateway features.
3D Secure and SCA by market
Strong customer authentication is a legal requirement for payer-initiated electronic payments in the EEA (PSD2) and the UK (Payment Services Regulations 2017), so a player’s card deposit normally falls in scope, subject to exemptions. Elsewhere, issuer and network rules decide, so not every gambling payment requires 3D Secure. Liability differs too: in the US, Visa states that 3D Secure gambling transactions are not eligible for its card-absent fraud dispute protection.
Niftipay applies 3D Secure when the issuing bank or the transaction flow requires it. Our guide to 3D Secure and SCA for high-risk payments covers the mechanics.
Credit the player only after confirmed payment status
A browser redirect is not sufficient evidence that a player’s payment succeeded; the operator’s backend should credit a balance only after a signed webhook or a trusted server-side status check confirms it.
Players close tabs, and payments can complete after the player has left the checkout. Niftipay’s developer documentation states the rule directly: never mark an order paid from the return redirect; wait for the webhook.
Redirects are for the player; webhooks are for the ledger
The redirect returns the player to the cashier. The webhook is a server-to-server message that a payment’s status has changed, and the ledger should update only from it, with a server-side status lookup as a second check for payments that stay pending. Our guide to payment gateway webhooks and the Niftipay developer resources cover the details.
Signed webhooks, retries and idempotent handling
A deposit webhook handler should:
- verify the signature and reject old timestamps (Niftipay signs payloads with HMAC when a webhook secret is configured);
- respond quickly and process asynchronously, so slow handling does not trigger repeat deliveries;
- process each event once, recording handled events so a repeat never credits twice;
- never downgrade a confirmed payment because a late or out-of-order notification arrives;
- send a unique reference with each payment, so a retried request does not create a second one.
Status-to-action table
| Payment status | Operator action |
|---|---|
| Pending | Do not credit yet; show the payment as processing |
| Paid | Credit the balance under the operator’s rules |
| Cancelled, expired or declined | Do not credit; let the player retry |
| Refunded | Record a separate refund event and adjust the balance |
| Chargeback | Record a separate event and start the dispute workflow |
Niftipay’s card webhooks use the values pending, paid, cancelled, expired, refunded and chargeback. Declined attempts appear in the merchant dashboard with a decline reason.
Withdrawals are a separate workflow with separate rules
A deposit integration does not automatically provide a player-withdrawal rail. A deposit moves money to the operator; a withdrawal moves the balance, including winnings, back to the player, using different transaction types, rules and often providers.
Paying winnings back to the source
Visa’s rules allow gambling winnings to be paid to a Visa card only through an Original Credit Transaction (OCT), not a refund-style credit. In Europe, the OCT must go to the card used for the winning wager.
Regulators point the same way. UK Gambling Commission risk guidance rates not paying out to the depositing card (a “closed loop”) as a high money-laundering risk, and the Malta Gaming Authority requires withdrawals to go, where possible, to the account the funds came from.
Withdrawal rules that affect the cashier
- Great Britain. Players must not be offered the option to cancel a withdrawal request, and a withdrawal must not trigger identity checks that could reasonably have been done earlier.
- Malta. Under the MGA Player Protection Directive, a requested balance is paid within five working days where practicable. Funds in a pending withdrawal must not be wagered.
Why refunds are not a payout rail
A refund reverses all or part of one original payment and is capped at its amount. Winnings usually exceed the deposits behind them, and Visa excludes refund-style credits for winnings.
Niftipay’s card refunds follow this model: full and partial refunds on paid orders, up to the original payment. Niftipay does not currently provide a verified player-withdrawal or winnings-payout capability, so operators using Niftipay for card deposits need a separate provider for withdrawals.
Reconciliation: matching payments to player balances
Reconciliation shows that every credited balance matches a confirmed payment, and every confirmed payment matches a balance change. It depends on identifiers stored from the moment each payment is created.
Which identifiers to store
For each deposit, the operator should store:
- its own unique payment reference;
- the provider’s order or payment ID;
- the internal player account ID;
- the amount, the currency, and each status with its timestamp;
- the webhook events already processed.
Each Niftipay order carries a merchant reference that must be unique across the operator’s orders. The merchant dashboard shows order and payment IDs and can export transaction records. Our guide to a payment status API explains how to surface status for operations teams.
Refunds and chargebacks as separate events
Reconciliation should never overwrite the original payment. A refund or chargeback is a new linked event with its own date, amount and status, which keeps an audit trail finance can match against settlement reports.
Fraud, chargebacks and monitoring after go-live
After go-live, gambling merchants operate under closer card-network and acquirer monitoring than most online merchants, so payment data has to feed the operator’s own risk controls.
What card networks monitor for gambling merchants
Because Visa treats card-absent gambling as high integrity risk:
- acquirers monitor a gambling merchant’s volume, average ticket, transaction count and disputes daily;
- Visa can impose additional authentication requirements and disqualify merchants whose dispute levels become critical;
- Visa does not allow dynamic merchant descriptors for gambling merchants, so the statement name should stay stable.
Disputes need an owner from day one, and the evidence normally comes from the operator’s own records.
Responsible-gambling checks that use payment data
In Great Britain, payment data feeds several operator controls:
- deposit limits;
- financial vulnerability checks, required once deposits minus withdrawals exceed £150 in a rolling 30 days;
- self-exclusion, after which the operator closes the account, returns funds and records the card numbers to exclude.
These are operator and regulatory responsibilities. A payment provider supplies the data, not the controls.
Pre-launch iGaming payment integration checklist
| Phase | What to confirm | Owner | Evidence / output |
|---|---|---|---|
| 1. Licence | Licence type, scope and permitted markets | Operator compliance | Licence and scope summary |
| 2. Target markets | Markets served at launch | Operator commercial | Launch market list |
| 3. Acquiring and methods | Methods and card types available per market, and transaction coding | Operator with provider | Written confirmation per market |
| 4. Commercial approval | Application reviewed, terms agreed | Payment provider | Approval and terms |
| 5. KYB | Company, director and owner verification | Operator, reviewed by provider | Completed KYB |
| 6. Checkout integration | Payment creation, checkout, return and failure pages | Operator tech team | Working test flow |
| 7. Webhooks and status | Signature checks, idempotent handling, status rules | Operator tech team | Test log for every status |
| 8. 3DS and SCA | Authentication in each launch market | Operator with provider | Authenticated and failed test cases |
| 9. Reconciliation | Stored identifiers, daily matching | Operator finance | Reconciliation report |
| 10. Refunds and chargebacks | Refund process, dispute evidence workflow | Operator operations | Written procedures |
| 11. Withdrawal rail | Separate tested route for withdrawals and winnings | Operator with payout provider | Payout provider live |
| 12. Production testing | Low-value live deposits and a refund, end to end | Operator | Go-live sign-off |
How Niftipay supports licensed iGaming operators
Niftipay Card Payments lists gaming and iGaming among the sectors it reviews, with licensed operators assessed individually and subject to licence and compliance review. Approval is not guaranteed.
For an approved operator, Niftipay provides card acceptance alongside existing payment methods:
- Visa and Mastercard, plus Apple Pay and Google Pay where supported;
- a hosted checkout with 3D Secure when required;
- a REST API with credentials issued after approval;
- HMAC-signed webhooks;
- full and partial refunds;
- chargeback status in the dashboard, with the operator preparing any evidence.
Cards are not stored, and each payment is an individual transaction. Availability depends on registration country, target markets and acquiring. Licence restrictions on card types, such as Great Britain’s credit-card ban, should be raised during qualification.
Niftipay does not currently provide a verified player-withdrawal or winnings-payout rail. Operators therefore need a separate solution for that part of the cashier.
iGaming payment gateway integration FAQs
What does an iGaming payment gateway integration require?
It requires six things, in order:
- a licence covering the target markets;
- commercial approval from a provider whose acquiring supports them;
- a deposit flow built on the provider’s checkout and API;
- crediting balances only on confirmed status;
- reconciliation;
- a separate, tested rail for player withdrawals.
Can UK-licensed gambling operators accept credit card deposits?
No. UK Gambling Commission licensees must not accept payment for gambling by credit card, including through an e-wallet or other money service business. Debit cards are not covered by this ban.
Do iGaming deposits need 3D Secure?
Not universally. Strong customer authentication applies to payer-initiated electronic payments in the EEA and the UK, which normally includes player deposits, subject to exemptions. Elsewhere, issuer, network and market rules decide.
How are gambling winnings paid back to cards?
Under Visa’s rules, winnings go to a Visa card only through an Original Credit Transaction (OCT), which pushes funds to a card. In Europe, the OCT must go to the card used for the winning wager. A refund cannot replace it, because a refund is capped at the original payment.
What is the difference between a payment gateway and payment orchestration?
A payment gateway processes payments and connects the operator to the acquiring network. An orchestration layer sits above several gateways and decides which provider handles each payment. Niftipay provides card acceptance and is not a payment orchestration platform.