Headless checkout

A headless checkout is the shopping cart, address form, shipping selection, and payment flow rendered by a custom frontend rather than by the commerce platform's built-in checkout page. The frontend handles the entire visual and interaction layer. The commerce platform handles cart state, order creation, tax calculation, and payment coordination through APIs. ## Why headless checkout is different In a monolithic ecommerce platform, checkout is a set of pages rendered by the platform itself. Themes can style those pages, and some platforms allow limited customization of the layout, but the checkout runs on the platform's rails. Changing the flow, the field order, the language, or the design past a certain point requires platform-level customization or is not possible at all. A headless checkout inverts the setup. The commerce backend still owns the data and the transaction logic. Cart totals, tax rules, discount validation, inventory reservation, and order creation all happen on the backend. But the pages that a shopper sees during checkout are rendered by the frontend, using the same design system and rendering stack as the rest of the storefront. The result is a checkout that looks and behaves like part of the storefront, not like a separate platform screen. ## What headless checkout enables The most obvious gain is visual consistency. A shopper never leaves the storefront experience to complete a purchase. The second gain is control over the flow. Merchants can add or remove steps, ask questions in a different order, add B2B-specific fields, or run experiments on layout without waiting for the commerce platform to release a checkout update. A less obvious gain is checkout composability. Payment providers can be swapped or offered in parallel. Address autocomplete, tax calculation, and shipping selection can be pulled from best-of-breed services. Klarna, Kustom Checkout, Svea, Walley, and other Nordic checkouts each expose their capability through APIs that a headless frontend can render inline rather than as a redirect. ## Redirect checkout vs inline checkout Some payment providers still prefer a redirect model where the shopper leaves the merchant site to complete payment on the provider's own domain. This is common for BNPL flows and some card processors. Others support fully inline embedded checkout, where the payment UI renders inside the merchant frontend. Both work with a headless setup. The choice depends on the payment provider's SDK, PCI scope preferences, and the merchant's own risk model. ## What headless checkout does not change A headless checkout does not remove the need for the commerce backend to be involved. Cart totals must still be authoritative on the backend. Discounts must still be validated server-side. Tax rules must still come from a reliable source. The frontend cannot be trusted to compute the final price because a hostile client could tamper with the values. Everything sensitive stays on the backend; the frontend only renders and coordinates. ## How Frntkey relates Frntkey ships with a pre-built checkout on both Norce and Shopware. Cart, address, shipping selection, and payment flows all render in Frntkey's design system. Klarna, Kustom, Svea, and Walley are pre-integrated. The commerce backend still owns cart state, tax, and order creation. The Storefront API carries data between the two. Merchants get a checkout that matches the rest of their storefront without building it from scratch. ## Related terms Headless commerce · Storefront API · Ecommerce frontend · API-first commerce