Architecture·March 2025·9 min read

Frictionless Retail Experience: The Future of Seamless Shopping

"Frictionless" checkout is usually a rebrand for three separate engineering problems: authentication that skips the password prompt, payment details that don't need retyping, and a checkout call that renders the right wallet on the right device. Passkeys, tokenized wallets, and the Payment Request API solve each piece on its own. Skip one and the friction just moves somewhere else in the journey.

The three problems hiding inside "frictionless"

Most vendor pitches treat "frictionless" as a single feature you bolt onto a storefront. It isn't. It's three separable problems that surface at different points in the journey and get solved by different specs.

Authentication: proving who the shopper is without a password field.
Payment credentials: getting card or bank details into the transaction without retyping 16 digits, an expiry, and a CVV.
Cross-device consistency: making both of the above work the same way on a phone browser, a native app, and a desktop tab.

Each of these already has a standards-track answer shipping in production browsers. None of them requires a proprietary SDK locked to one vendor.

Passkeys replace the password, not the login button

A passkey is a FIDO2/WebAuthn key pair generated on the shopper's device. The private key never leaves the device or its secure enclave. Your server only ever sees a public key and a signed challenge, per the W3C Web Authentication API Level 3 specification.

The registration and sign-in ceremony

WebAuthn calls these exchanges "ceremonies" for a reason. They're a fixed sequence, not a form you can rearrange to fit a design comp.

The relying-party server generates a random challenge and sends it with account details to the browser.
The browser calls navigator.credentials.create(), which prompts the platform authenticator: Face ID, Windows Hello, or a hardware security key.
The authenticator signs the challenge with a freshly generated key pair and returns the public key plus an attestation object.
The server verifies the attestation and stores the public key against the account, per MDN's Web Authentication API guide.
On the next visit, navigator.credentials.get() repeats the challenge-response against the stored key. No password field ever renders.

// Simplified registration call — real options need a server-issued
// challenge, relying party ID, and user handle from your backend.
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,
    rp: { name: "Your Store", id: "yourstore.com" },
    user: { id: userId, name: email, displayName: name },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],
    authenticatorSelection: { residentKey: "required" },
  },
});

A passkey is bound to a relying party ID, not stored in a password database. There's nothing to phish in bulk and nothing to leak from a breached hash table, because there's no shared secret sitting on your server in the first place.

What breaks when passkeys go wrong

Passkeys sync within a platform ecosystem — iCloud Keychain, Google Password Manager, Windows Hello — but not across ecosystems. A shopper who registers on an Android phone and later opens your site on Windows in a different browser gets asked to re-register or fall back, a behavior the FIDO Alliance documents directly.

That's the trust model working as intended, not a bug to route around. The fallback path — email and password, or a one-time code — has to exist and has to be tested. Treating it as a rare edge case is how support tickets pile up.

The registration call above set residentKey: "required", which asks for a discoverable credential — one the authenticator can surface without your site first sending an email address. That's what enables a true username-less sign-in button, but it also means the credential itself, not just its reference, lives on the shopper's device or keychain.

Wallets replace re-typing the card, not the payment method

Shop Pay, Apple Pay, and Google Pay solve a narrower problem than passkeys. They store a tokenized card so the shopper never retypes a card number after the first purchase, on your site or anyone else's that shares the wallet.

How wallet tokenization actually works

None of these wallets hand your server a raw card number. Apple Pay on the web returns a payment token generated through the device's Secure Element and decrypted only by your payment processor, per Apple's Apple Pay on the Web documentation.

Shop Pay works the same way inside Shopify checkout: card data is tokenized once at signup and referenced by token on every later purchase, per Shopify's Shop Pay wallet documentation. Google Pay follows the same tokenization model, detailed in Google's Pay API for web overview.

Wallet tokenization and passkey authentication solve different halves of the same problem. A tokenized card without strong authentication just means an attacker who gets into the account can complete a purchase faster.

The Payment Request API is the interoperability layer underneath

Shop Pay, Apple Pay, and Google Pay each expose themselves to third-party checkouts through one browser-native interface: the Payment Request API, standardized by the W3C and documented for implementers on MDN.

Instead of writing separate integration code per wallet, a checkout calls one API and the browser surfaces whichever wallets are actually installed and available on that device.

const request = new PaymentRequest(
  [{ supportedMethods: "https://google.com/pay", data: googlePayParams },
   { supportedMethods: "https://apple.com/apple-pay", data: applePayParams }],
  { total: { label: "Order total", amount: { currency: "USD", value: "84.00" } } }
);
const response = await request.show();

Where this sits relative to checkout forms and checkout flow

This identity-and-payment layer is not the same problem as checkout form design — input types, autocomplete values, error messaging on a single page — and it's not the same problem as checkout flow architecture — step count, guest defaults, payment-method breadth. Both of those are worth their own treatment.

What passkeys and wallets add is persistence across sessions and devices: the shopper who registered a passkey or saved a wallet on mobile shouldn't have to rebuild that trust relationship from zero on desktop three weeks later.

Laid side by side, the four approaches trade off differently on what they remove for the shopper versus what they demand from your engineering team and your fallback coverage.

Approach	What it removes	Where it breaks	Support caveat
Password + saved card	Nothing, by default	Phishing, credential stuffing, retyped card fatigue	Universal, but weakest security model
Passkey (WebAuthn)	The password prompt	Cross-ecosystem device switches without a synced credential manager	Requires a platform authenticator; needs a tested fallback
Tokenized wallet (Shop Pay, Apple Pay, Google Pay)	Card re-entry after first use	Only as available as the wallet's install base on that device/browser	Best invoked through the Payment Request API, not a vendor-specific SDK
Payment Request API	Per-wallet integration code	Still needs a merchant account with each underlying wallet provider	Supported in Chromium and Safari; behavior varies by browser

Rolling this out without breaking existing customers

None of this replaces password-and-card checkout overnight. It sits alongside it, offered as the faster path for shoppers whose device and browser support it.

Detect platform authenticator availability before offering passkey registration; don't prompt on devices that can't complete the ceremony.
Keep email-and-password as the guaranteed fallback, and test it as carefully as the happy path.
Invoke wallets through the Payment Request API rather than separate vendor SDKs, so new wallets show up without a checkout redeploy.
Log which authentication and payment paths shoppers actually complete, separately from which ones are merely enabled — adoption is uneven across device types.

The fallback path isn't a lesser version of the experience. For a meaningful share of your traffic, it's the only version that works, and it's the one that has to hold up under load on launch day.

What this actually costs to build

Passkeys need a backend WebAuthn relying-party library, not a from-scratch cryptography implementation. Open-source libraries handle challenge generation, attestation verification, and signature checking against the spec; the engineering work is mostly around account linking and recovery flows.

Storage is a small, well-defined schema: credential ID, public key, sign counter, user handle, and the authenticator's transport hints. The sign counter matters more than it looks — the spec requires rejecting a credential whose counter goes backward, which is how you catch a cloned authenticator.

Wallets ride on your existing payment processor

Wallet integration is lighter than it sounds if your payment processor already exposes a Payment Request button component. Stripe's Payment Request Button, documented in Stripe's Elements reference, wraps the browser API and returns a processor-native token, so the checkout code doesn't need to speak Apple Pay or Google Pay's wire formats directly.

That's the real cost curve: passkeys are a backend and account-model change; wallets are closer to a checkout-page addition once your processor supports the Payment Request button pattern. Budget and sequence them differently.

If you're deciding where to spend the next quarter of engineering time on this, ship the wallet integration first. It's cheaper, it's mostly UI work against an API your processor already supports, and it earns adoption data before you commit to the bigger account-model change that passkeys require.

FAQ

Do passkeys replace two-factor authentication entirely?

For sign-in, yes — a passkey ceremony already proves possession of the device and, on most platforms, a biometric or PIN check. Step-up verification for high-risk actions like changing a payment method is a separate decision.

What happens if a customer loses the device holding their passkey?

Recovery depends on the platform's credential sync. iCloud Keychain and Google Password Manager both support recovery through the platform account, but your fallback authentication method still needs to exist for shoppers outside those ecosystems.

Is the Payment Request API supported in every browser?

No. Support and wallet availability vary by browser and platform, which is exactly why routing through the standard API instead of per-wallet SDKs matters — the browser handles the feature detection for you.

Does Shop Pay only work on Shopify-built storefronts?

Shop Pay is built for Shopify's checkout, though Shopify documents integration paths for merchants running Shopify's checkout components outside a fully Shopify-hosted storefront.

Does adding wallets remove the need for a guest checkout option?

No. Wallets speed up returning shoppers who've already saved a card; first-time shoppers on an unsupported device still need a guest path that doesn't force an account.

Do I need separate integrations for Apple Pay and Google Pay?

Not if you build against the Payment Request API. Each wallet still needs its own merchant setup, but the checkout code itself doesn't fork per wallet.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.