Headless commerce platform

Problem

The client wanted a back office they owned outright, able to power any frontend and swap storefronts later without a rebuild.

System

Three deployable applications over one shared database. The admin owns the data and logic, the API exposes it, the storefront consumes it.

Outcome

28 feature phases shipped and live. Brand edits land on the storefront with no redeploy, and a full audit closed every critical and high finding.

The client wanted a commerce back office they fully owned: one codebase that could power any frontend, hold the catalog, orders and business logic, and keep the door open to add or swap storefronts later without a rebuild.

I answered with a headless platform split into three deployable applications. The admin owns the data and the business logic, the API exposes it, and the storefront consumes it. Each ships on its own, and a new frontend is a new client of the API rather than a migration.

Brand edits land on the live storefront with no redeploy. Catalog, pricing, CMS pages, policies, announcements and theme colours are owned in the admin and read by the storefront at runtime, and structured content is parsed defensively, so a malformed edit degrades gracefully instead of breaking the page.

The storefront reads through one typed data layer with caching, so it stays fast without the redundant requests common in headless builds.

The API has two doors. Public storefront endpoints are CORS enabled and rate limited, and customer sessions authenticate with Bearer tokens. The private admin API sits behind API key authentication, so the storefront is open to the public and the admin never is.

A full security and code quality audit documented every finding with a severity and file level evidence, and I remediated every critical and high severity issue. The two most serious lived on the API and the gateway edge.

1. HP.01

   Server side price validation

   Checkout resolves every line price again from the database, so a tampered client request can never set its own price.

2. HP.02

   Authenticated payment webhooks

   Paid notifications are verified cryptographically or confirmed again with the provider, which closes the door on forged payment events.

3. HP.03

   Atomic order processing

   Order creation and payment state changes are transactional and idempotent, so nothing is processed twice and no record is orphaned.

Stripe, Mollie and Viva Wallet drive a webhook driven order flow, and on one deployment a pay by bank rail built from scratch joined them on the same contract. The Shopify and WooCommerce handoff is the other integration edge, switched on per destination.

That pay by bank work was part of a payment processor readiness project, written up as Payments readiness.

The audit also covered gift card and coupon integrity, rate limiting on customer authentication, SSRF and stored XSS protection in the media pipeline, and reduced data exposure on the public endpoints.

• Catalog and variations
• Orders
• Role based access
• Coupons
• Inventory and CSV import
• Low stock alerts
• Loyalty points
• Gift cards
• Refunds and returns
• Tax and VAT engine
• Shipping zones and rates
• Verified reviews
• Abandoned cart recovery
• Affiliate tracking
• Stripe subscriptions
• Translation with DeepL
• SEO tooling
• Email notifications
• CSRF and rate limiting
• API key and Bearer auth

• Strict TypeScript
• Automated tests
• Lint and type checks
• Typed API client
• Normalized error handling
• Request timeouts
• Error boundaries and reporting
• Vendor code splitting
• Per route chunks
• Query cache
• Tuned API cache headers
• Documented onboarding

feature phases

28

admin controllers

55+

migrations

34

API routes

56

card gateways + pay by bank

3

Every phase is live, not a roadmap item. Brand edits reach the storefront with no redeploy, the platform deploys with zero downtime, and the audit closed every critical and high finding.