Online casino operators handle payments differently from standard e-commerce: licensing jurisdiction dictates which rails you can offer, payout speed is a competitive differentiator, and every PSP relationship has to survive regulator scrutiny. This guide walks through the rails, provider selection, KYC vendors, and payout mechanics that shape a compliant casino payment stack.
Below is a working reference for the payment stack every online casino operator has to make decisions about — rails, PSP selection, KYC vendors, payout automation, and the compliance work regulators actually check.
Casino Payment Mix in Regulated Markets
For an operator, "casino payment methods" is the set of rails you expose in the cashier plus the PSP contracts and internal routing behind them. Every rail has a different fee, a different chargeback profile, a different settlement time, and a different regulator-facing paper trail.
The right mix is not universal — it depends on your licensing jurisdiction, the countries you accept players from, and where your player base actually banks. In Malta, Malta Gaming Authority data (2016–2022), published via Statista, puts bank transfers at 40%, cards at 34.7%, and e-wallets at 13.2% in the latest reported year. In the UK the mix skews harder to debit + e-wallet because credit cards have been banned for gambling since 2020.
Why the Payment Mix Decides Operator Economics
Deposit UX is the single biggest lever on top-of-funnel conversion. A frustrating cashier interaction — a declined deposit, a 3D-Secure loop that doesn't complete, a "please contact your bank" error — measurably hurts the odds that the player ever tries to deposit again. Every one of those costs the operator both the deposit and the LTV of the player.
On the payout side, time-to-money has become a competitive weapon. Casinos routing payouts through e-wallets or crypto rails clear winnings in minutes; those stuck on batched bank transfers take 3–7 days. When affiliates and review sites benchmark operators, "average withdrawal time" is a headline metric — and slow payouts drive churn to competitors who moved to instant rails first.
MGA, UKGC and FCA: Regulatory Framing for Payment Handling
Operator payment obligations sit at the intersection of gambling regulators, payment regulators, and card scheme rules. The three that most reshape day-to-day payment operations in EU/UK-facing casinos:
- Malta Gaming Authority (MGA) – MGA-licensed operators must segregate player funds, evidence source-of-funds on deposits above threshold, run PEP/sanctions screening at onboarding and continuously, and file transaction reports. The MGA Player Protection Directive governs KYC timing and payout SLAs; on timing the MGA applies a risk-based approach, so when identity gets verified varies by operator and risk profile — common patterns range from pre-deposit checks to verification before the first withdrawal. Check the current
licensee hub for operator obligations.
- UK Gambling Commission (UKGC) – Any casino serving UK players needs a UKGC licence. The Commission enforces AML/CTF requirements (matching the FCA's Money Laundering Regulations), affordability checks, and reverse-withdrawal bans. Register lookups live on the
UKGC public register.
- Financial Conduct Authority (FCA) – The FCA doesn't licence casinos, but does authorise the PSPs, e-money institutions and acquirers you contract with. Your payment provider stack has to be FCA-authorised (or passported/equivalently regulated) to hold and process UK player funds — the MLR obligations flow up from them into your reconciliation and reporting.
- Credit card ban (UK) – Since April 2020, credit cards cannot be used to fund UK gambling accounts, including through e-wallets that top up from a credit card. Operators are responsible for the BIN-level enforcement — this is a routing rule inside the payment gateway, not something the card scheme blocks for you.
Payment Rails Casino Operators Must Support
Modern casino cashiers expose 5–15 rails on average, but the economics of each one differ sharply. What matters to an operator is the four numbers per rail: acceptance rate, all-in fee (interchange + scheme + PSP + FX), settlement time, and chargeback exposure. Below is how the main rails compare in an iGaming context.
Debit Cards (Visa, Mastercard)
Visa and Mastercard debit are the default deposit rail in most EU markets and the mandated rail in the UK (credit is banned). Both schemes classify gambling under high-risk MCC 7995, which drives higher interchange, additional scheme fees, and mandatory dispute monitoring under Visa's Acquirer Monitoring Program (VAMP, which replaced the former VDMP and VFMP in April 2025) and Mastercard's Excessive Chargeback Program. Card acquiring for iGaming typically requires a specialised high-risk acquirer, not a generic e-commerce PSP.
- Operator pros: Highest player recognition and 88–94% base authorisation rates on healthy portfolios (best-in-class country/BIN combinations reach 95%+); instant deposit; native 3DS2 flow satisfies PSD2 SCA.
- Operator cons: Effective cost typically 2.5–4.5% (MCC 7995 loading); the combined VAMP ratio (fraud reports plus non-fraud disputes) must stay clear of Visa's excessive threshold — 1.5% in Europe and North America since April 2026, scored at acquirer level as well as merchant level, so the health of your acquirer's whole portfolio matters — and of Mastercard's ECP line (1% plus 100+ chargebacks a month), or scheme monitoring fees kick in; issuer-side BIN blocks in some countries mean routing across multiple acquirers is standard.
E-Wallets (Skrill, Neteller, PayPal, ecoPayz, MuchBetter)
E-wallets are the workhorse payout rail in iGaming — Skrill and Neteller in particular have deep operator integrations and near-instant settlement. Players value them because their bank statement shows only the wallet name (privacy), and operators value them because the wallet handles KYC on the player side, reducing declines.
- Operator pros: Payouts in seconds to minutes; low chargeback (wallet operator absorbs most dispute risk); higher-limit corridors for VIP players; strong for cross-border where cards fail.
- Operator cons: Fees on both deposit (typically 0.5–2%) and payout (fixed + %); bonus-abuse risk is higher, so most operators exclude Skrill/Neteller deposits from welcome bonuses; some markets have low e-wallet penetration among casual players.
Bank Transfers (SEPA, Faster Payments, Open Banking)
"Bank transfer" now covers three distinct rails an operator has to think about separately: legacy wire (T+1 to T+3), SEPA Instant / Faster Payments (near real-time), and Open Banking / PIS pay-by-bank flows (Trustly, Tink, TrueLayer). Open Banking is where growth is — 40% of Malta iGaming volume runs through some form of bank rail, and pay-by-bank cuts per-transaction cost meaningfully vs cards while inheriting the bank's KYC.
- Operator pros: Very low unit cost (fixed fee, not %); high limits; zero chargeback risk on push payments; inherits bank-side KYC and reduces the operator's own screening load.
- Operator cons: Legacy wires are slow (unusable for withdrawal SLAs on their own); PIS flows require country-by-country bank coverage and API contracts; refund handling on push payments is manual.
Cryptocurrencies (BTC, ETH, USDT, USDC)
Crypto adoption in licensed iGaming is uneven: MGA has issued detailed guidance and some operators run crypto natively, while UKGC-licensed casinos generally cannot accept it. The UKGC is, however, currently exploring a path to permit crypto payments for licensed operators — an industry forum set up in early 2026 is examining how they could fit existing AML/KYC frameworks, aligned with the FCA's upcoming crypto regime — so this position may change. Where allowed, stablecoin rails (USDT, USDC) have replaced volatile-coin acceptance for operational reasons — settlement in a dollar-pegged asset removes the FX-on-hold problem casinos had with BTC.
- Operator pros: Sub-1% acquiring cost; irrevocable settlement (no chargebacks); global reach where card acquiring fails; on-chain payout is minutes to any wallet.
- Operator cons: Regulator posture varies by jurisdiction (blocked entirely in some, permitted with enhanced AML in others); Travel Rule (FATF) reporting for transfers above threshold; on-ramp/off-ramp friction can shift the UX burden back to the player.
Mobile Payment Solutions (Apple Pay, Google Pay, Direct Carrier Billing)
Apple Pay and Google Pay are tokenised card wrappers — the underlying rail is still Visa/Mastercard, and the scheme rules and fees follow. The operator benefit is UX (biometric auth, no card entry) which lifts mobile deposit conversion by a measurable margin. Direct carrier billing (Boku, Fortumo) is a separate rail with far higher fees — the mobile carrier and aggregator typically keep 20–30% of the transaction value, several times the cost of card acceptance — and low limits, generally used only in markets where card penetration is weak.
- Operator pros: Higher mobile deposit conversion vs manual card entry; biometric SCA satisfies PSD2 without a challenge screen; token vault means less PCI scope on the operator side.
- Operator cons: Same MCC 7995 fee stack as underlying card; withdrawal support is uneven (mostly deposit-only for wallets); carrier billing is expensive and typically off-limits under gambling regs in many jurisdictions.
Deposit and Payout Flow: What Operators Configure
A "deposit" from the operator side is a five-stage flow, and every stage has a decision the operator (or their payment gateway) has to make. The same goes for payouts, which typically fail or succeed on the internal controls layer, not the rail itself.
Deposit Flow Steps (Operator-Side)
Behind the cashier screen, each deposit runs through a consistent sequence:
- Player selects rail in the cashier — the gateway routes to the acquirer or PSP configured for that BIN / country / amount band.
- Fraud pre-authorisation — device fingerprint, velocity checks, PEP/sanctions screen, and per-player deposit limits enforce here, before the money moves.
- SCA / 3DS2 — PSD2 requires strong customer authentication on most in-scope transactions; the gateway triggers the appropriate 3DS2 flow (frictionless, challenge, or exemption).
- Authorisation call to the issuer / rail; on approval, the ledger is credited and the player sees the balance.
- Settlement and reconciliation — funds land in the operator's merchant account on the acquirer's cycle (T+1 to T+3 for cards), and the payments ledger has to reconcile against the gaming ledger daily.
Operator-side deposit acceptance controls that materially move the numbers:
- Multi-acquirer routing — industry estimates put the share of otherwise-lost deposits recovered by cascading a declined transaction to a second acquirer at around 5–15%, though results vary by portfolio and acquirer mix.
- BIN-level routing rules — sending each card to the acquirer with the best historical auth rate for that issuer.
- Automatic retry on soft declines — with respect for scheme rules on retry limits.
- Currency-of-origin routing — matching the player's local currency to a local acquirer reduces cross-border decline rates.
- Chargeback dispute automation — Verifi CDRN and Ethoca Alerts intercept disputes before they hit the scheme's monitoring programme.
Payout Flow and Time-to-Money SLAs
A payout starts when the player submits a withdrawal request. The operator has to run KYC and bonus-clearance checks, apply any responsible-gambling holds, and then submit the payout instruction to the chosen rail. Most operators lose more player LTV to the internal review queue than to the rail itself — competitive operators now target keeping "pending" holds under 24 hours, with instant-review flags for verified players.
Once released, rail settlement times shape the player-visible payout SLA:
- E-wallets (Skrill, Neteller, ecoPayz): typically instant to a few hours end-to-end.
- Debit cards (Visa Direct OCT, Mastercard Send): 30 minutes to 24 hours where push-to-card is enabled; 1–5 business days on legacy refund rail.
- Bank transfers: SEPA Instant and Faster Payments settle in seconds; SEPA Credit Transfer T+1; SWIFT wires 3–7 business days.
- Cryptocurrency: minutes for on-chain confirmation (network-dependent); stablecoin rails give the most predictable UX.
- Mobile push-to-wallet: minutes to hours.
The internal review step — not the rail — is what makes operators competitive or slow on published "average payout time" metrics.
KYC, AML and Source-of-Funds Verification
KYC is where the operator's licensing obligations, the fifth AML Directive, and the practical need to keep fraud/chargeback rates low all converge. In practice, MGA and UKGC operators run identity, address, and payment-instrument verification through a specialised KYC vendor (Jumio, Onfido, Sumsub, Veriff), plumbed into the deposit and payout flows via API. The three checks operators do at minimum:
- Identity document verification — passport or driving licence + selfie + liveness, typically 90–120 seconds end-to-end on the player side.
- Proof of address — utility bill or bank statement, matched against declared address.
- Payment method ownership — bank card ownership check (name-match, first/last digits) or e-wallet email match.
Timing has shifted: while historically operators verified only at first withdrawal, most now front-load KYC to before first deposit. This raises deposit friction slightly but massively reduces the "verified after they've already deposited and lost" complaints regulators pay attention to, and cuts payout queue times. Above regulator thresholds (commonly a €2,000 cumulative threshold under 5AMLD-derived rules — measured over a rolling period such as 30 days rather than the account's lifetime, with the exact basis and window varying by regulator), operators must also collect and store source-of-funds evidence.
Deposit/Payout Limits and the Real Fee Stack
Operator-side deposit and withdrawal limits are set for three reasons: regulatory (responsible-gambling caps and cooling-off tools), risk (per-rail chargeback exposure), and commercial (VIP tier segmentation). Most operators expose per-transaction, daily, weekly and monthly limits, with a self-set player limit layer on top.
The fee stack on each transaction is deeper than the "processing fee" line most players see. On a card deposit, the operator is charged: interchange (paid to the issuer, MCC 7995 loading), scheme fees (Visa/Mastercard), acquirer margin, PSP margin, FX margin if cross-border, and 3DS transaction fees. Total blended cost for iGaming card acceptance typically sits at 2.5–4.5% depending on portfolio quality. E-wallet and pay-by-bank rails have a different structure — typically fixed fee + smaller %, with no interchange, which is why high-volume operators route as much traffic as possible off cards.
Choosing PSPs and Rails: Operator Selection Checklist
There is no universally-best PSP or rail — the right stack depends on your license mix, your player geography, and where you are in the operator lifecycle (a market-entry operator on one licence has different needs than a group with 10+ licences and regional acquirers). What follows is the working checklist experienced payment leads run through when specifying a new rail or PSP.
Operator Evaluation Criteria for PSPs and Rails
The evaluation framework most iGaming payments teams use:
- Licence and jurisdiction coverage – The PSP or acquirer must be able to serve the countries your gaming licence covers, with the right local licensing on their side (FCA for UK player funds, MFSA for Malta EMIs, etc.).
- iGaming acceptance policy – Many mainstream PSPs decline MCC 7995 outright. Confirm iGaming appetite in writing before scoping integration work.
- All-in fee model – Interchange plus scheme plus PSP margin plus FX plus per-transaction fees. Compare on effective rate against your actual mix, not the headline number.
- Auth rate benchmarks – Request rolling 90-day auth rate data on comparable iGaming portfolios in your target countries. A 2-point auth-rate delta on the primary acquirer moves top-line revenue meaningfully.
- Payout capability – Native payout support (Visa Direct / Mastercard Send, SEPA Instant, wallet APIs) is the difference between an hour-scale and a day-scale player payout SLA.
- Fraud and chargeback tooling – In-flow chargeback prevention (Verifi, Ethoca), 3DS2 issuer coverage, device fingerprinting, and configurable rule engine.
- Redundancy and routing – A single acquirer is a single point of failure. The stack should support at least two acquirers per major rail with rules-based cascading.
- Regulatory reporting – Ability to produce the transaction reports required by your licensing regulator without a bespoke integration.
Operator Risk Management: Fraud, Chargebacks, Bonus Abuse
The three loss vectors that most consistently show up on casino P&Ls are card-not-present fraud, friendly-fraud chargebacks, and bonus abuse. Card scheme monitoring programmes (Visa's VAMP, Mastercard's ECP) impose fines and remediation costs once dispute ratios cross the scheme thresholds — VAMP's excessive line sits at 1.5% in Europe and North America as of April 2026, ECP triggers at 1% plus 100+ chargebacks a month — for a mid-size iGaming operator, that can turn from a routing issue into a cost-of-acceptance issue in one quarter.
Practical operator controls: device fingerprinting on registration and deposit, velocity limits, deposit-to-play-through ratio checks, first-deposit lower limits with graduation, payout method match (payouts released only to the same rail as the deposit or a KYC-verified alternative), and integration with chargeback intelligence networks so disputes are resolved before they hit the scheme.
Payment Rail Rules for Bonus Programmes
Most operators exclude specific rails from bonus eligibility because they concentrate abuse — Skrill and Neteller deposits are most commonly excluded, sometimes crypto deposits too. This should be enforced at the promotion engine layer (deposit-to-bonus attribution) rather than left to T&Cs alone. On the marketing side, aligning bonus mechanics with your dominant deposit rail (e.g. a "1% cashback on all Visa deposits" promotion for a card-heavy portfolio) tends to outperform generic welcome offers on lifetime value.
Operational Issues Casino Payment Teams Face
The recurring operational tickets that hit iGaming payment teams — and what typically fixes them at the platform level, not at the player-support level:
Payout Queue Backlog and Player Complaints
Complaints about slow payouts are almost never about rail latency; they're about how long the withdrawal spent in internal review. Fixes that move the metric: auto-approve for KYC-verified players below a threshold, tiered reviewer queues, KYC front-loaded to registration (so payouts have nothing to wait for), and instant push-to-card / SEPA Instant on the release side.
Deposit Auth Rate Drops by Country or BIN
A sudden auth-rate drop is usually one of three things: an issuer starting to decline MCC 7995 in a specific country, a scheme-level rule change, or an acquirer's own risk model tightening. The response is per-BIN cascading rules to the alternative acquirer, escalation with the primary acquirer, and adding a local acquirer or alternative rail (pay-by-bank, e-wallet) in the affected country.
Cross-Border FX Cost Bleed
Operators processing cross-border traffic on a single-currency acquirer pay FX on both the deposit and the payout leg. Local acquiring in the player's currency (EUR for eurozone, GBP for UK, PLN for Poland etc.) removes both the FX cost and the cross-border decline penalty. For operators that grew internationally before opening local acquiring corridors, the margin recovered this way is commonly estimated at ~1–2%, depending on corridor mix.
KYC Drop-Off During Onboarding
KYC completion rates below 80% are typically a UX problem, not a document problem: too many steps in one flow, unclear document requirements, or a vendor whose SDK doesn't handle mobile browsers well. Split the flow (identity first, address later if regulator allows), enable auto-capture and quality feedback in the document upload, and A/B test the KYC vendor if pre-deposit drop-off is a top-3 funnel leak.
Rail Restrictions by Jurisdiction
Some rails are unavailable in some markets — UK players cannot fund via credit card at all, PayPal is unavailable to some operators, and UKGC-licensed operators have in practice been unable to accept crypto (a position the regulator is currently reviewing). The operator side is a routing-rule matrix (country × licence × rail) enforced in the gateway. Getting this right at design time prevents "rail shown, transaction blocked" errors, which are among the worst UX failures in the cashier.
MGA and UKGC Compliance Requirements for Payment Handling
Payment compliance for licensed casino operators lives at the intersection of the gambling regulator's licence conditions, EU-level AML directives, and the card scheme rulebooks. What follows are the concrete operator-side controls that regulators actually inspect.
Age Gating and Identity Verification (Operator Duty)
Both MGA and UKGC require the operator to verify the player is 18+ and confirm identity before real-money play. In UKGC's post-2019 framework the industry practice is verified-before-deposit. Age screening has to be robust enough to survive complaints — an underage player who slipped through a weak check is a licence-review event, not just a bad player experience. Operator implementation: KYC vendor on registration + database matching against electoral roll / national ID where available.
Payment-Blocking, Self-Exclusion and Reverse-Withdrawal Rules
GAMSTOP integration is mandatory for UKGC operators — the API must be checked at registration and login, and any self-excluded player must be blocked at the account layer, not just the login screen. UK-issued cards can be flagged as gambling-blocked by the issuing bank; the operator receives the decline and must handle it as a hard decline in the cashier UX. On the operator side, MGA and UKGC both require self-exclusion tools (cool-off, session limits, deposit limits) exposed in the player account, and UKGC additionally bans reverse-withdrawals — once a player initiates a payout, the operator cannot let them cancel it back into playable balance.
Operator Licence Conditions on Payments
Standard payments-related licence conditions across MGA/UKGC and comparable regulators include:
- Identity checks on every player — verified before deposit under UKGC's framework, while the MGA applies a risk-based approach with verification triggered at registration or at cumulative-activity thresholds.
- Segregated player funds — player balances held separately from operating funds in a dedicated account, with reconciliation reports on demand.
- Documented AML programme with transaction monitoring, thresholds, and STR/SAR filing procedures.
- Responsible-gambling tooling — limits, self-exclusion, activity statements — available in the account and enforced at the payments layer.
- Documented complaints procedure, ADR body appointment, and public T&Cs including bonus mechanics and payout terms.
Operationally these translate into KYC/AML tooling, a segregated bank account structure with the acquirer, and configurable player-side controls in the account area. The audit trail matters as much as the controls themselves — regulators expect operators to show not just that the control exists, but that it fires on the right transactions and produces evidence.
Merchants
Only one integration to consolidate all your payment providers to a unified management system.
Start using any PSP within 1-2 weeks and avoid long delays caused by your cashier integration process.
Contact author