How Apple Pay and Google Pay Work

Apple Pay and Google Pay are wallet layers on top of the existing card system. They do not replace the acquirer, card network, or issuer. They change how card credentials are stored, how the customer authorises a payment, and what data reaches the merchant.

The core mechanism is tokenisation. Instead of exposing the underlying card number to every merchant touchpoint, the wallet returns a token or encrypted payment object that the merchant forwards to its processor. The issuer still makes the final approve or decline decision.

1. Card provisioning

Before a customer can pay, the card has to be enrolled in the wallet.

With Apple Pay, the customer adds a card to Wallet on the device. The card data is encrypted, passed through Apple, and handed to the card network and issuer for verification. If the issuer approves, it creates a device-specific token, often called a Device Account Number, plus the keys used to generate transaction-specific cryptograms. That token is stored in the Secure Element, a dedicated hardware component on the device. Apple says it does not store the original card number and that the Secure Element token is not backed up to iCloud.

With Google Pay, the customer selects a card saved to the Google account or adds a new one. Google Pay prepares a payment credential that can be returned to the merchant app or site as a payment token. The exact tokenisation path can vary by processor, network, market, and device capability, but the merchant integration is still designed around receiving a tokenised payload rather than raw card data.

Provisioning is also where many controls run. The issuer can require extra verification, reject a risky device, or refuse to tokenise an ineligible card product.

2. Payment authorisation flow

Once the card is provisioned, the payment itself follows a familiar card authorisation path.

1. The customer taps an Apple Pay or Google Pay button in store, in an app, or on the web.
2. The wallet asks the customer to authenticate with Face ID, Touch ID, device passcode, fingerprint, or another device unlock method.
3. The wallet returns a payment token and supporting cryptographic data to the merchant session.
4. The merchant backend forwards that payload to its gateway or payment processor.
5. The processor or gateway unwraps or maps the payload as required, then sends an authorisation request through the acquirer, card network, and issuer.
6. The issuer checks the token, the cryptographic proof, available funds or credit, and fraud signals, then approves or declines.
7. The response travels back to the merchant checkout.

The important point is that the wallet improves credential security, but it does not remove the ordinary acquiring and issuing stack. Capture, clearing, and settlement still happen later through the card network.

3. Where Apple Pay and Google Pay differ

Apple Pay is closely tied to device-based security. For contactless payments, the Secure Element and a dynamic security code are central to the model. Apple also re-encrypts payment data with a merchant or developer specific key for in-app and web purchases.

Google Pay is broader as a checkout platform. In many integrations the merchant receives a Google Pay token and depends on its processor or gateway to handle the rest. That makes Google Pay flexible across Android apps, web checkouts, and processor-specific token formats.

4. Controls, delays, and failure points

The main controls are tokenisation, user authentication, web domain verification, issuer fraud checks, and processor support for the wallet payload format.

Common failure points are practical ones: card provisioning can fail, the processor may not support the returned token format, device authentication can time out, the issuer can decline the authorisation, or a merchant can hit extra fraud review because of the transaction amount or merchant category.

In short, Apple Pay and Google Pay make card payments safer and easier to start, but the underlying money movement still depends on the same card network, issuer decisioning, and merchant acquiring infrastructure as any other card transaction.