Shop Pay vs Custom Checkout: The Real Cost of Owning Your Funnel

Every few months a founder emails us asking whether they should rip out Shopify's checkout and build their own. The pitch is always the same: "We need more control, our conversion is stuck, and our devs can do better." Sometimes they're right. Usually they're about to set fire to eight points of conversion for a feature two customers asked for.

This is the honest version of that conversation — what Shop Pay actually gives you, what Checkout Extensibility can and can't do in 2026, and when a fully custom checkout is worth the pain.

The three checkouts you're actually choosing between

Most teams frame this as "Shopify vs custom". That's the wrong framing. In 2026 you're really picking one of three:

1. Shopify's stock checkout with Shop Pay enabled — hosted, one-tap for returning Shop Pay users, minimal engineering.
2. Checkout Extensibility — same hosted checkout, but with Checkout UI Extensions, Functions, and Web Pixels for custom logic.
3. Fully custom checkout — either headless on Shopify's Storefront API + Cart API, or off-platform entirely (Commerce Layer, Medusa, custom Stripe).

Each has a very different cost curve and a very different ceiling on what you can change.

What Shop Pay actually does

Shop Pay is Shopify's accelerated checkout. When a returning shopper who's used Shop Pay anywhere on the network hits your store, they get a one-tap flow with saved address, card, and shipping. Shopify has published lift numbers in the 5–10% range for stores that enable it; in our engagements we typically see something in that neighborhood on mobile, less on desktop, and more on repeat-heavy verticals like beauty and apparel.

The important part isn't the button. It's the network effect: your first-time visitor might already be a Shop Pay user because they bought a candle somewhere else last week. You get that saved-state conversion boost without ever having seen the customer.

This is the thing custom checkouts can't replicate. You can build the smoothest checkout on earth and it will still ask a first-time buyer to type their address.

When stock checkout + Shop Pay is the right answer

If you're doing under roughly $20M/year in GMV, selling physical goods, and your checkout complaints are things like "we want a custom upsell block" or "we need to collect a VAT ID" — stay on stock. Checkout Extensibility covers almost all of it now.

A non-exhaustive list of what you can do without leaving Shopify's checkout:

• Custom UI blocks (upsells, trust badges, delivery date pickers) via Checkout UI Extensions
• Custom discount, shipping, and payment logic via Shopify Functions
• Server-side analytics via Web Pixels (including consent-gated)
• Custom validation rules (min order, restricted SKUs by region)
• B2B flows: net terms, company accounts, quantity rules

A rough Checkout UI Extension for a delivery-date picker looks like this:

import {
  reactExtension,
  DatePicker,
  useApplyAttributeChange,
  BlockStack,
  Text,
} from '@shopify/ui-extensions-react/checkout';

export default reactExtension('purchase.checkout.shipping-option-list.render-after', () => <DeliveryDate />);

function DeliveryDate() {
  const applyAttributeChange = useApplyAttributeChange();

  return (
    <BlockStack>
      <Text emphasis="bold">Preferred delivery date</Text>
      <DatePicker
        onChange={(date) =>
          applyAttributeChange({ type: 'updateAttribute', key: 'delivery_date', value: date })
        }
      />
    </BlockStack>
  );
}

That's it. No checkout.liquid, no hosted-page hacks, and it survives Shopify's updates. Five years ago this was a Shopify Plus-only nightmare; today it's a Tuesday afternoon.

When Checkout Extensibility starts to hurt

Extensibility is generous but not infinite. The ceiling shows up when you need one of these:

• Multi-step branching flows where step 2's fields depend on a backend call from step 1 (think: insurance products, financing pre-approval, prescription verification).
• Non-standard payment orchestration — routing between PSPs based on BIN, currency, or risk score, or splitting a single order across multiple merchants of record.
• Deeply custom cart mechanics — bundles that recompose on the server, subscriptions with mid-cycle proration, marketplace-style split shipments with per-vendor tax.
• Checkout on domains Shopify doesn't own — in-app native checkout in your own mobile app, WhatsApp-initiated checkout, kiosk flows.

You can hack around some of these with Functions and app proxies, but you'll spend more engineering time fighting the platform than building the feature. That's the signal to consider going custom.

The real cost of a custom checkout

Here's what people underestimate. A custom checkout is not "a form and a Stripe call". It's:

• Tax calculation (Avalara, TaxJar, or Shopify's tax API via headless)
• Address validation and autocomplete (Google, Loqate, or Smarty)
• Fraud scoring (Signifyd, Riskified, or Stripe Radar)
• PSP integration with 3DS2, SCA, and local methods (iDEAL, Bancontact, PIX, OXXO, UPI, whatever your market needs)
• Inventory reservation and race-condition handling
• Discount and gift card logic — the thing that quietly eats six months of your roadmap
• PCI scope management (even with tokenization, you own the audit trail)
• Order-edit and refund flows that reconcile with your ERP
• A/B testing infrastructure, because the whole point was CRO

Our rough number for a production-grade custom checkout, integrated with a headless Shopify backend: 4–7 months of a focused 2–3 person team, plus 15–25% ongoing engineering to maintain. Off-Shopify (Commerce Layer, Medusa, custom) is longer.

And you lose Shop Pay. That's the tax you pay for control.

The honest conversion math

We've watched teams migrate to custom checkouts and see conversion go down 4–8% in the first quarter. Not because the new checkout is worse — it's usually cleaner — but because they lost the Shop Pay network effect and underestimated how many buyers were using it silently.

The teams that came out ahead did one of two things:

1. Kept Shop Pay as one option on a custom cart page and only diverged at the payment step.
2. Ran the custom checkout only for a segment (B2B, subscribers, a specific geography) where Shop Pay penetration was low anyway.

Both are viable. The mistake is a full cutover with no fallback.

A decision framework that actually works

When we're scoping this for a client, we run through a short checklist. If you answer "yes" to three or more of these, custom starts making sense:

• Do you need checkout on a surface Shopify doesn't render (mobile app, WhatsApp, POS you built, embedded partner site)?
• Is your AOV over $500 and does your buyer expect a bespoke flow (financing, quotes, approval chains)?
• Do you sell in a market where local payment methods matter more than card, and Shopify Payments doesn't cover them well?
• Are you a marketplace or multi-vendor operator with split settlement?
• Do you have a product team of 8+ engineers who can own the checkout as a permanent surface, not a project?

If you answered "no" to most of these and you're still tempted, the honest question is whether you have a CRO problem or a checkout problem. They're not the same. Most checkout-conversion issues we've audited turned out to be product-page problems, shipping-cost surprises, or trust-signal gaps — not the checkout itself.

Where Checkout Extensibility is heading

A quick note on the direction Shopify is pushing. Since the sunset of checkout.liquid for Plus merchants, Extensibility is the only supported customization path on the hosted checkout. Functions have picked up more surface area — payment customizations, delivery customizations, cart transforms — and the UI Extension API keeps adding target zones.

The practical read: the gap between "stock checkout" and "custom checkout" has narrowed a lot. Features that used to require going headless (custom validation, dynamic upsells, complex discount stacking) now live inside Shopify's checkout. If you looked at this decision in 2022 and picked custom, it's worth re-evaluating.

Where we'd start

Before you touch checkout code, do this:

1. Instrument your current funnel properly. Cart → contact → shipping → payment → thank-you, with drop-off at each step, segmented by device and new vs returning.
2. Isolate what's actually broken. If drop-off is at shipping, it's a cost or timing problem, not a checkout UI problem.
3. Rebuild the top three fixes as Checkout UI Extensions or Functions first. Ship them in two weeks.
4. Only then, if you're still hitting a ceiling, scope the custom checkout — and scope it as a full product with a maintenance budget, not a sprint.

If you want a second pair of eyes on that funnel or the extensibility work itself, our team does this constantly — take a look at what we do on the e-commerce engineering side. The right answer is usually less code than you think.