One-Page Checkout & The Platform Shift

Shared Shell

One-Page, Shop Pay, and partner checkouts share a single codebase

Years

Migration Timeline

Multi-year effort to move merchants off Liquid checkout

The Bigger Story

One-Page Checkout is the headline, but it's not the real story. The real story is a multi-year platform shift that made One-Page Checkout possible.

Shopify checkout used to be a set of Liquid files that Plus merchants could directly edit. This gave merchants enormous flexibility—they could customize anything. But it created problems at scale. Customized checkouts were non-upgrade safe. When we shipped new features, these merchants couldn't get them without manual migration work. When something broke, debugging meant diff-ing Liquid files. Security patches required merchant-by-merchant rollouts.

The platform shift was moving checkout from "editable templates" to "extensible platform." Modularity. Composability. App-based customizations that work across layouts without touching the underlying code.

One-Page Checkout was the proof that this new architecture worked. The same customizations, the same apps, the same business logic—but now they could render in a three-page format, a one-page format, an embedded format. The platform handles the layout; merchants and apps handle the logic.

The Migration

Moving merchants off years of Liquid customizations was the hard part.

Phase one was straightforward: merchants with no customizations. We had access to their Liquid files, so we could run heuristics to identify who had never touched the defaults. Those moved first.

But the tail was fat. Lots of merchants had lots of customizations. The approach was cohort-based—grouping merchants by customization type, migrating similar ones together, building tools to handle common patterns.

For the biggest merchants, it was hand-to-hand combat. Negotiating which customizations actually mattered. Many didn't—they were legacy cruft that nobody remembered the reason for. The key narrative was lowering cost of ownership. Merchants understood that their brittle, hard-to-maintain custom checkout was a liability. They wanted faster performance, better security, access to new features. Most were willing to trade some pixel-perfect customization for those benefits.

💡

The "cost of ownership" framing changed the conversation. We weren't asking merchants to give up customization—we were offering to take technical debt off their hands.

Design Constraints

Collapsing three pages into one sounds like a UX project. It was really a constraints problem.

The core jobs couldn't be compromised. Contact details, shipping address, shipping method selection, payment entry, discount codes, tax visibility, order summary. All of that had to be at least as clear as it was across three pages. Nothing hidden, nothing harder to find.

The hardest calls were about interaction patterns. Three-page checkout had natural boundaries—you finish contact info, click Continue, move to shipping. Those Continue buttons were load-bearing. They triggered validation, fired analytics events, created clear user feedback.

One page has no Continue buttons. So: how do we know you're done with a section? How do we make sure information loading doesn't feel slow? How do we handle pixel tracking when there are no step boundaries?

The entire ecosystem—merchants, partners, marketing teams—had built workflows assuming step-based funnels. "Cart abandonment at shipping step" was a metric people tracked. When you remove the steps, you're breaking assumptions.

We had to rethink what events meant. Instead of "completed shipping step," we fire events on field completion, section visibility, interaction patterns. The data is richer, but it required retraining how people thought about checkout analytics.

Performance was a major constraint. Server-side rendering mattered. The page had to feel instant even though it was loading more content upfront than any single page in the old flow.

The Shared Shell

Here's the mental model that ties this together: One-Page Checkout is a shell. Everything else is state.

Shop Pay isn't a different checkout—it's One-Page Checkout where we already know the buyer. We have their address, their payment method. It's the fully-known state.

A returning customer with a merchant account? That's partially-known state. Same shell, some fields pre-filled.

A guest buyer? Unknown state. Same shell, all fields empty.

The shell also handles brand layers. Shop Pay brings its own brand on top of the shared shell. Apple Pay and Google Pay—when a buyer returns from those services for final confirmation—bring their branding too. Partner branding in embedded checkout contexts. Merchant branding by default.

Same shell. Different identity state. Different brand layer. All sharing the same business logic, the same components, the same codebase.

This is the long-term vision. Minimize duplication. Every feature ships everywhere. Every optimization benefits everyone. One-Page Checkout isn't a product—it's the foundation that all checkout surfaces build on.

The headline was "Shopify shipped One-Page Checkout." The actual achievement was building a platform where checkout layouts are just configuration, and the hard work of commerce happens in a shared, composable layer underneath.