Apple Pay and Google Pay for Casino: Acceptance Map

Apple Pay and Google Pay are the two biggest one-tap deposit rails for mobile-first casino traffic in 2026. Operators leave conversion on the table by skipping them, but the path to enabling them is not what most "Apple Pay casino" content covers. Almost every top-ranking page on the topic is a player-facing affiliate listicle of brands; almost none of them answers the question an operator actually has to answer at the desk.

The wallet itself is not the constraint. Apple Pay is on iOS across most regulated markets and Google Pay clears across a similar footprint. The constraint is the acquirer underneath: any wallet on a casino checkout still ends up as a Visa or Mastercard transaction tagged with MCC 7995, and that is where the gates close. This guide maps where they reliably clear by jurisdiction, which PSPs route them, what the conversion math is worth, and what the wallet does not cover end-to-end.

The conversion math behind one-tap wallet checkout for casino

Card decline at MCC 7995 books runs in the 30 to 40 percent range against 5 to 10 percent in mainstream e-commerce, so anything that pushes approval rate up before the issuer model fires is worth quantifying. (The full code-keyed retry playbook for the declines that do still hit sits in the soft-decline article; this one covers the wallet rail above it.) One-tap wallet checkout does that on two axes: device-bound biometric auth replaces password reentry, and the underlying card token clears with stronger fraud signals than a freshly typed PAN.

Stripe ran a holdback experiment across more than 50 payment methods in its Optimized Checkout Suite. The reported number for Apple Pay across global businesses was a 22.3 percent increase in conversion versus the same checkouts without it, and a 22.5 percent revenue lift. On its own, that is an aggregate number from a non-iGaming sample. The mechanism it measures, however, applies harder on a casino mobile deposit page than on a generic e-commerce checkout, because a player at the start of a session has lower tolerance for friction than a buyer who has already committed to a basket.

Placement matters as much as enablement. Stripe also reports a 2x conversion lift when Apple Pay surfaces at the top of the checkout page versus tucked inside an "other methods" panel below cards. That lines up with retention math operators already understand: every step a player takes is a conversion-loss point, and the wallet button is the lowest-step path on iOS.

Google Pay's lift is shaped similarly but the adoption side runs lower because credit-card-on-Google-Pay sees more issuer-side blocks for MCC 7995 than Apple Pay does. Operators report Google Pay deposit volumes as a smaller fraction of the wallet total in regulated markets, useful as a fallback rail rather than a replacement for Apple Pay.

Apple's policy in 2026: App Store rule 5.3 is not the same as Apple Pay web checkout

Operators routinely conflate two unrelated Apple policies and decide Apple Pay is closed to gambling when it isn't. The confusion is worth disentangling because it costs roadmap.

App Store Review Guideline 5.3 governs what real-money gambling apps can and cannot do inside the iOS App Store. The rule is well-defined: real-money gaming apps must hold a license in every jurisdiction they operate in, must be geo-restricted to those jurisdictions, must be free on the App Store, and cannot use Apple's in-app purchase system to fund gambling balances. That last clause is the one that gets misread. It bans IAP for gambling. It does not ban Apple Pay.

Apple Pay on a casino's web checkout, or via a PSP-supplied SDK inside a native app, is a different rail entirely. It runs on the standard Visa or Mastercard tokenized card network, with Apple as the wallet provider and the merchant's PSP as the acquirer side. The 5.3 rule has nothing to say about it.

What this means in practice: a UKGC-licensed operator can take an Apple Pay deposit on its web app today, and a US-licensed operator in New Jersey or Pennsylvania can take an Apple Pay deposit inside the FanDuel or BetMGM iOS app, because both flows route to a third-party PSP rather than IAP. Apple's own list of supported payment platforms confirms which PSPs can be the acquirer side on that flow. The list includes Worldpay, Nuvei, Adyen, Paysafe, Solidgate and dozens of others, in the regions where each PSP holds the relevant network access.

Google's parallel structure is closer to the App Store side than to Apple Pay's web side. Google Pay's general business policy prohibits gambling acceptance, but the Google Pay API documentation carves out an exception for licensed gambling integrations in 18 named countries: Australia, Austria, Canada, France, Germany, Ireland, Italy, Japan, Netherlands, Poland, Spain, Sweden, the UK and a handful of others, with country-specific carve-outs (Cyprus permits only OPAP, Finland only Veikkaus, Kazakhstan permits sports betting but not online casino). Operators outside those 18 countries do not get Google Pay for casino, even with a clean license elsewhere.

The acceptance map: UK debit-only, US state-restricted, EU mostly open, offshore mostly closed

The wallet rails clear where the underlying card acquiring clears. The map below tracks where they reliably enable in 2026, by license stack rather than by player country (the player is anywhere; the operator's license is what the acquirer underwrites).

UK (UKGC-licensed)

Apple Pay clears for UKGC-licensed books, but only on debit cards. The UK Gambling Commission's April 2020 credit card ban applies regardless of the rail funding the deposit, so any credit card a player has linked to Apple Pay will be declined at the issuer layer when the merchant tags MCC 7995. Operators implementing Apple Pay in the UK have to either route only the debit-card portion of incoming wallets or accept a higher decline rate on credit-linked players who do not realise the rule.

Google Pay on the same UKGC stack works the same way mechanically, but with a smaller set of UK casinos advertising it as a primary deposit option. Apple Pay leads the wallet share on iOS in the UK; Google Pay sits second, picked up mostly on Android-first books or as a paired option for cross-OS coverage.

US (state-licensed iGaming and sports betting)

Apple Pay clears at most US books in the seven legal iGaming states (New Jersey, Pennsylvania, Michigan, West Virginia, Connecticut, Delaware, Rhode Island) plus the broader sports-betting jurisdictions, because regulated US operators get MCC 7801 instead of 7995. The 7801 code is treated more permissively by US issuers, and that gap is what makes wallet enablement materially easier on US-regulated books than on offshore ones.

Around 21 brands accept Apple Pay across these states in 2026, including BetMGM, DraftKings, FanDuel, Caesars, bet365, Fanatics and BetRivers, per SportsLine's published list. FanDuel restricted credit-card-via-Apple-Pay in March 2026 according to the same source: Apple Pay still works, but only when the underlying instrument is a debit card or bank account. Google Pay availability is narrower, with a smaller set of brands and routine credit-card blocks at major issuers.

Tribal-licensed Class III gaming and offshore-licensed books targeting US players are a different regime: most do not get Apple Pay or Google Pay at all because the acquirers willing to underwrite them are not on Apple's PSP list for the corresponding card networks.

EU (regulated)

MGA, DGOJ, French ANJ, German GGL, Italian ADM and similar EU regulator stacks all clear Apple Pay through standard PSP integrations. The operator's PSP needs to be on Apple's payment-platforms list for the country in question. That is the only mechanical hurdle. Adyen, Worldpay, Nuvei and Paysafe all carry the relevant access across EU member states. Google Pay clears similarly, scoped by the 18-country list above.

The EU exception worth flagging is Apple's recent NFC opening to third-party wallets across the 30-country EEA, following the European Commission antitrust commitments accepted in 2024. The practical effect on casino acceptance is small in 2026 (Apple Pay is still the dominant on-iOS wallet in EU markets) but operators planning multi-year roadmaps should expect EU wallet share on iOS to fragment as competing wallets gain NFC access.

Offshore (Curacao GCB, Anjouan, Costa Rica)

Apple Pay and Google Pay are mostly closed for offshore-licensed books. The bottleneck is not the wallet. It is that the card acquirers willing to underwrite Curacao or Anjouan operators in 2026 are largely not on Apple's PSP list for the card networks they ride, and the ones that are typically do not pass internal MID-level checks for offshore licensing. Operators on offshore licenses get card-side acceptance through aggregators and crypto-native rails, not through the major-PSP wallet path.

The exception is post-2024 Curacao operators with clean compliance documentation on Paysafe-or-similar acquiring contracts, which can sometimes clear Apple Pay through the underlying acquirer's own MID. Treat that as a per-operator carve-out, not a default.

PSPs that route wallets on MCC 7995 (and the Stripe trap)

Apple's own list of supported payment platforms has 60+ PSPs in the US alone. Most are general-purpose and do not underwrite iGaming MIDs at production volume. The shortlist of PSPs that combine Apple Pay enablement with active MCC 7995 underwriting in 2026 is much smaller. Five candidates from our database carry both:

Worldpay carries Apple Pay across most regulated markets and is on Apple's official platform list with both direct integration and host-to-host options. The wallet enablement piggybacks on the operator's existing UKGC, MGA, or US iGaming MID, so if Worldpay already underwrites the card book, adding the wallet is contract-level not stack-level work.

Nuvei publishes Apple Pay and Google Pay docs with iGaming as a named vertical, runs the AGA partnership in the US sports-betting and casino segments, and reports a ~15 percent multi-market volume lift on portfolios that adopted its full payment stack. The figure comes from a Solidgate case study attributed to the combined network-token plus wallet rollout, not wallets alone, so treat it as the upper bound rather than what wallet enablement alone delivers.

Adyen runs Apple Pay through its standard component on web and API-only on native, and holds banking licenses in EU, UK and US. The AML and licensing checks are stricter than the card-only PSPs above; operators with a clean MGA or UKGC stack get Apple Pay with the card book; operators with thin compliance documentation get rejected at onboarding rather than at wallet enablement. Skip if your KYB documentation is messy.

Paysafe runs Apple Pay across its US and Canada acquiring footprint and is on Apple's list for those regions specifically. The European footprint is thinner on Apple Pay (Worldpay, Nuvei or Adyen are stronger picks for EU-licensed books). The strategic value of Paysafe for wallets is the bundled Skrill, Neteller, and paysafecard wallet brands underneath the same parent, which gives operators serving European players three wallet rails on one contract.

Solidgate's Apple Pay and Google Pay docs are PSP-level rather than acquirer-level. Solidgate sits in front of multiple acquirers and routes wallet transactions through whichever underlying acquirer is most likely to clear at any given issuer. The pricing premium over direct acquiring is the orchestration cost; the value is failover when one underlying acquirer pulls out of iGaming or rate-jacks mid-contract.

The Stripe trap is the misread that operators run into more often than any other on this topic. Stripe is on Apple's PSP list. Stripe supports Apple Pay at the integration layer. Stripe also explicitly prohibits gambling, betting, lotteries, and skill-based gaming for money in its Treasury and Financial Accounts requirements and across its general acceptable-use policy. The fact that Stripe technically supports Apple Pay says nothing about whether Stripe will underwrite a casino MID. It will not. Same logic for Braintree (PayPal) and Square. A PSP being on Apple's list is necessary but not sufficient; the operator's MID has to clear that PSP's own iGaming policy first.

Deposit-only by default: payouts run on push-to-card, not Apple Pay

The wallet rails are pull-only on the merchant side. Apple Pay and Google Pay carry the customer-to-merchant card transaction with the wallet's tokenized card credential; they do not carry merchant-to-customer payouts back to the wallet. Casinos that advertise "Apple Pay withdrawals" are doing one of two things: pushing the payout to the underlying debit card linked in the wallet, or running Visa Direct or Mastercard Send rails to the same debit card the deposit flowed through.

Visa Direct is the dominant US gambling-payout rail. FanDuel was the first US sportsbook to offer real-time payouts on Visa Direct, and the pattern has spread to most major US iGaming brands. The mechanics: payouts from the operator's bank to the player's debit card, settling within 30 minutes per Visa's network rules. The card the player used at deposit is the default destination, but the rail itself is independent of Apple Pay.

The integration cost is separate. Adding Apple Pay deposits is a PSP-side configuration on top of an existing acquiring contract. Adding Visa Direct or Mastercard Send for payouts is a separate processor agreement, sometimes with a different vendor entirely. Operators planning a wallet rollout should price both legs upfront. Promising "instant withdrawal back to Apple Pay" is a roadmap commitment to two integrations, not one.

Pull-only also has a fraud implication worth flagging. The wallet token carries device-binding signals at deposit, but the payout flows through the underlying card. Account-takeover patterns where a fraudster adds a stolen card to a fresh device and immediately deposits-and-cashes-out are easier to detect on the inbound side (device fingerprint mismatch on Apple Pay) than on the outbound (which sees only the card number). Risk teams should weight Apple Pay deposits accordingly when KYT signals on the inbound flow are sparse.

Tokenization mechanics: DPAN, MPAN, and what they mean for fraud and refund flow

Apple Pay does not transmit the player's raw 16-digit Primary Account Number. The wallet provisions a Device Account Number (DPAN) at card-add time, tied to the specific iPhone or iPad, and the casino's PSP receives the DPAN plus a transaction-specific cryptogram instead of the actual card number. Refunds and reversals route to the DPAN, which is why a player who deletes Apple Pay from a device loses the refund-trace path on transactions made from that device.

Apple has been rolling out Merchant Tokens (MPANs) on top of the DPAN model since 2024. An MPAN is a merchant-bound version of the DPAN: the same physical card produces a different MPAN per merchant, and the MPAN survives card expiry and replacement. For a casino taking Apple Pay deposits, MPAN is what makes "card on file" work for returning players without storing a real PAN, because the player does not have to re-add a card after a reissue.

The fraud signal mix is different from raw card. On a DPAN transaction, the issuer sees device-binding plus a one-time cryptogram, which is closer to EMV-chip-card data than to a typed card-not-present transaction. Tokenized transactions clear at higher approval rates than typed card-not-present on most issuer benchmarks, which is part of the mechanism behind the Stripe lift number above. The trade-off: DPAN reduces the operator's PCI scope but increases dependence on the wallet provider for refund traceability. If Apple revokes a DPAN, whether for fraud, device-loss reporting, or any other trigger Apple chooses to act on, the merchant side sees an opaque settlement-side decline with no visibility into the cause.

The answer to "should we add Apple Pay and Google Pay?" is almost always yes for operators with a clean license stack and a primary PSP that already underwrites iGaming. The conversion lift from one-tap mobile checkout pays for the integration in the first quarter at any non-trivial volume tier. The harder question is which jurisdictions to enable first and through which PSP, and that map is what this guide answers. Pick the markets where your acquirer is on Apple's platform list, layer Visa Direct or Mastercard Send for the payout side separately, and do not expect Stripe to be the answer when the casino MID hits underwriting.