iGaming Payment Gateway: 2026 Operator's Guide
What an iGaming payment gateway costs, which auth rates to expect, and how PaymentIQ, Nuvei and Checkout.com actually compare for licensed operators.
Most operators shopping for an iGaming payment gateway are really shopping for three things at once, and the vendors selling to them are happy to leave that confusion in place. This guide separates the layers, puts real numbers against each, and names the providers you will end up comparing.
It is written for whoever owns the deposit funnel — usually a CTO or a head of payments — and it assumes you already know what a card transaction is.
What a gateway actually does, and what it doesn’t
A payment gateway has one job: turn a set of payment credentials into an authorisation, then settle the money. That is it.
Three things it is routinely confused with:
- The cashier renders the deposit form, picks which methods to show, validates input, and handles the retry conversation with the player. It is a UI layer. It moves no money.
- The orchestrator decides which gateway a given transaction goes to, retries soft declines against an alternative, and fails over during an incident. It is routing logic.
- The acquirer holds the merchant account and carries the scheme relationship. Some gateways are acquirers (Checkout.com, Adyen). Most are not, and resell someone else’s licence.
The distinction is not academic. It determines who you call at 2am, who owns your auth rate, and what it costs you to leave. If one vendor supplies all three and you sign one contract, you have bought a single point of failure with a discount attached.
The economics nobody puts on the pricing page
Gateway pricing is quoted as a percentage. That percentage is the smallest part of what you actually pay.
| Cost line | Typical range for MCC 7995 | Notes |
|---|---|---|
| Merchant discount rate | 2.5-4.5% blended | Varies hard by licence, geo, and card mix |
| Per-transaction fee | 0.10-0.30 EUR | Applies to declines too, at some providers |
| FX margin | 0.5-2.5% | On any currency you don’t settle in |
| Chargeback fee | 15-40 EUR each | Charged regardless of whether you win |
| Rolling reserve | 5-10% held 90-180 days | The big one |
| Monthly minimum | 500-5,000 EUR | Kills the “cheap backup provider” plan |
The rolling reserve is the line to negotiate hardest. A 7% reserve held 180 days on 4M EUR of monthly volume is roughly 1.7M EUR of your capital sitting in someone else’s account permanently. It is not a fee, so it never appears in a rate comparison, and it dwarfs the 0.3% you spent three weeks arguing about.
Two things reduce it in practice: a demonstrated chargeback history under 0.5%, and a licence the underwriter recognises. Neither is negotiable on day one, which is why reserves should have a written step-down schedule in the contract rather than a promise to “review it annually”.
Benchmarks worth measuring against
Auth rate is the number that moves revenue, and most operators measure it wrong — usually by dividing approvals by total attempts including obvious fraud and test traffic.
Measure it per method, per geo, per issuer BIN range. Blended auth rate hides the market that is quietly failing.
Realistic bands for licensed operators in stable EU markets:
- Cards, 3DS2 with network tokens: 82-90%
- Cards, 3DS2 without tokens: 74-84%
- Pay-by-bank (Trustly, Zimpler and similar): 90-96%
- Wallets (Skrill, Neteller): 88-94%
- Apple Pay / Google Pay: 88-95%
If cards sit below 75%, the cause is usually structural rather than fraud-related. In order of how often it turns out to be the answer: no network token programme, a 3DS flow that challenges every transaction instead of using risk-based authentication, an acquirer with thin issuer coverage in that country, or a BIN routing table nobody has updated since launch.
Network tokens are the cheapest fix on that list. Provisioning cards into Visa VTS or Mastercard MDES typically returns a low-single-digit percentage point uplift on auth, and it compounds because tokens survive card reissuance — the stored card that would have died on expiry keeps working.
Read your decline codes properly
Retrying a hard decline burns money and irritates issuers. Retrying a soft decline recovers real revenue. The distinction is in the ISO 8583 response code, and any gateway worth using exposes it rather than collapsing everything into “failed”.
Retry these:
05Do not honour — the largest and most ambiguous bucket; frequently recoverable on an alternative route51Insufficient funds — retry later, or prompt a lower amount91Issuer unavailable — a timing problem, not a decision96System malfunction — same
Never retry these:
04/07Pick up card14Invalid card number41Lost card43Stolen card57Transaction not permitted to cardholder
Code 05 deserves specific attention because it is where the volume is. It means the issuer declined without telling you why, and a meaningful share of those approve on a second attempt through a different acquirer with a different issuer relationship. That is the single strongest argument for having more than one gateway, and it is measurable: track the approval rate of second attempts routed to an alternative provider, and you have the ROI case for multi-provider written for you.
57 is worth watching separately. A cluster of it in one country usually means issuers there have started blocking MCC 7995 as policy, and no amount of retry logic will fix it — that market needs a local APM instead.
The providers you will actually compare
PaymentIQ (Worldline)
Built for iGaming from the start, and it shows in the breadth of provider connections. If you want one contract that covers a hosted cashier, orchestration, and a long list of pre-integrated PSPs, this is the most direct route to live.
The trade-off is control. The cashier is a hosted surface, so brand and UX changes go through the vendor’s queue rather than your sprint. Adding a PSP that PaymentIQ has not integrated means waiting for their roadmap. Operators who outgrow it usually do so for one of those two reasons, not because of pricing.
Nuvei
Genuine breadth — a very large APM catalogue and real licensing depth across regulated markets, which matters if you are running several jurisdictions off one commercial relationship. Strong where you need a provider that has already solved local rails you would otherwise integrate one by one.
Worth knowing: the acquiring, the gateway and the value-added services are separate commercial conversations, and the blended rate you are quoted depends heavily on which combination you take. Ask for the breakdown, not the blend.
Checkout.com
The best granular data of the three. Decline reasons come back detailed rather than generic, network token support is mature, and being a direct acquirer in most of its markets removes a hop between you and the issuer — which is where a chunk of that auth-rate difference comes from.
The catch is appetite. Checkout.com is selective about gambling merchants and underwrites tightly; licence, jurisdiction mix and chargeback history all get scrutinised. When it approves you, it is frequently the strongest card performer in the stack. It is also the least likely of the three to say yes to a new operator with no history.
Also on most shortlists
Praxis — iGaming-native orchestration and cashier, strong in emerging markets. Trustly — the pay-by-bank default in the Nordics and increasingly elsewhere; frequently the highest-converting method you can offer in those geos. Adyen — excellent technology and reporting, narrower iGaming appetite. Paysafe / Skrill / Neteller — wallet coverage that still carries real deposit share in several markets.
What breaks after go-live
The integration is not the hard part. These are:
Underwriting drift. Your approved risk profile is a snapshot. Volume growth, a new jurisdiction, or a chargeback spike triggers re-review, and re-review can raise your reserve or cap your volume with a fortnight’s notice. Keep a second provider live and warm precisely so that notice is survivable.
Reconciliation. Every provider has its own settlement file format, timing, and definition of a refund. With two providers this is annoying; with four it becomes a permanent part-time job unless something normalises it. Budget for it before you add the third.
Silent method failures. An APM that stops converting rarely errors — it just quietly drops from 92% to 61% while everything reports green. Alerting on per-method auth rate deviation catches this in hours instead of at month-end.
Card-on-file breakage. Without network tokens, every reissued card is a returning depositor hitting a dead stored method. This shows up as churn in your retention numbers rather than as a payments problem, which is why it goes undiagnosed for so long.
A gateway RFP that gets useful answers
Vendor RFPs mostly generate marketing prose. These questions do not:
- What is our expected auth rate on cards in [your top three markets], and what is that based on — comparable merchants or a general figure?
- Do you support network tokens natively, and is provisioning included or priced separately?
- What is the rolling reserve, and what is the written step-down schedule?
- Which decline codes do you pass through unmodified?
- How long does adding a new PSP or APM take, and is that on your roadmap or ours?
- What is the notice period, and does the contract auto-renew?
- On termination, do we get our tokenised card vault exported in a portable format?
Question 7 is the one that changes negotiations. A vault you cannot export means every stored card in your player base has to be re-entered by the player when you switch providers, and that is a retention event, not an engineering task. Ask it in writing, early, and get the answer in the contract.
Where to start this week
Pull last month’s transactions and produce one table: auth rate by method, by country, split into approvals, soft declines and hard declines. Nothing else, and no blended totals.
Almost every operator who does this finds one country or one method sitting 15+ points below the rest of the book. That gap is the highest-value payments work available to you, it is usually a configuration or routing problem rather than a vendor problem, and you cannot see it in an aggregate dashboard.
If the gap turns out to be the retry path — soft declines dying on the first attempt because there is nowhere to send them — that is a routing question rather than a gateway question. Payment orchestration vs gateway for iGaming works through when the extra routing layer earns its licence fee and when it does not. If your criteria are still forming, how to choose an iGaming payment gateway covers the selection process in less depth than this piece but in a more usable order.