Express wallets: faster checkout, if you place them right

There is a button in most mobile checkouts that out-converts everything around it, and most stores treat it like a garnish. Express wallets — Apple Pay, Google Pay, Shop Pay, PayPal's fast lane — collapse the entire checkout into a biometric glance: identity, address, payment and shipping option in one sheet, straight from the device the customer is already holding. On stores we've instrumented, mobile wallet checkouts routinely finish in under twenty seconds, against two to four minutes of thumb-typing for the card form. That is not a marginal improvement. It is a different activity.

And yet, in audit after audit — the same forty-check pass we describe in our checkout friction audit — we find the wallet button below the fold, after the card fields, inside a radio-button list, or missing from the cart entirely. The most conversion-dense element on the page, buried. This piece is about where wallets actually belong, the two problems nobody warns you about (the commitment point and address capture), and how to measure what they're really doing — because the default attribution flatters them.

Placement is the product

Wallet performance is mostly placement. The same button, moved, is a different feature.

The PDP comes first. "Buy it now" from the product page is the purest express flow — it skips the cart entirely. It suits single-item, low-consideration purchases: a reorder of coffee, a $40 candle, a replacement filter. It does not suit a store whose revenue depends on baskets. If your average order is three items, a PDP wallet button quietly trains customers to buy one item fast instead of three items slowly. Watch the metric before you ship it. At Fernleigh Wines we deliberately kept the express button off the PDP — a winery lives and dies by the six-bottle case, and one-bottle impulse buys were worth less than the mixed dozen the cart was built to grow.

The cart is the highest-leverage home. The cart drawer or cart page is where intent and basket are both maximal and commitment is still low. Wallets here catch the shopper who has finished deciding and wants out of the funnel. We treat this placement as non-negotiable on stores whose mobile traffic share exceeds half — which is nearly all of them. The button sits beside the primary "Checkout" action, visually second but functionally equal, and it must be the real button (rendered by the payment SDK), not a drawn imitation that bounces people into a form.

The payment step is the fallback, not the headline. Inside checkout itself, wallets belong at the top of payment, above the card form — the placement the audit calls out as the most common unforced error. But a wallet button that only appears at payment has already made the customer walk through shipping fields on their thumbs. By then it's a recovery device, not an express lane.

One placement rule overrides all of this: show only the wallets the device can actually use. Apple Pay on a device without a card enrolled, or on Chrome on Windows, is an advertisement for a competitor's ecosystem. The SDKs give you capability checks. Use them, or don't ship the button.

The commitment-point problem

Here is the paradox that trips up most wallet implementations: express payment works best when the customer has decided, but it's placed where they haven't.

A wallet button on the cart asks "commit to paying $84" before the customer has seen the shipping cost, the delivery window, or the review screen. For some shoppers that's thrilling. For others — particularly on higher-consideration purchases — pressing it feels premature, so they don't, and the button sits there being ignored while the store concludes "our customers don't use wallets."

The fix is sequencing, not removal:

• Resolve the variable costs before the wallet. Shipping estimate on the cart (postcode in, options out), taxes included or clearly flagged. A customer who knows the real total can commit to it. Our rule from the cart design patterns piece applies doubly here: the cart is a negotiation, and you can't ask for a signature before you've tabled the numbers.
• Let the wallet sheet do the last negotiation. Apple Pay and Google Pay sheets can carry shipping options and a final total — the customer picks "Standard $0" or "Express $9" inside the sheet, sees the updated total, then confirms. Designed well, the sheet is the review screen. Designed badly, it confirms first and reveals later, which is a chargeback with extra steps.
• High-consideration purchases get a review step after the wallet. Order templates, B2B carts, anything over a few hundred dollars: the wallet authorises payment, then a review screen confirms before the charge captures. Payment authorisation and order commitment are two events; express flows that conflate them scare exactly the customers with the biggest baskets.

Address capture: the part that quietly breaks

The wallet's address is a convenience that becomes a liability if you treat it as read-only truth.

Old addresses are endemic. People move; their Apple Pay shipping address doesn't. The first failure mode is a parcel sent to a 2023 address. The mitigation is boring and effective: show the resolved address on the confirmation screen in a form that invites correction ("Sending to 14 Church St, Newtown — not right? Tell us within 30 minutes"), and make the order-confirmation email repeat it prominently.

Regional addresses stress the pipeline. Rural routes, new estates, parcel lockers — the same edge cases we test in address lookup — arrive via wallets too, sometimes formatted worse. At Tallow & Co., shipping daily to regional NSW, we found wallet addresses occasionally arrived with suburb and city transposed. The store must validate and normalise after capture, and must be able to reach the customer: always collect email and phone on the express path, because some couriers require them and every delivery exception will.

Wallets aren't an identity system. The email that comes back from a wallet may be a relay, a decade-old iCloud address, or fine. Don't build account-matching logic on it without a confirmation step, and don't withhold the order-confirmation email because "the wallet has their details."

How to tell if wallets are actually working

The default story — "wallet users convert at 92%!" — is selection bias wearing a dashboard. People with a card enrolled, a phone in hand and a decision made were always going to convert; the wallet mostly observes it. Honest measurement asks a different question: did adding or moving the wallet change the store's overall checkout completion?

Run it like any other structural change, with the discipline from our CRO experiment design piece:

• Measure checkout completion overall, not wallet-session conversion. The metric that matters is: of everyone who reached the cart, what share bought? If wallet adoption climbs but overall completion is flat, the wallet is cannibalising card checkouts — fine for support costs, but not the lift you were promised.
• Segment by device and new/returning. Wallets do their real work on mobile and for returning customers. A blended number hides the effect; an iPhone-new-visitor segment is where a wallet placement change will show up first.
• Watch average order value on the express path. If express buyers' baskets are meaningfully smaller, your wallet placement is encouraging single-item speedruns. Sometimes that's right (replenishment businesses), sometimes it's a leak.
• Give it weeks, not days. Wallet adoption has a learning curve — returning customers discover the button on their second or third visit. We pre-commit to a minimum run and kill criteria before launch, or we don't call it an experiment.

One honest caveat for the roadmap: wallet share of payment method is heavily category-dependent. Consumables and reorder-heavy stores see the most; considered purchases the least. If a vendor shows you a universal number, they're selling something.

Key takeaways

• Express wallets collapse checkout to a glance; most stores bury the button below the card form. Placement is the product.
• Cart placement first, payment-step second, PDP only for single-item businesses. Show only wallets the device can use.
• Wallets ask for commitment before customers have seen costs — resolve shipping and total before or inside the sheet.
• Wallet addresses are convenient and stale: confirm visibly, validate after capture, always collect email.
• Measure overall checkout completion, segmented by device — not wallet-session conversion, which is selection bias.
• Pre-commit your run length and kill criteria; wallet adoption compounds over repeat visits.

FAQ

Should we offer Shop Pay and PayPal express alongside Apple Pay and Google Pay? Match the wallet to the audience, not the industry listicle. Mobile-first consumer stores: Apple Pay and Google Pay cover the overwhelming majority. Stores with an existing PayPal-heavy base (common in certain categories and demographics) should keep it. Every additional express option is another button competing for the same commitment moment — two is usually plenty.

Do wallets replace the card form? Never. They're the fast lane, not the only lane. Desktop share is real, corporate cards live in password managers, some customers actively distrust wallets. The card form stays, gets the same craft — brand detection, autocomplete coverage, errors that don't wipe entered data — and remains most stores' largest single payment path.

Wallets or one-click account checkout ("pay with your saved details")? Both, in that order. The wallet serves the guest; the saved-details flow serves the account holder — and account creation should still happen after the first purchase, as we describe in the e-commerce service engagement playbook. Stores that force account creation to get one-click checkout have built a loyalty program that starts with a tax.

How does this fit a wider checkout project? Wallet placement is usually a one-sprint change inside a larger e-commerce engagement — high leverage, low risk, measurable. It pairs naturally with the field-math work and error-copy rewrite from the audit, and it's the piece most clients wish they'd done a year earlier.