The best iGaming payment processor is the one that can lawfully support your exact licence, player markets and deposit-to-withdrawal flow—and prove how it will settle, reconcile and resolve exceptions. A glossy list of payment-method logos is not enough. This operator-side RFP helps a business team compare processors and payment service providers (PSPs) without assuming that any vendor is universally “gambling-friendly.” It does not rank or endorse providers we have not tested.
Use this framework for a new market, a processor replacement or a second-route resilience project. Start with the legal entity, licence, jurisdictions, products, expected transaction volumes and bank/PSP relationships. Ask counsel and the relevant acquirer or regulator to validate the market-specific rules before contracting. “Available in a country” does not necessarily mean approved for your gambling product or merchant entity.
First separate the parties behind “payment processing”
Gateway, PSP, processor, acquirer, bank and payout provider are often used loosely in sales language, but the contracts and operational duties may sit with different entities. Map who authorizes the transaction, who holds or moves funds, who provides the cashier interface, who handles card-network disputes, and who returns settlement and fee data. A single supplier may bundle several functions, yet its subcontractors and regional acquirers still matter.
| Decision | Evidence to request | Common gap |
|---|---|---|
| Market and gambling eligibility | Written entity/product/market approval and acquiring route | Generic “high-risk accepted” claim |
| Payment methods | Specific deposit and payout rails by country and currency | Deposit coverage mistaken for withdrawal coverage |
| Settlement and reserves | Settlement calendar, currencies, fees, reserve triggers and release terms | Headline rate hides cash-flow cost |
| Risk and disputes | Dispute workflow, fraud-data access, escalation and reporting | Operator receives alerts too late to act |
| Technology | API/webhook docs, sandbox, uptime process and version policy | Demo payment passes; reconciliation fails |
| Exit | Data export, token portability, open-case support and termination terms | Switching requires a disruptive rebuild |
Write an operator brief before inviting quotes
- Licensing and geography: List the actual operating entities, licences, player countries and verticals. Mark markets under consideration separately from markets already authorized.
- Flow: State deposit methods, withdrawal methods, supported currencies, refund rules, expected transaction bands and whether a single wallet serves casino and sportsbook.
- Risk: Describe KYC, AML, fraud, chargeback and safer-gambling decision points. Share anonymized counts, not identifiable player records, at the RFP stage.
- Systems: Name the cashier, PAM/wallet, risk platform, CRM, accounting system and reporting warehouse. Specify whether the integrator or PSP owns each adapter.
- Operations: State support hours, expected incident response, reconciliation cadence and the team’s capacity to manage more than one provider.
Ask every bidder to reply to the same brief in a standard template. This makes the comparison fairer and exposes missing answers. A proposal should distinguish what is live in production from what needs a partner, a custom build or a future roadmap release.
Compare the real cost, not just the headline transaction fee
Request a quote with each fee on its own line: onboarding, monthly minimum, authorization, capture, payout, refund, dispute, currency conversion, cross-border, reserve, gateway, fraud tool, reporting, support and termination. Ask whether taxes and scheme or acquirer charges are included or passed through. Do not combine a percentage and a fixed fee into one “effective rate” without the expected method and ticket-size mix.
Build a 12-month model with your own forecast by country, method, currency, average deposit, payout ratio and dispute rate. Record the amount of cash tied up in a reserve and the release conditions separately from fees. A lower processing price can be worse for liquidity if settlement is slower or the reserve is larger. Leave unknown quote cells blank until the supplier confirms them in writing; no market-wide rate card is reliable for every operator.
Approval rates need a defensible denominator
“Approval rate” may refer to authorizations accepted by an issuer, successful deposits visible to players, or completed cashier attempts. These are different metrics. Require a reporting dictionary with counts by market, issuer country, payment method, new versus returning customer, amount band and decline reason. Exclude or separately report user-abandoned and blocked attempts so an “improvement” is not merely a change in what gets counted.
For a processor switch or route experiment, compare like-for-like cohorts over a defined test period. Log routing changes and promotions that alter the customer mix. Track not only successful deposits but also payout completion, disputes, refunds, fraud alerts and player-support contacts. Do not accept an uplift guarantee without a baseline, definitions and a test plan.
Risk, disputes and compliance belong in the commercial decision
Ask who owns card-network monitoring, when the operator is alerted and what data is available to investigate. Visa’s VAMP fact sheet describes its fraud, dispute and enumeration monitoring program; the relevant acquirer should explain current thresholds and responsibilities for the operator’s route. Avoid copying a static threshold from an old article into a contract.
Check payment-method restrictions by licence. For example, the UK Gambling Commission’s payment-method condition governs eligible payment-service providers for specified remote licensees serving Great Britain, and its credit-card guidance explains that the ban can extend through an e-wallet. Those are GB examples, not universal rules. Your RFP should ask the bidder to show how each market’s restrictions are enforced and evidenced.
For card security, require a responsibility matrix and evidence of the provider’s assessed scope. The PCI Security Standards Council states that a customer using third-party service providers must manage and oversee those relationships and monitor their PCI DSS status. Do not assume that outsourcing means the operator has no payment-security obligations.
Run a paid or unpaid proof of concept with failure cases
- Complete a deposit and withdrawal in each priority market and method, with the ledger and PSP reference reconciled.
- Force a decline, abandoned authentication, timeout and repeated request. Confirm the player receives a truthful state and no duplicate wallet credit.
- Replay and delay a webhook. Confirm event authenticity, deduplication, recovery and a visible support/finance exception.
- Run a partial refund, chargeback and withdrawal hold; show how fees and adjustments reach finance records.
- Simulate an outage and planned maintenance. Test status communication, escalation and approved fallback behavior.
- Export transaction, settlement, dispute and fee data in the format the operator would need to leave the provider.
The scorecard should mark each test passed, failed, blocked or not applicable with evidence and owner. A sandbox success is not a production approval; the commercial and regulatory route must still be confirmed before launch. Technical boundary tests are detailed further in our payment-gateway integration RFP, scheduled as a companion guide.
Single processor or multi-PSP?
A second provider can reduce dependency and improve market coverage, but it also adds underwriting, integration, reconciliation, dispute and support work. Do not deploy “smart routing” until the operator has an explicit policy for eligible markets, player consent where applicable, transaction ownership and failure recovery. A routing decision should be reconstructable from logs. The first priority is a sound primary route; the second is a tested contingency, not an impressive diagram.
For operators focused on one region, a region-specific guide may be more useful than a global list. See our Ontario payment-provider guide for a separate market lens. Its jurisdictional details should be rechecked before procurement.
Frequently asked questions
What is the difference between a gambling payment processor and a gateway? A gateway typically provides the technical path from cashier to payment infrastructure; processing, acquiring, settlement and payout may be separate services. Ask who performs each role in the proposed contract.
Can one provider handle every market and method? Do not assume so. Get written approval and a method-by-market matrix for the specific gambling product, entity and licence. Confirm both deposits and withdrawals.
What is the most important commercial question? Ask for the complete settlement and reserve mechanics alongside fees. The operator needs to know when cash is available, what can be withheld and how disputes affect that balance.
How should we rank vendors? Use evidence from the same RFP and test suite, weight legal eligibility and ledger integrity as mandatory, and leave unsupported claims unscored. Paid relationships should never decide editorial order.
Method note: This article is an operator evaluation framework, not a claim that named processors were tested or that a provider is approved for your licence. Primary-source examples were checked on 17 September 2026. Revalidate current rules, network programs and vendor terms before procurement.
