Apple Pay and Google Pay Merchant Acceptance: What Operators Actually Build and Run

Most merchants treat Apple Pay and Google Pay as a checkout SDK decision — drop in the button, ship it, done. The button is the easy part. What actually has to be built and run underneath it is a merchant registration process with its own certificates and expiry dates, a token type that behaves nothing like a stored card, an authentication model that changes what liability shift actually means, and a reconciliation identifier that doesn't match the customer's real card. None of that is covered by "we added the SDK."

This article is the acceptance and operations layer specifically — what a merchant configures, receives, and has to keep running. It assumes the credential taxonomy from payment credential vault architecture, which already covers how a device token fits alongside PSP tokens and network tokens; it doesn't re-run that comparison, or the network token vs PSP token trade-offs, or the terminal-level mechanics of card-present acceptance and terminal fleet operations that in-store wallet taps ultimately ride on. What follows is what's specific to Apple Pay and Google Pay as a merchant-facing acceptance method: registration, the payment sheet, authentication and liability, decryption, recurring billing, disputes, and what fails silently.

Domain verification and merchant registration: the step that blocks launches

Both wallets gate production access behind a registration step that has nothing to do with checkout code, and both are more commonly the reason a launch slips than any integration bug.

Apple's requirement is a file on your server. A merchant registers an Apple Pay Merchant ID, creates a Payment Processing Certificate and a Merchant Identity Certificate against it, and then verifies every top-level domain and subdomain that will show an Apple Pay button by hosting a specific file — unproxied, unredirected — at https://[domain]/.well-known/apple-developer-merchantid-domain-association. Apple's servers fetch that file directly; if it's missing, wrong, or sitting behind a CDN redirect, verification fails. Sandbox testing skips this step entirely, which is exactly why domain verification is the thing teams discover late — it works perfectly in every test environment and only becomes a blocker the week of go-live in production.

Most merchants never touch this process directly. Stripe's own documentation is explicit about it: Stripe creates the Apple Merchant ID and Certificate Signing Request on the merchant's behalf and tells integrators not to follow Apple's own merchant-validation process at all — just register the domain through the Stripe Dashboard or API. This is what Apple's Web Merchant Registration API formalises at platform scale: a PSP or e-commerce platform registers many merchant domains under one shared set of keys and certificates, and none of those merchants needs its own Apple Developer account. The trade-off is the same one that runs through the rest of this article — PSP-mediated setup is faster and requires no PCI-relevant infrastructure of your own, at the cost of the PSP now sitting in the middle of a relationship (domain registration, and later, decryption) that a merchant integrating directly would hold itself.

Google's requirement is a console approval, not a file. A merchant registers a Business Profile in the Google Pay & Wallet Console, picks an integration type — Gateway, for merchants routing through a supported PSP, or Direct, for merchants that are themselves PCI DSS compliant and will decrypt payment data on their own servers — adds the calling domain, uploads screenshots of the live integration, and submits for approval. Nothing processes in production until Google approves that submission — budget for a real approval queue, not a same-day toggle, and don't assume a staging approval carries over when the production domain changes.

Web, in-app, and in-store registration aren't the same unit of work either. Web needs the domain-verification step above for every domain rendering the button, including subdomains — Stripe's guidance notes that if a checkout's top-level domain differs from an embedded iframe's domain, both need registering separately. In-app (PassKit on iOS, the Google Pay Android SDK) skips domain verification entirely, depending instead on app-level entitlements and the same Merchant ID — a materially lighter path, and one reason "we already support Apple Pay in-app" doesn't mean the web checkout is ready.

Three acceptance paths, one credential model underneath

Web uses Apple's Payment JS API or the Payment Request API, and Google's Web Payments API — both render a payment sheet inside the browser or, since Safari opened Apple Pay to third-party desktop browsers, hand off to a paired iPhone via a QR code that the customer scans and authenticates on. That handoff path is a real availability constraint worth planning around: a customer on a non-Safari desktop browser without a paired, unlocked iOS device physically nearby cannot complete the flow at all, and Apple's own documentation is blunt that Apple Pay isn't available in every region regardless.

In-app runs through native SDKs — PassKit on iOS, the Google Pay API on Android — presenting the same payment sheet inside the app UI rather than a browser context. The credential and authentication mechanics underneath are identical to web; what differs operationally is the registration path (app entitlements, not domain files) and the fact that an app's Apple Pay button can appear the moment the SDK is wired in, with no separate per-domain verification step to schedule around a release.

In-store is the one channel where the wallet transaction rides entirely on the card-present architecture this article deliberately doesn't re-derive: an NFC-capable terminal reads the phone or watch the same way it reads a contactless card, the device's on-board authentication (below) substitutes for a PIN or signature, and everything downstream — floor limits, offline authorisation, terminal certification, the terminal fleet operations that keep that hardware running — is exactly what those two articles already cover for contactless acceptance generally. Nothing about accepting a wallet tap at a physical terminal is a separate integration from accepting a contactless card; the terminal doesn't know or care which one it's reading.

What the merchant actually receives: device token, not the funding PAN

Whichever channel a transaction comes through, the payload the merchant or PSP receives is structurally the same, and it is never the customer's real card number. Apple's own merchant documentation describes it plainly: the payment sheet returns an encrypted payment token containing a device-specific account number, the transaction amount, and a one-time-use cryptogram. The PKPayment object an iOS or web integration receives wraps that token alongside optional billing and shipping contact data — the token itself, PKPaymentToken, is what a PSP or a merchant's own decryption service unpacks.

The device-specific account number is the DPAN — the device token this article's scope note defers to payment credential vault architecture, linked above, for full taxonomy against PSP tokens and network tokens generally. What's specific to the acceptance layer is what a merchant can and cannot do with it: a DPAN is meaningless charged twice against the same cryptogram, because the cryptogram is single-use by design — there is no equivalent of resubmitting a raw PAN for a retry using the same payload. A failed or declined wallet authorization has to go back through the wallet's own authentication flow again, not a backend retry against the same token-and-cryptogram pair.

This is also where the reconciliation identifier problem starts, covered fully further down: the DPAN's own last four digits are not the card's real last four digits, and a support agent or a fraud reviewer looking at "the card number" on a wallet transaction is, by default, looking at the wrong four digits for the customer's actual card.

The payment sheet: what comes back, and what it changes about fraud checks

Both payment sheets can return more than the token. Apple's sheet can supply billing contact, shipping contact, shipping method, name, phone number, and email — unencrypted, distinct from the encrypted token itself. Google's PaymentData response carries the same shape: an optional email field (only if explicitly requested), a shippingAddress object, and — nested inside the card info — an optional billingAddress, alongside the card network, funding source, and the last-four cardDetails a merchant sees for display.

The operational upside is real and doesn't need an invented conversion number to matter: address and contact data comes pre-filled from the customer's stored wallet profile rather than typed, which is one less place a checkout form gets abandoned mid-fill or filled with a typo that trips a fraud rule downstream.

The operational catch is what this does to two fraud checks merchants build around card-not-present traffic. Address Verification (AVS) still runs on a wallet transaction — the billing address the wallet supplies gets checked against the issuer's records the same as a typed-in address would, and a merchant's own AVS-mismatch rules still apply and can still suspend the transaction. The CVV check cannot run at all, structurally, because the security code is never stored on the device or with the wallet provider in the first place — there's nothing to transmit. A merchant whose fraud rules score a transaction down specifically for a missing CVV match, without accounting for wallet transactions as a distinct category, is scoring every legitimate Apple Pay or Google Pay sale as if it withheld information it was never capable of providing.

Authentication and liability: what device-level auth buys, and what it doesn't

Every wallet transaction carries device-level authentication by construction — this is the one property genuinely unique to wallet acceptance versus a typed card number, and it's worth being precise about what it does and doesn't establish.

The mechanism, for Apple Pay specifically: the customer confirms intent with a physical gesture (a side-button double-click in-store or in-app; the equivalent trigger on web) tied to the device's Secure Enclave, then authenticates with Face ID, Touch ID, or a device passcode. The Secure Enclave verifies that biometric match and only then releases the cryptographic keys used to sign the payment request — authentication happens on the device itself, before any payload leaves it. EMVCo names this category generally: Consumer Device Cardholder Verification Method (CDCVM), cardholder verification performed on the consumer's own device rather than merchant-owned hardware like a PIN pad, governed by EMVCo's own CDCVM Security Requirements and a formal Security Evaluation Process. A wallet transaction structurally combines possession (the device) with either inherence (biometric) or knowledge (passcode) at the moment of payment — the same factor categories SCA is built around, and the reason wallet transactions are routinely treated as carrying their own authentication rather than needing a separate 3DS challenge on top. When an issuer honours that as sufficient versus still requesting a full challenge is the same request-not-guarantee dynamic the SCA exemption strategy playbook covers — device authentication changes what's asserted to the issuer, not whether the issuer must accept it.

Liability shift is the claim most worth being careful with, because it's conditional on both networks, not a blanket property of "the transaction went through a wallet." Google Pay's own documentation is precise: liability shift applies to qualified Mastercard and Visa transactions carrying a specific cryptogram type on an Android device token. Mastercard device-token transactions carry no geographic or category exclusions. Visa device-token transactions do — a merchant has to explicitly enable "Fraud Liability Protection for Visa Device Tokens" in the console, several specific US merchant category codes (money transfer, online gambling, and cryptocurrency-related activity among them) are excluded outright, and transaction amount and currency data must be passed accurately or the transaction doesn't qualify. That Visa condition wasn't even universal until recently — eligibility was previously limited to European-issued cards before being expanded globally, still subject to the same opt-in and accuracy conditions. Apple Pay's picture, per Stripe, is broad but not uniform either: liability shift is supported globally across the major networks, but for Visa specifically it depends on the device running iOS 16.2 or later, with older iOS versions covered only if the card was issued in Europe. A merchant assuming "we accept wallets, so we're covered," without checking network, device-OS, and MCC conditions against its own PSP's dashboard, is assuming a stronger position than either network grants.

PSP-mediated vs direct decryption: who holds the keys

Every wallet token has to be decrypted before it becomes a usable authorization request, and who performs that decryption is a real architectural choice, not just an implementation detail.

The default on both networks routes decryption through the PSP. A merchant on Stripe, Adyen, Checkout.com, or a comparable provider never sees the wallet's cryptographic material at all — the PSP holds the Payment Processing Certificate (Apple) or the registered decryption key (Google) and hands the merchant an already-decrypted, tokenised payment method reference, the same shape as any other PSP-vaulted credential covered in payment credential vault architecture.

Direct decryption exists on both networks as an explicit alternative. Adyen documents a specific API-only path where the merchant decrypts Apple Pay tokens itself, using its own certificate, distinct from Adyen's default managed-decryption flow. Google's equivalent is its DIRECT tokenization type: the merchant generates a NIST P-256 elliptic-curve key pair, registers the public key in the Google Pay & Wallet Console, and decrypts each response using an ephemeral key exchange the response itself supplies — with an explicit gate that the merchant be PCI DSS compliant as validated by a Qualified Security Assessor, plus an ongoing obligation to rotate the encryption key and resubmit PCI documentation annually.

The trade-off runs in a consistent direction on both sides. PSP-mediated decryption means zero incremental PCI DSS scope and no cryptographic infrastructure to build — at the cost of the credential relationship living inside that PSP's systems, the same portability question covered for stored cards generally: a token decrypted only by one PSP gives the merchant no independent relationship with that credential to carry elsewhere. Direct decryption buys that independence, plus flexibility in how decrypted data feeds fraud tooling — at the cost of real, ongoing PCI DSS obligations (key rotation, QSA validation, documentation) a PSP-mediated integration never touches. Most merchants should default to PSP-mediated; direct decryption is a deliberate choice for merchants already carrying PCI DSS scope elsewhere, not an incremental step to take on for wallet acceptance alone.

Recurring and card-on-file with a wallet credential

A subscription charged against a device token inherits a real fragility a subscription charged against a network token or a PSP-vaulted card doesn't have: a DPAN is bound to one physical device. If that device is lost, replaced, or the card is simply removed from the wallet, the DPAN can stop resolving with nothing automatically re-tokenising in its place — a silent, device-side failure mode a merchant's own systems have no visibility into until the next charge declines.

Both networks have moved to address this, in different ways, and it's an active area, not a settled one. Apple's answer is the merchant token, MPAN: requested explicitly via one of three request types (PKRecurringPaymentRequest for subscriptions, PKAutomaticReloadPaymentRequest for balance top-ups, PKDeferredPaymentRequest for pay-later cases like hotel holds), bound to the merchant relationship rather than a single device, so unaffected by the customer switching phones. If the issuer doesn't support MPAN generation for a given request, the merchant falls back to a DPAN — MPAN coverage is issuer-dependent, not universal, so a subscription book still holds a mix of both. Visa had planned to force this migration on its own timeline, announcing that device-bound standing-instruction transactions issued after 30 July 2025 would start being declined — but per Visa's own current guidance, that restriction has been delayed indefinitely, with DPAN standing instructions continuing to be accepted until Visa announces a new compliance date. The best-practice direction hasn't changed; the enforcement deadline that would have forced it has.

Google's approach leans on webhook infrastructure rather than a separate merchant-bound token type: a tokenUpdateUrl a merchant registers receives lifecycle notifications when the underlying payment credential changes — including on card expiry — alongside newer recurringTransactionInfo, deferredTransactionInfo, and automaticReloadTransactionInfo request objects that let a merchant declare billing frequency, amount, and duration up front, closer to how network tokens auto-update on card reissue than to Apple's merchant-token model. The operator takeaway either way: don't build subscription billing against a wallet credential assuming it behaves like a stored card. Check which token type (DPAN or MPAN, gateway or direct) a given subscriber's credential actually is, and build the decline-and-recovery path around the device-loss and card-removal failure modes a typical card-on-file re-authorisation flow — covered generally in the MIT/CIT subscription billing reference — doesn't have to account for.

Refunds and disputes: how the customer identifies the transaction

Refund and dispute mechanics on a wallet transaction follow the same underlying card-network process as any other card payment — Stripe, for one, states this directly: the dispute process for Apple Pay charges is the same as for card payments, and any successful Apple Pay payment can be partially or fully refunded through the same flow. What's genuinely different is identification: the numbers that show up in support tooling, receipts, and the customer's own statement are DPAN digits, not the funding card's digits, and that mismatch is exactly where refund and dispute handling goes wrong if nobody built for it.

Stripe's own explanation of dynamic_last4 is the clearest illustration of the mechanic generally: dynamic_last4 carries the DPAN's last four digits, distinct from the card object's last4, which is the real card's last four digits as separately surfaced by Apple or Google. A customer calling in about a wallet charge may describe their real card's last four digits — the number on the physical card in their hand — while the transaction record a support agent pulls up is keyed to the DPAN's different four digits. Cards added to Apple Card are the sharper edge case: both fields resolve to DPAN digits, because Apple never surfaces the real card number's last four at all, so there is no "real number" to fall back to on that specific card type. Support scripts and refund-lookup tooling that assume "the last four digits" is one consistent number per customer will misroute exactly this class of case; the fix is building lookup by order ID or the wallet-transaction identifier as the default path, with card-digit matching treated as unreliable for wallet-originated charges specifically.

Reconciliation: tying settlement back to an order

Underneath the wallet layer, a wallet transaction settles through the same scheme fee and interchange structure as any other card transaction on that network — a wallet tap doesn't create a parallel settlement rail. What a merchant's settlement and ledger data carries in addition is a wallet marker: Stripe's charge object, for instance, nests wallet-specific detail (including dynamic_last4) inside payment_method_details.card, tagged by wallet type, alongside the same PSP reference and settlement identifiers any card charge carries. The reconciliation mechanics themselves — matching a settlement line back to an internal order, handling the PSP-specific reference-ID chains, building the break taxonomy when something doesn't match — are exactly what the PSP reconciliation failure runbook already covers in full and this article doesn't repeat. The one wallet-specific addition worth building explicitly: store the wallet type and the DPAN's dynamic last-four alongside the standard settlement fields, because that's the pair a support or fraud investigation will actually need to pull up first, and it isn't present on a typed-card settlement row at all.

Failure modes

Domain verification lapses without anyone noticing. Apple's domain verification doesn't carry its own fixed expiry — it expires whenever the domain's TLS certificate does, and Apple's auto-detection of a renewed certificate only works if that renewal actually completes cleanly. A migrated hosting provider or a broken auto-renewal silently drops Apple Pay eligibility on the domain until someone manually redoes verification, and the failure is invisible in monitoring that only checks checkout uptime.

Certificates expire on their own 25-month clock, independent of the domain. Apple's Payment Processing and Merchant Identity Certificates each need renewal on that schedule regardless of domain or SSL status — a second expiry clock a team tracking only domain verification can miss entirely.

Unsupported browsers and devices silently degrade the experience, not fail it outright. A customer on a non-Safari desktop browser without a paired iOS device nearby, or in a region where Apple Pay isn't available, simply doesn't get a working Apple Pay button — there's no error state to alert on, only a channel that quietly underperforms if a merchant doesn't segment conversion data by whether the wallet button was even eligible to render.

Re-platforming a checkout domain breaks Google Pay production eligibility if the new domain isn't re-added and re-approved. Because Google's approval is scoped to a specific registered domain and a submitted set of integration screenshots, a domain migration is a re-approval event, not a configuration change — treat it as a launch-blocking dependency in the migration plan, not an afterthought.

Liability-shift conditions get assumed rather than checked. MCC exclusions, the console opt-in for Visa device tokens on Google Pay, and the iOS-version dependency for Visa on Apple Pay are all real gates a specific merchant can fail without any error message — the transaction just processes without liability protection, discoverable only when a chargeback lands on the merchant's own book.

Support and fraud tooling built around card-number matching mishandle wallet transactions. The DPAN-vs-real-card mismatch covered above, and the CVV-always-absent behaviour on the fraud side, both produce false signals for a team that hasn't explicitly built a wallet-aware branch into its scripts and rules.

Conversion considerations, stated operationally

The honest, sourceable version of "wallets improve conversion" is structural, not a percentage: the payment sheet pre-fills billing, shipping, and contact data from a profile the customer already maintains with Apple or Google, which removes a class of checkout-form abandonment and typo-driven fraud-rule friction that a manually typed card number carries. That's a real, checkable mechanism — fewer required fields, one device-native authentication step instead of typing a 16-digit number and a CVV. It is not the same claim as a specific uplift percentage, and this article deliberately doesn't publish one: uplift figures vary by merchant, category, and measurement methodology, and the industry's most commonly repeated wallet-conversion statistics are rarely traceable to a specific, reproducible source. Measure your own before-and-after conversion rate for wallet-eligible traffic specifically, segmented from the browsers and devices where the button doesn't render at all, rather than importing someone else's number.

What to monitor

A wallet acceptance stack needs its own monitoring surface, distinct from general card-acceptance dashboards:

• Certificate and domain-verification expiry, tracked on its own calendar (the 25-month certificate cycle, and the domain's underlying TLS renewal) rather than assumed to be covered by general infrastructure monitoring.
• Wallet button render rate and eligibility, segmented by browser and device, to catch the silent-degradation failure mode above before it shows up only as an unexplained conversion dip.
• Liability-shift eligibility rate, per network and per condition (MCC, console opt-in status, device OS version where visible), not assumed as a constant.
• Token type mix on recurring billing — DPAN versus MPAN on Apple Pay, gateway versus direct on Google Pay — so a subscription book's exposure to the device-loss failure mode is visible before it shows up as involuntary churn.
• Dispute and refund volume specifically on wallet-originated charges, checked against whether support tooling is actually resolving the DPAN-vs-real-card identification problem correctly, not assumed fixed because the ticket got closed.

What to read next

• Payment credential vault architecture — the full credential taxonomy (raw PAN, vault token, PSP token, network token, device token) this article assumes and doesn't re-derive.
• Network tokens vs PSP tokens — the auth-rate and portability comparison for the non-wallet token types this article deliberately skips.
• Card-present payment architecture — the terminal-level mechanics an in-store wallet tap rides on.
• Terminal estate and POS fleet operations — the day-two operating discipline for the hardware accepting those taps.
• SCA exemption strategy: the operator playbook — how device authentication interacts with issuer-side exemption and challenge decisions.
• Merchant-Initiated Transactions: SCA, Reason Codes, Auth Rate Impact — the general CIT/MIT and recurring-billing framework a wallet-funded subscription still has to satisfy.
• PSP reconciliation failure runbook — the break taxonomy and matching logic this article's reconciliation section defers to.