iGaming Payment Provider Evaluation: Operator Checklist

This is the checklist we’d run if we were operators evaluating payment providers for an iGaming brand in 2026 — so really, what we did run when we were operators ourselves. 47 items across six sections: licensing, conversion, integration, fraud + KYC, commercials, and operator experience.

Use it as an evaluation template, not a tick-box exercise. Some items are dealbreakers (license coverage, settlement timing); others are nice-to-haves where flexibility and partnership matter more than a hard yes.

How to use this

For each candidate vendor, score each item:

• Pass — the vendor meets your requirement clearly.
• Conditional — the vendor meets it with caveats; capture the caveats.
• Fail — the vendor doesn’t meet it.
• N/A — the item doesn’t apply to your context.

A strong fit is 35-40+ Passes with no critical Fails (items 1-4, 14, 30 are the typical critical ones for licensed operators). Below 30 means the vendor is likely a poor fit even if they’re showing well on the surface.

Section 1 — Licensing and compliance (items 1-8)

These are mostly hard requirements. Failures here are dealbreakers.

1. License coverage. Vendor explicitly serves operators with the licenses you hold (MGA, UKGC, AGCO, Curaçao, etc.).
2. Geographic coverage. Vendor processes in every geography your traffic comes from, or commits to a roadmap.
3. AML / KYC alignment. Vendor’s KYC standards are aligned to your jurisdictional requirements (FATF, 5AMLD, jurisdictional source-of-funds thresholds).
4. PCI DSS Level 1 certification. Required for any vendor processing card data on your behalf.
5. GDPR / data residency. Vendor stores player data in the region your license requires (most EU licenses require EEA residency).
6. Sanctioned-jurisdictions handling. Vendor blocks or flags transactions from OFAC, EU, and UK sanctions lists.
7. Regulatory change handling. Vendor commits to compliance with new rules within X weeks (e.g. UK affordability checks, Italian deposit limits).
8. Audit cooperation. Vendor will produce SOC 2 reports, PCI ROC, and license audit responses on reasonable request.

Section 2 — Player conversion (items 9-16)

The commercial heart of the evaluation. Items here directly affect revenue.

9. Average approval rate on your transaction profile, with historical benchmarks. Below ~80% on cards in iGaming is a yellow flag.
10. Decline-recovery delta — how much approval-rate lift the retry/smart-routing logic delivers vs no-retry. Typically 4-12%.
11. Apple Pay / Google Pay coverage — table stakes in 2026 for mobile-first operators.
12. Pay-by-bank coverage in your jurisdictions (Trustly, Volt, TrueLayer, Pix, etc.).
13. Localised payment-method ranking. Cashier shows the right payment methods first for each player based on geography and history.
14. Brand control of the cashier UI. Cashier renders inside the operator brand without iframe seams or vendor watermarks.
15. Mobile UX on iOS Safari — the highest-traffic-share browser in EU iGaming. Specifically: no scroll-jank, no autocomplete failures, no Apple Pay sheet bugs.
16. Personalised deposit defaults. Cashier remembers each player’s typical deposit amount, preferred method, and time-of-day pattern.

Section 3 — Integration and engineering (items 17-26)

Where weeks of project time live or die.

17. Integration model — REST API, web component, SDK, or hosted iframe. Web component / SDK is the modern default.
18. Time to first deposit in a non-production environment, on a clean stack. Realistic answer: 2-4 weeks for a competent team.
19. CSS variable inheritance — does the cashier inherit your design tokens, or hardcode its own?
20. Event hooks for analytics, A/B testing, error monitoring (Datadog, Sentry, Segment, Mixpanel, GA4).
21. Sandbox quality — does the vendor’s test environment behave like production, including edge cases (3DS challenges, retries, partial failures)?
22. Documentation quality. Code samples, error catalogue, runtime invariants, breaking-change history.
23. Versioning policy. SemVer, deprecation windows, support for older versions during migration.
24. Multi-region deployment. Cashier hosted in your geo, low TTFB, edge cache friendly.
25. Web Component or vanilla JS distribution. Avoid vendors who require a specific framework (Angular, Vue) — that’s a 5-year commitment.
26. Open-source visibility. Either OSS or comprehensive published changelogs. Black-box products are higher risk.

Section 4 — Fraud, KYC, and risk (items 27-33)

iGaming-specific risk signals.

27. Device fingerprinting — coverage across iOS, Android, desktop, including Safari ITP-resistant.
28. Velocity controls — configurable rules for transactions/hour, deposits/day, max-per-card.
29. Multi-account detection — detection of one player operating multiple accounts.
30. In-flow KYC — KYC steps surfaced inside the cashier, not redirected out. Critical for European compliance UX.
31. Affordability checks — UK / EU regulators expect operators to assess affordability at deposit time. Vendor supports this hook.
32. Chargeback management workflow — tooling to respond, evidence, and dispute.
33. Third-party fraud-tool integrations — Sift, Featurespace, Forter, Riskified, Sardine.

Section 5 — Commercials (items 34-40)

The terms of the deal beyond the price tag.

34. Pricing model — fixed-fee per cashier-rendered session, % of volume, or hybrid. Volume-based aligns vendor incentives with yours.
35. Tier breakpoints — at least three volume tiers documented up-front.
36. Implementation fee — zero or refundable on launch is the right answer.
37. Termination clause — 60-day notice on a 12-month contract is standard. Anything longer needs justification.
38. Auto-renewal terms — month-to-month after initial term, not 12-month auto-renewals.
39. Liability cap — cap should be at least 12× monthly fees, ideally with carve-outs for vendor breach of data-protection obligations.
40. MFN / pricing fairness clause — vendor commits not to charge you more than reference-class operators of similar size.

Section 6 — Operator experience (items 41-47)

Long-term partnership criteria. Often the deciding factor between two vendors who score similarly on items 1-40.

41. Named technical contact — a specific engineer or solutions architect, not a faceless support inbox.
42. Roadmap influence — operator can submit feature requests with realistic chance of being prioritised.
43. Quarterly business reviews — vendor proactively reviews your conversion, decline patterns, and roadmap fit.
44. Status page and incident transparency — public status page, post-mortem culture, no surprise outages.
45. Migration support — vendor will help you onboard from your current provider, not just go-live.
46. Off-boarding support — vendor will help you migrate off if it ever comes to that. This is a culture signal, not a contract signal.
47. Operator references at your size and geography — at least three references the vendor will hand over without filtering.

Common red flags during the evaluation

Beyond individual checklist items, these patterns signal a vendor unlikely to last past year 2:

• The same person owns sales, technical demos, and contract negotiation. Suggests a small team with no separation of concerns.
• Demo scripts can’t deviate from the canned flow when you ask “what happens if X?”
• Reference customers are all under 12 months old. Suggests retention is weak past the first year.
• Roadmap items the vendor promised in pre-sales don’t appear on the contract or SOW.
• Sales team can’t articulate the trade-off in their product. A vendor who says “we have no trade-offs” is either lying or doesn’t understand what they sell.

What to do with the checklist output

Compile the per-vendor scoring into a single summary table for the buying committee. Then do these three things:

1. Share the methodology with the vendors. Don’t share the scores. Tell them the dimensions you’re evaluating on so they can clarify any item where the answer is “yes but only with a caveat”.
2. Cross-check with two reference customers per shortlisted vendor. Specifically validate items 14, 18, 30, 41, and 46 — these are the ones vendors are most likely to over-claim.
3. Walk through the top 2 with your engineering and payment-ops leads. They’ll catch operator-impact issues that pure procurement scoring misses.

And then the boring step that catches most regrets

After signing, document the original evaluation. We’ve seen operators sign a vendor based on a strong scorecard, then 18 months later forget what was promised vs delivered. The evaluation document is what you bring to the year-2 renewal conversation.

For the longer-form decision-making frameworks, see our payment orchestration RFP template and our iGaming Payment Solutions Comparison. And if your evaluation is mid-process and you’d like an outside view, we’d love to talk — we’re operators ourselves, so we tend to spot the gaps that pure-vendor sales conversations smooth over.