Accelerated Checkout Audit: Apple Pay, Google Pay, Shop Pay, PayPal on Mobile

The contrarian rule most Shopify stores get wrong

If you turn on all four accelerated checkouts and let Shopify auto-detect the order, you are not running a payments strategy. You are running a lottery. The store that wins on mobile picks an order and enforces it, because the order changes conversion more than the buttons themselves. After auditing accelerated checkout stacks across more than two hundred Shopify stores, the pattern that wins on mobile is almost always the same. Apple Pay goes first on iOS. Shop Pay goes second. Google Pay sits in detect only mode so it only shows on Android Chrome. PayPal goes last because its post click flash redirect punishes you on mobile data, and its shipping address sync behavior punishes you on any order where billing and shipping diverge. The one order we never use is PayPal first. It wins the click and loses the order, and we will show the receipts below.

This piece is the audit we run before writing a single line of checkout code for a client. It is also the argument we use when a merchant insists on keeping a stacking order that is quietly bleeding revenue. If you are a vibe coder shipping Shopify stores, or a founder handing off the last mile, this is the stack that survives a Thursday night mobile ad campaign.

What each accelerated checkout actually is, with the device gates

Accelerated checkouts on Shopify are not all the same mechanism. Shop Pay is the first party express option, native to Shopify, which uses a phone number or email and a one time passcode to pull a stored shipper, billing, and card in about seven tenths of a second. Apple Pay is the wallet baked into iOS and macOS Safari, gated to devices with a provisioned card and Face ID or Touch ID. Google Pay is the Google wallet, gated to Chrome on Android primarily and Chrome desktop with a saved card. PayPal Express is the classic PayPal wallet flow, universal across devices, which renders a button that opens a PayPal authentication layer and returns an approval token to Shopify.

The device gates are not cosmetic. Apple Pay will not render at all in Chrome on iOS, in Firefox on any device, or in any Android browser. Google Pay will not render on iOS Safari. PayPal renders everywhere. Shop Pay renders everywhere but only functions as a true one click when the shopper is logged into a Shop account. If they are not, the Shop Pay button is effectively a phone number capture followed by a passcode step. Merchants who report low Shop Pay conversion are often reporting the share of shoppers who have never linked a Shop account, which is a different problem from the button being broken.

This is why a default theme render is wrong more often than it is right. The theme asks the browser what is available and paints whichever it gets first. That order is not your order. It is the browser vendor's order. Your job is to enforce a render sequence that matches where your shoppers actually convert.

The stacking order that wins on mobile

On a US store selling in USD, on a mobile product detail page, render Apple Pay first. The moment an iOS Safari shopper lands on the PDP, the wallet prompt they recognize is the black pill with the Apple logo. Tap, Face ID, done. Shopify's own checkout data consistently shows that when Shop Pay is available it is chosen two thirds of the time by returning shoppers, but new iOS shoppers without a Shop account will take Apple Pay every single time because their thumb already knows where to go. Shop Pay goes second because on iOS it is the strongest fallback for wallet free users, and on Android it is the primary anchor where Apple Pay does not exist at all. Google Pay goes third, set to detect only. Detect only means you let the Shopify render fall through on Android Chrome where it belongs, but you do not hard code a Google Pay slot that sits dark on iOS and eats vertical space. PayPal goes last. Not hidden, not removed, just last.

Why last for PayPal. Two reasons that compound on mobile. The first is the post click flash redirect. When a shopper taps PayPal on a Shopify PDP, the browser leaves your domain, loads paypal.com, authenticates, and returns. On a mid tier Android on 4G, that round trip can add one and a half to three seconds, and the return animation on iOS Safari flashes a white screen that reads as a broken site to a non technical shopper. The second is the shipping address sync behavior. PayPal's API accepts only one address. Shopify sends the shipping address. If the shopper's PayPal account has a different default, the returned address overwrites the one the shopper entered, silently. For gift purchases, for B2B buyers where billing and shipping diverge, this is a support ticket. Put PayPal last and most shoppers who want it will still find it, while the majority who do not are not distracted by a worse experience dressed up as a primary option.

The UK and Europe reshuffle

The stack above is the US default. It is not universal. On a UK SKU pricing in GBP, PayPal moves up, not down. UK ecommerce data consistently shows PayPal holding a stronger share than it does in the US, with roughly a third of UK digital wallet users reaching for PayPal and PayPal Buyer Protection operating as a known trust trigger on first purchases from unfamiliar brands. UK shoppers also use Apple Pay at rates above sixty percent, with Google Pay around thirty seven percent, so the top two slots remain Apple Pay and Shop Pay, but the third slot swaps. On a UK store the order we run is Apple Pay, Shop Pay, PayPal, Google Pay. On a German store the order changes again because German shoppers trust invoicing and SEPA methods that are not in this stack at all, which is a separate audit. The point is that your accelerated stack is a function of the shopper's market, not a global config.

One thing that does not change across markets. PayPal never goes first on mobile. It wins the click and loses the order. On desktop the redirect is less jarring and the stack can loosen. On mobile it is a rule.

The Apple Pay domain verification trap

The most common reason an accelerated checkout audit uncovers silent revenue loss is the Apple Pay button not rendering on a store that thinks it has Apple Pay enabled. The cause is almost always domain verification on a custom or headless subdomain. Apple requires a verification file to be served at a precise path, slash dot well known slash apple dash developer dash merchantid dash domain dash association, on every domain where the wallet is meant to appear. Shopify serves this file on the primary domain automatically, which is what the help center documents. What the help center does not make loud enough is that each subdomain has to be verified individually. A store running a checkout subdomain, a headless storefront on shop dot brand dot com, or a regional subdomain for a country specific cart, will find that Apple quietly fails the handshake and the button renders blank. You can watch the network tab all day and see no error because Apple's validation failure happens server to server, not in the browser.

The trap deepens on Cloudflare proxied subdomains. Apple's verification process is particular about the SSL cipher suite and certificate chain it accepts, and the default Cloudflare proxy configuration does not always satisfy what Apple asks for. The workaround most experienced teams land on is to serve the verification file from an unproxied A record pointed at a simple origin, or to move the verification subdomain to a dedicated endpoint that presents a clean certificate chain. Until that handshake lands, the Apple Pay slot in your stack is a black rectangle that never paints, which means the top of your accelerated checkout is effectively empty on iOS. That is a conversion bomb that does not page.

The audit step we run is deliberately boring. We curl the association file from every checkout subdomain, confirm it matches the one Shopify is serving on the apex, check the TLS handshake details, and only then trust that Apple Pay is live. Most stores skip this step because the Shopify admin shows Apple Pay as enabled, and the admin is reporting intent, not render.

The PayPal Express shipping address bug we design around

If your product catalog includes gift purchases, bundles that ship to a different address than the buyer, or B2B orders with a separate billing contact, PayPal Express will cost you support tickets. The sequence is well documented and has not been fixed because it is an API constraint on PayPal's side. Shopify forwards a single address to PayPal, which is the shipping address the buyer entered. PayPal takes that address, applies the buyer's default account address to anything it thinks it needs to fill, and returns a payload that Shopify merges back into the order. The net effect is that the address the buyer typed can be replaced by the address PayPal thinks is correct, and the buyer does not see the swap until the confirmation email lands at the wrong recipient.

The design decisions we make around this are two. First, if the store has any meaningful share of gift or B2B orders, PayPal Express stays off the PDP and moves to the cart page only, where the shopper has already committed to the line items and is more likely to proof the shipping step. Second, the order confirmation email is rewritten to make the shipping address the first line of the email, in a size the shopper cannot miss, so that if PayPal has swapped it the shopper catches it inside the thirty minute window where support can redirect without a carrier intercept fee. This is not a fix. This is damage control. The fix would require PayPal to accept a billing and shipping address separately, and it does not.

What the SERP round ups miss

Most write ups about Shopify accelerated checkouts stop at the list. Turn them on, pick a theme that renders the buttons, trust Shopify. That is a 2019 article wearing a 2026 date. The operators we work with have moved past the on off question and into three harder ones. First, what is the render order on mobile for my primary market. Second, is every accelerated method actually rendering on every device I claim to support, verified by real device testing, not by an admin toggle. Third, is the stack the same for my US and UK and German SKUs, and if it is, why.

The other thing the round ups miss is that Shop Pay adoption is not the same as Shop Pay enabled. A merchant can switch Shop Pay on and still see a twenty percent opt in rate because the Shop login nudge in the theme is weak, or because the brand has never communicated that Shop Pay remembers your card across Shopify stores. The number to report to a founder is Shop Pay's share of completed checkouts, not Shop Pay's share of buttons clicked. Those are different funnels. The share of clicks is a design question. The share of completed checkouts is a trust and familiarity question, and it climbs with a small amount of copy above the stack that names Shop Pay and explains in one line that it remembers the shopper's details.

A render sequence, in plain English

For a US mobile PDP the sequence runs Apple Pay, Shop Pay, Google Pay detect only, PayPal. For a UK mobile PDP it runs Apple Pay, Shop Pay, PayPal, Google Pay detect only. On desktop both orders can relax and we usually test Shop Pay first for returning shoppers because the desktop shopper is more likely to have a Shop account. On the cart page the same rules apply, with the addition that PayPal Express can return to a higher slot on UK cart pages because the redirect penalty is less severe once the shopper has already committed to the cart. On a custom checkout subdomain the stack does not go live until the Apple Pay domain association file has been verified against Apple's server, not against the Shopify admin.

The one order we never use, on any market, on any device, is PayPal first on mobile. It wins the click, flashes white on return, occasionally overwrites the shipping address, and trains the shopper to associate your brand with the checkout that felt a little broken. Every time we have inherited that order from a previous build and moved PayPal down, revenue per session on mobile has moved in the right direction within a single weekend of data.

Where WitsCode fits

If your accelerated stack is a default theme render, a Shopify admin toggle, and a hope that the four buttons will sort themselves out, there is money sitting on the floor that a single afternoon of work will pick up. Our payments CRO audit reads your theme render order, verifies Apple Pay domain association on every active subdomain, tests the stack on real devices in your primary markets, and returns a stack recommendation with the code to enforce it. Shop Pay placement, Apple Pay verification, Google Pay detect only enforcement, and the PayPal slot that matches your market and your catalog. If the audit does not find at least one silent failure, we tell you, and the call is short. Most of the time it finds three. That is the last mile. That is what we do.