Digital wallet development: Apple Pay Google Pay integration

Yes — Apple Pay works in Chrome, Firefox, and other browsers on iOS since Apple's WebKit restriction was lifted for EU compliance in 2024. On iOS, all browsers use WebKit as their rendering engine, and Apple Pay access through the Payment Request API or Apple Pay JS API is available to all iOS browsers that expose the API. Apple Pay button display and functionality should be tested across Safari, Chrome, and Firefox on iOS to ensure consistent behaviour. On macOS, Apple Pay in Chrome became available in macOS Sequoia and later — older macOS users on Chrome may not have Apple Pay available and should fall back to the card form.

For React SPAs, the recommended approach is using your payment processor's React SDK (Stripe's @stripe/react-stripe-js, Braintree's hosted fields React wrapper) which handles the Apple Pay session management, button rendering, and token processing within the React component lifecycle. If implementing directly without a processor SDK: the Apple Pay session must be initiated within a user gesture (onClick handler) — Apple Pay will not initiate outside a direct user interaction; use useEffect for session event listener setup; and ensure the merchant session validation endpoint call and payment token handling occur server-side, with only the payment token passed from the Apple Pay callback to your server. The most common React implementation error is attempting to initiate the Apple Pay session outside a user gesture (e.g., from a useEffect on load) — Apple's security model requires the session to start directly from a user interaction.

Digital wallet integration using platform wallets (Apple Pay, Google Pay) and a payment processor significantly reduces PCI-DSS scope compared to direct card processing. When using Apple Pay or Google Pay, card numbers never enter your servers — you receive only an encrypted payment token, which your payment processor decrypts. This places your implementation in the SAQ A (Self-Assessment Questionnaire A) scope for PCI-DSS — the lowest and simplest compliance tier — as long as all payment processing is delegated to a PCI-compliant payment processor. You must still: use HTTPS throughout; protect the Apple Pay merchant certificate and private key; implement secure merchant session validation (not exposing your merchant credentials client-side); and validate payment tokens server-side before fulfilling orders. The specific PCI-DSS documentation requirements vary by payment processor — request a SAQ scope confirmation letter from your processor that covers your wallet integration approach.

Apple Pay and Google Pay support recurring payment authorisation through the payment token's network token infrastructure. When a customer authorises a recurring payment with Apple Pay, the payment processor stores a network token (tied to the card's actual number but replaceable by the network if the card is reissued) rather than the raw card number. This significantly reduces subscription churn from card expiration — network tokens automatically update when the underlying card is renewed, maintaining the subscription without requiring the customer to re-enter payment details. Implementation: when processing the initial Apple Pay or Google Pay token for a subscription, instruct your payment processor to create a stored payment method from the token; use that stored payment method for subsequent subscription charges. Stripe, Braintree, and Adyen all support this flow with their subscription management APIs. For PSD2/SCA-regulated markets, initial recurring authorisation requires Strong Customer Authentication (satisfied by Apple Pay's biometric authentication); subsequent merchant-initiated transactions are exempt from SCA under the recurring transaction exemption.

Testing digital wallet integrations requires sandbox environments from both the wallet provider and your payment processor. Apple Pay testing: use Apple Pay Sandbox test cards (available in Apple Developer documentation); test on a real Apple device with Face ID or Touch ID (Apple Pay does not work in browser DevTools or iOS Simulator for testing the actual payment flow); test domain validation by hosting the well-known file on your staging domain. Google Pay testing: Google Pay test environment is enabled through the Google Pay Business Console; test with the Google Pay test card numbers; use Chrome DevTools on Android emulator for initial testing, but verify on real Android devices before launch. Payment processor sandbox environments (Stripe test mode, Braintree sandbox) integrate with wallet test cards — test the full flow from button click to payment confirmation in sandbox before enabling live mode. Test failure scenarios: invalid payment tokens, declined transactions, and user cancellation should all be handled gracefully in the UI without displaying technical error details to users.

Stripe, Adyen, and Braintree (PayPal) provide the most comprehensive and well-documented Apple Pay and Google Pay integration support in 2026. Stripe's approach is the simplest for most developers — Stripe.js handles button rendering, device detection, session management, and token processing with minimal custom code; their documentation covers React, Vue, and vanilla JavaScript implementations in detail. Adyen is the strongest enterprise choice for organisations needing multi-region payment method support alongside wallets — their Drop-in UI supports Apple Pay, Google Pay, and 200+ local payment methods through a single integration. Braintree's Drop-in UI provides the simplest possible integration (a single UI component that auto-detects and renders available payment methods), though with less customisation flexibility than Stripe. For specific markets (Southeast Asia, India, China), regional processors (Razorpay, Pine Labs, PayU) provide better wallet coverage for local wallet methods than global processors.

Button placement and presentation significantly impact wallet adoption rates. Best practices from conversion rate data: show wallet buttons above the card form, not after it — users who see the wallet option first are more likely to use it than users who see it as an afterthought below card fields; use the official payment method buttons (Apple Pay button, Google Pay button) rather than custom styling — users recognise and trust the official buttons; show wallet buttons only when that wallet is available in the current browser/device (use isReadyToPay detection to conditionally render); show a clear visual separator between wallet options and the card form ("Or pay with card") to clarify the relationship; and test button sizing — Apple Pay guidelines specify minimum 30px height, but conversion data consistently shows larger buttons (44–48px) performing better on mobile. A/B testing wallet button prominence (above vs below the fold, size, ordering) on your specific checkout flow is the highest-confidence approach to optimising wallet conversion for your particular audience.

Digital wallet payments have meaningfully lower fraud and chargeback rates than card-not-present transactions for several reasons: device-level authentication (biometric or PIN) provides strong cardholder verification that manual card entry lacks; network tokens (used by Apple Pay and Google Pay) are transaction-specific and cannot be reused by attackers who intercept them; and the card network liability shift applies when the merchant accepts a biometrically-authenticated wallet payment — liability for fraudulent transactions shifts to the card issuer rather than the merchant. In practice, Apple Pay and Google Pay fraud rates are 0.01–0.03% compared to 0.1–0.3% for standard card-not-present transactions — a 5–10× improvement. Chargeback rates are similarly lower. For merchants with significant fraud problems on card payments, prioritising wallet payment method promotion is both a conversion and a fraud reduction strategy. Some payment processors offer lower processing fees for authenticated wallet transactions compared to standard card-not-present rates, reflecting the lower fraud risk.