Breaking Down Payment Flows of the Most Popular e-Wallets
In this article:
- Apple Pay and Google Pay replace SMS code with 3DS through device biometrics and a cryptogram — the bank assigns such a transaction full authentication (ECI 05/02), the same as with standard 3D Secure.
- The second and subsequent subscription payments go through as MIT without biometrics.
Online shopping habits changed forever even before AI arrived, in particular with the emergence of digital wallets from giants like Apple and Google. Where a standard checkout used to mean entering sixteen card digits, an expiration date, and a CVV, followed by waiting for an SMS from the bank, today everyone expects to pay in one click. Touching a finger or scanning a face has become the basic standard of convenience — both on websites and in mobile apps.
For a merchant, this brings plenty of upsides: buyers don't drop off at the data-entry stage, checkout conversion rises, and the process itself looks modern and technological. However, behind the outward ease and seamlessness lies a complex mechanic of interaction between smartphones, banks, and payment systems, one that depends on exactly where the payment takes place.
Today we'll take a detailed look at how payments on your website differ from payments in a mobile app, as well as one-time purchases versus subscriptions. Understanding these nuances will help you manage risk properly and understand what's happening technically behind the scenes of these payment methods.
What's Happening "Under the Hood" of Apple Pay and Google Pay?
Besides convenience and speed, digital wallets also provide a high level of payment security. To understand how transactions through digital wallets are protected, it's worth comparing them to classic 3D Secure. In traditional acquiring, 3DS is a verification of the payer's identity by the card-issuing bank (the issuer), where it redirects the user to a special page and asks them to enter a code from an SMS or confirm the operation in the banking app. If the code is entered correctly, what's known as Liability Shift occurs (a transfer of responsibility that matters for the merchant): if it turns out the card was stolen by fraudsters, the bank covers the financial losses, not the merchant. Many interactions are built on this concept, and we'll return to it repeatedly today.
It's well known that Apple Pay and Google Pay don't show the user the familiar 3DS windows with SMS codes at all, while the issuing bank almost always considers such a transaction fully authenticated. How does that happen?
The essence lies in a combination of three technologies: tokenization, on-device biometrics, and one-time cryptograms. When customer adds a card to Apple Wallet or Google Wallet, the real card number (FPAN) is not stored either on the phone or on the tech giants' servers. Instead, the international payment systems (Visa, Mastercard) create a unique digital token for that specific smartphone — a “DPAN.”
The payment flow looks as follows:
- Buyer taps the Apple Pay or Google Pay button and scans their face or finger;
- The smartphone's security chip performs a local biometric check;
- Based on the card token and the specific purchase data, the chip generates a unique “one-time cryptogram,” valid only for that charge;
- Payment gateway sends the token and cryptogram to the bank.
Having received this data package, issuing bank understands that purchase was made from a specific trusted device, and that its owner just passed biometric verification. For the bank, this is a signal of the highest reliability, which is exactly why it assigns the transaction a fully authenticated status (ECI 05 for Visa or ECI 02 for Mastercard). For a business, this means the payment is protected from fraudulent chargebacks in exactly the same way as if the customer had entered an SMS code, since this path is effectively an equivalent of familiar 3DS.
However, this picture looks different depending on exactly where you're selling goods or services: on your website or through official app stores.
Scenario 1. Payments on Your Website (Acquiring)
When you accept payments on your own website through any payment gateway (for example, Stripe, Adyen, and others), your company is the merchant of record, and you yourself are responsible for fraud level and deal with disputes. This is important to understand, since with wallet-store purchases the situation is somewhat different. Let's look at the two main payment models examples.
For one-time sales (electronics, clothing, one-time services), Apple Pay and Google Pay work almost flawlessly nearly every time. Both wallets follow a similar scenario, generating tokens and a biometric cryptogram. With Apple Pay in the browser (Safari), customer pays in a second, and you get full protection from fraud chargebacks thanks to biometrics. It's worth keeping in mind that for Visa, full global liability shift for Apple Pay is guaranteed on devices running iOS 16.2 and newer. On older iOS versions, protection for Visa transactions unconditionally applies only to cards issued by European banks — outside Europe, on older iOS this doesn't always work.
Google Pay in the native Chrome browser has two flows: if card is linked to Google Wallet app on smartphone, cryptogram is transmitted and protection applies; if card is simply saved in Chrome browser profile, Google Pay automatically launches a standard 3DS Challenge with an SMS code right inside the form. Conversion may be somewhat lower, but fraud protection still applies and remains with the merchant. In practice, both wallets each replicate previously invented two-factor authentication technology in their own way.
The nuance of subscription payments is more psychological than technical. Merchants often assume that if the first payment goes through as described above, with full authentication and confirmed, then subsequent charges are protected by that same biometric session. However, the logic here is also identical to card subscriptions, and 2FA occurs only on the first, initiating transaction. On the first payment (CIT), user is on site and personally confirms the charge with their face or fingerprint, which creates the first transaction with the generation of a biometric cryptogram. The customer is happy with the instant payment, and you're protected from fraud with liability shift. But on the second and subsequent months, once the payment moves to MIT status and the buyer isn't on the site at that moment — they're asleep or busy with their own affairs — money is charged automatically in the background. Apple Pay and Google Pay physically cannot transmit a biometric cryptogram for a charge without user present, and acquiring gateway simply takes stored card and sends a regular auto-charge referencing the ID of the first successful transaction. But since there was no biometrics at that moment, payment goes through completely outside the 3DS protocol. As a result, all such payments are made without a second layer of confirmation, just as is typical card subscriptions. This isn't a flaw in the system, but an important point to keep in mind.
Scenario 2. In-app Purchases (App Store and Google Play)
If you sell digital content or subscriptions inside a mobile app for iOS or Android, you're required to use the stores' built-in billing — Apple StoreKit and Google Play Billing. In this model, the very foundation of the process changes: it's not you but Apple or Google itself that acts as the Merchant of Record for the banks.
Inside App Store and Google Play, the difference between a one-off purchase and a recurring subscription is practically invisible. Apple and Google take on full responsibility for potential fraud, since users link their cards to their Apple ID or Google Account, and all purchases are confirmed with a password or ecosystem's biometrics. The stores are responsible for the legitimacy of charges, and if a card happens to be stolen or a customer claims fraud in the second or tenth month of a subscription, bank opens a dispute against Apple or Google, not against the merchant. You don't even have a concept of an “chargeback profile” — you don't risk fines from payment systems and don't spend time drafting appeals.
When it comes to subscriptions, stores themselves continuously control the charges. They have direct integrations with banks and their own mechanisms for handling debts. For example, when customer requests a refund for a subscription, they request it through Apple or Google support. If they approve the refund, that amount is simply deducted from merchant's final monthly payout. That said, none of these services are free — for full fraud protection, acquiring, and payment processing, stores charge a fee of 15%–30% per transaction. By comparison, regular acquiring fees are typically 1.5%–3.5%.
To summarize, we see that Apple and Google have built infrastructures on top of already-existing card mechanisms and have successfully monetized interface convenience along with the shortcomings of traditional finance. You could say the underlying substance is the same, yet the final form for the customer is completely different.
Tokenization has proven its effectiveness and has made its way to the networks themselves; for example, Mastercard plans to move the majority of transactions to tokens as early as 2030. And it's doing so no longer from a checkout-design standpoint, but for security: if raw card data isn't entered at checkout, it's harder to steal, and the level of protection for that information rises to a maximum.
In a fairly short span of time, payments industry has come a long way — from cash to advanced technology — and Monoup breaks down all the details to help you build a payment strategy that keeps balance between high conversion, costs, and protection of your business.
