Guide · Tech · 2026

Apple Pay & Google Pay on UK raffle sites

Name: Turbo IT Raffle & Competition Platform
Price: 99 GBP

Mobile wallets are no longer optional. They're the difference between a raffle site that converts and one that doesn't.

Updated 1 June 20269 min readBy Turbo IT

TL;DR

· 70%+ of UK raffle traffic is mobile. Card-only checkout on mobile loses 50%+ of those buyers.
· Apple Pay + Google Pay are the highest-converting payment methods — one-tap, biometric, no form-filling.
· Setup is gated by your payment processor (Stripe, Cashflows, Worldpay). Apple Pay has a domain-verification step that catches operators out.
· Both work with the existing free-entry route compliance — no separate legal step. They're just better card rails.

Launch with both enabled

Why Apple Pay & Google Pay are now essential

UK raffle traffic skewed mobile for years; by 2026 it's overwhelmingly mobile. Mobile means typing card numbers on a 6-inch screen, getting AVS errors, fumbling 3D Secure SMS codes, and bouncing. Apple Pay and Google Pay eliminate that friction entirely — face/fingerprint, done.

Operators who shipped mobile wallets in 2024-2025 saw measurable, immediate conversion improvements — typically 15-30% lift on the checkout page conversion rate. By 2026 a competitor running Apple Pay against your card-only checkout has a structural conversion advantage you can't ad-spend your way out of.

The mobile conversion data

Mobile card checkout in the UK typically converts 1.5-2.5% (visitor to purchase). Adding Apple Pay + Google Pay typically lifts this to 3-5%. That's a doubling of conversion for the same traffic.

· Apple Pay UK usage: roughly 35-45% of iOS shoppers use Apple Pay when offered, in commerce categories with one-tap support.
· Google Pay UK usage: lower at 15-25% of Android shoppers — Android wallet adoption is more fragmented.
· Checkout abandonment: card-only mobile checkout abandons at 70-85%. Wallet-enabled checkout abandons at 40-55%.
· Time-to-purchase: 4-12 seconds with Apple Pay vs 45-90 seconds for card-only on mobile.

Turbo IT's checkout ships Apple Pay + Google Pay buttons by default on every Launch-tier tenant. Configured at provisioning, no ops work needed.

Get started

Merchant account setup for both

The setup path differs by payment processor. The two most common UK raffle processors are Stripe and Cashflows; both support Apple Pay and Google Pay but with different friction.

Stripe — both wallets are enabled by default for new accounts. Apple Pay requires domain verification (next section). Google Pay works automatically. Stripe Apple Pay docs walk through the process.

Cashflows — both wallets require explicit activation on the merchant account. Apple Pay needs underwriting review (2-5 business days) and domain verification. Google Pay can usually be enabled instantly once Apple Pay is approved.

Worldpay / Adyen — both wallets are standard but configuration is more enterprise-style; expect to work with a relationship manager.

Apple Pay domain verification (the trap)

Apple requires every domain that shows the Apple Pay button to be cryptographically verified. You upload a verification file to a specific URL on your domain, Apple's servers fetch it, and you're approved for that domain. Get this wrong and the Apple Pay button silently doesn't render — no error, just no button.

The verification file goes at /.well-known/apple-developer-merchantid-domain-association on your domain. It must serve over HTTPS with the correct MIME type and exact byte content provided by Apple/Stripe.

The classic trap: the file is hex-encoded text. Many tools "helpfully" decode or normalise it during upload. Serve byte-for-byte what Apple gave you, or verification silently fails. Verified working pattern: store it as a static file, set the correct content-type, never let any framework process it.

For multi-tenant raffle platforms with custom domains, each tenant domain needs its own verification. Turbo IT handles this automatically during provisioning — every Launch-tier tenant gets verified at the subdomain level on day one.

Implementation in your checkout

The UI implementation is straightforward once the merchant account and domain are configured — both wallets render via the Payment Request API (the W3C standard browsers expose). Your checkout component decides whether to show the buttons based on device capability detection.

· Show Apple Pay button when window.ApplePaySession?.canMakePayments() returns true (iOS Safari / macOS Safari with a card in Wallet).
· Show Google Pay button when the Google Pay API isReadyToPay returns true (Chrome / Android with payment method on file).
· Render above the card form — buyer should see the wallet button before they consider typing a card.
· Brand styling follows the official Apple Pay / Google Pay button guidelines — black/white variants, specific button text, no custom branding inside the button.
· Show "or pay by card" as a fallback below the wallet buttons.

Common implementation traps

· Verification file decoded during upload. Serve byte-for-byte what's provided — never let any tool process it.
· Apple Pay button below the card form. Above-the-fold or buyers don't see it.
· Custom button styling. Apple and Google reject implementations that deviate from button guidelines — you'll lose approval.
· Forgetting subdomain verification. Each subdomain needs separate Apple Pay verification. Multi-tenant platforms must handle this per tenant.
· CSP / iframe issues. Apple Pay uses a postMessage flow; strict CSP without the right allowances breaks it silently.
· Cart amount mismatches. The wallet sheet shows the cart total; if your final charge differs (e.g. you add a fee at the last step), the transaction is rejected.

FAQ

Can I use Apple Pay without a separate Apple Developer account?

Yes — when you go via Stripe/Cashflows/Worldpay, the merchant account covers it. You only need your own Apple Developer account for native iOS apps.

Do Apple Pay & Google Pay have different fees?

In the UK, no surcharge over standard card processing. Your processor charges the same rate as a Visa/Mastercard transaction. The wallets themselves don't charge merchants.

Do these wallets work with 3D Secure?

Yes — and they handle it more cleanly. The wallet's biometric authentication is treated as strong customer authentication (SCA) under PSD2, so the explicit 3DS step is often skipped.

Can buyers use Apple Pay with cards added to Wallet from any UK bank?

Yes — Apple Pay supports virtually all UK banks. Same for Google Pay.

What about Klarna / buy-now-pay-later?

Most raffle operators avoid BNPL — the consumer-protection concerns + chargebacks make it unattractive. Apple Pay + Google Pay + standard card is the typical full stack.

Ready to launch?

Apple Pay, Google Pay, free-entry route compliance, instant-win games — all built in. Turbo IT's Launch tier launches you in 1-2 weeks from £99/mo + 19p per ticket.

Get started See pricing Try the demo

Turbo IT