The Complete Guide to Headless E-Commerce Architecture in 2026

If you've been running an e-commerce business on WordPress or Shopify for more than a few years, you've probably hit a point where the platform is constraining what your business can actually do.

Maybe checkout customisation requires a plugin that costs £200/month. Maybe adding a second storefront means paying for a second Shopify plan. Maybe your page speeds are dragging, your conversion rates are falling, and every developer you talk to tells you the same thing: "The WordPress way to do this is..."

This guide explains what headless architecture is, when it's the right choice, how the major platforms compare, and what a real production deployment looks like.

What "Headless" Actually Means

A traditional e-commerce platform like Shopify or WooCommerce is monolithic — the frontend (what customers see) and the backend (products, inventory, orders) are tightly coupled in a single system. You customise the frontend within the limits of the platform's templating system. The checkout is Shopify's checkout. The cart is WooCommerce's cart.

Headless architecture decouples these two layers. The backend — products, inventory, orders, customers, promotions — runs as an API-only service. The frontend is a completely separate application that fetches data from that API and renders it however it wants.

Traditional:  [Shopify/WooCommerce] → renders frontend + manages backend
Headless:     [Medusa.js API] ← [Next.js Frontend A] + [Next.js Frontend B]

The practical implications:

• The frontend is a React application. It can be as fast, as custom, and as complex as any modern web app.
• The backend is just an API. Any frontend — mobile app, kiosk, voice interface, another website — can connect to it.
• Checkout logic is code. Multi-recipient orders, custom delivery rules, B2B pricing tiers — all programmable, not plugin-dependent.

When Headless Is and Isn't the Right Choice

Headless architecture is not always the right answer. A WooCommerce store selling 50 products with standard checkout requirements is probably fine on WordPress. The overhead of a headless build — both upfront and in ongoing maintenance — isn't justified for every business.

Headless makes sense when:

You need multiple storefronts from one backend. Running three brands? Selling across B2C and B2B channels with different pricing? Headless is the natural model — multiple frontends sharing one inventory.

Your checkout requirements are non-standard. Multi-recipient delivery, complex postcode routing, subscription logic, B2B purchase orders — these are trivial to build in a headless system and genuinely painful to implement in Shopify or WooCommerce.

Performance is a commercial priority. A server-rendered Next.js storefront with edge caching will consistently outperform a dynamically rendered WooCommerce site on Core Web Vitals. If you're paying for Google Ads or doing serious SEO, that performance gap translates directly to conversion rate.

You're scaling beyond the platform's capacity. Shopify Plus starts at roughly $2,500/month. If you're at that scale, a self-hosted headless platform is likely cheaper and gives you more control.

You need custom integrations at the order level. WhatsApp notifications, ERP connectors, custom fulfilment logic — these are order-lifecycle events that headless platforms expose cleanly via webhooks and workflow extensions.

Headless probably isn't worth it when:

• You have a small catalogue with standard checkout requirements
• You don't have (or can't afford) ongoing developer support
• You're early-stage and still validating your business model
• Your team doesn't have the technical capacity to own a more complex stack

Medusa.js vs Shopify Plus vs BigCommerce: The 2026 Comparison

There are three realistic options for a serious headless commerce build in the UK market.

Shopify Plus

Cost: ~$2,500/month + transaction fees
Headless support: Yes, via Hydrogen (React framework) + Storefront API
Checkout control: Limited — Shopify's checkout is the checkout, with customisation through Checkout Extensions
Multi-storefront: Requires separate stores + plans
Self-hosted: No — Shopify hosts everything

Shopify Plus is the right choice if you want the reliability of a managed platform and you don't need deep checkout customisation. The trade-off is cost, platform lock-in, and transaction fees on every order.

BigCommerce

Cost: $400–$1,000/month
Headless support: Yes, via Catalyst framework
Checkout control: Better than standard Shopify — Open Checkout is fully customisable
Multi-storefront: Yes, with Channel Manager
Self-hosted: No

BigCommerce is a reasonable mid-ground for businesses that want headless without the complexity of self-hosting. Less ecosystem than Shopify, but more checkout flexibility.

Medusa.js v2

Cost: Hosting only (~£50–£150/month on Railway for most businesses)
Headless support: Headless-native — no frontend included by default
Checkout control: Complete — checkout is code you write
Multi-storefront: Native via Sales Channels
Self-hosted: Yes — you own the infrastructure

Medusa is the right choice if you need complete control, want to avoid platform fees, and have the development capacity to build and maintain a custom frontend. The flexibility ceiling is unlimited; the trade-off is that you own the complexity.

The Architecture of a Production Medusa.js Deployment

Here's how a real multi-tenant Medusa.js v2 deployment is structured — based on the platform we built for Blooms at London, Epsom Flowers, and On The Hill Flowers.

The Backend Layer

Medusa.js v2 runs as a Node.js application. In production:

• Database: PostgreSQL (managed by Railway or Supabase)
• Hosting: Railway — containerised deployment, automatic deploys from Git, built-in PostgreSQL provisioning
• Storage: S3-compatible object storage for product images (Cloudflare R2 or AWS S3)
• Email: Resend for transactional emails — clean API, React-based email templates
• Payments: Stripe — Medusa's Stripe plugin handles the payment flow natively

Sales Channels

This is Medusa's answer to the multi-storefront problem. A sales channel is a logical partition of your product catalogue:

Backend
├── Sales Channel: Blooms at London
│   ├── Products visible in this channel
│   └── Channel-specific pricing
├── Sales Channel: Epsom Flowers
│   └── Products visible in this channel
└── Sales Channel: On The Hill Flowers
    └── Products visible in this channel

All three channels draw from the same inventory pool. A product can be published to one channel, two, or all three. Prices can be overridden per channel. This is the fundamental primitive that makes multi-brand commerce possible without running separate backends.

The Frontend Layer

Each storefront is a separate Next.js application. They share a component library but have independent:

• Domains and deployment pipelines
• Brand design (colours, typography, logo)
• Navigation and page architecture
• Featured product configurations

The Next.js App Router handles product pages as generateStaticParams routes — they're pre-rendered at build time and served as static HTML from the CDN edge. Category pages, cart, and checkout are dynamic routes.

Custom Workflow Extensions

Medusa v2's workflow engine lets you write custom logic that hooks into the order lifecycle. The extensions we built for the Blooms platform:

Multi-recipient checkout: A custom checkout workflow that allows customers to assign different delivery recipients per line item — different addresses, delivery dates, and personal messages — in a single transaction. At payment, the order is split into discrete fulfilment tasks by recipient.

WhatsApp notification: A Medusa subscriber that fires on order.placed. It formats the order details (product names, quantities, delivery address, requested date) and sends a WhatsApp message to the fulfilment team's shared group via the WhatsApp Business API.

Delivery completion trigger: A scheduled Medusa job that checks orders whose delivery date has passed, marks them as delivered, and fires a customer follow-up email requesting a Google review.

Core Web Vitals: The Performance Case for Headless

Google's Core Web Vitals — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — are direct ranking signals. Google has published data showing a clear correlation between Core Web Vitals scores and conversion rates.

A standard WooCommerce site running on shared hosting typically scores:

• LCP: 3–6 seconds (Google target: under 2.5s)
• CLS: Often high due to late-loading images and dynamic elements

A server-rendered Next.js storefront with edge caching typically scores:

• LCP: Under 1.5 seconds
• CLS: Near zero when image dimensions are declared correctly

The improvement isn't cosmetic. For a business spending £5,000/month on Google Ads, a 20% conversion rate improvement from performance alone — which is consistent with industry data — is an additional £1,000/month in revenue from the same ad spend.

The Migration Process: What Actually Happens

If you're migrating from WooCommerce to a headless Medusa.js platform, here's the sequence:

1. Discovery and architecture design — catalogue size, order volume, checkout requirements, integration list, team capabilities
2. Backend setup — Medusa v2 on Railway, database provisioned, Stripe connected, Resend configured
3. Data migration — products, variants, images, and inventory migrated via Medusa's import tools and custom migration scripts
4. Custom extension development — checkout logic, notification systems, admin dashboard customisations
5. Frontend build — Next.js storefront, connected to the Medusa API, designed to brand
6. Parallel testing — new platform runs alongside the live WordPress site for 2–4 weeks, order processing tested end-to-end
7. DNS cutover — takes minutes; the old site redirects to the new platform
8. Post-launch monitoring — Search Console, Core Web Vitals, order processing, email deliverability

The entire process typically takes 8–16 weeks depending on the complexity of the checkout logic and the size of the catalogue.

Is It Worth It?

The honest answer: it depends on whether your current platform is actively limiting your business.

If you're running a WooCommerce store that converts well, loads reasonably fast, and doesn't need custom checkout logic — the migration cost probably isn't justified yet.

If you're paying Shopify Plus fees, running multiple brands, fighting plugin conflicts, struggling with slow load times, or constantly working around checkout limitations — a headless build pays for itself within 12–18 months in platform cost savings alone, before accounting for the performance and conversion uplift.

We've shipped this in production. If you want to understand whether a headless build makes sense for your business, book a discovery call — we'll give you an honest answer.