You know the drill. The analytics show a sharp drop-off at checkout. Your eCommerce manager flags it in the monthly review. Someone mocks up a better flow - guest checkout prominent, fewer fields, Klarna front and centre, Apple Pay on mobile. You take it to your agency. And then comes the phrase you've heard before: "That's not possible on this platform."

The request gets filed. The conversion loss continues. Quarter after quarter, you watch customers who have browsed your site, found a product they want, and clicked "Buy" - walk away before they actually buy.

This is not a niche problem. It is one of the most significant and most routinely unaddressed revenue issues in UK mid-market retail. And in most cases, the root cause is not what your agency says it is.

The Scale of What You're Losing

Checkout abandonment is not a rounding error. UK retailers lost £38 billion in abandoned basket revenue in a single recent year - and roughly one in four purchase attempts ends without a completed order. The customers abandoning at checkout are not disinterested. They found your product, they wanted it, they got to the payment stage. And then something stopped them.

The most common culprits are well-documented:

Forced account creation. A significant proportion of shoppers will leave rather than register before they buy. Guest checkout is not a nice-to-have - it is a baseline expectation.
Complicated, multi-step flows. Every additional screen between "I want this" and "order confirmed" is a decision point where the customer can change their mind.
Missing payment options. Around one in eight shoppers abandons specifically because their preferred payment method is unavailable — whether that's Klarna, Apple Pay, or PayPal.
Mobile friction. UK smartphones drive the vast majority of retail traffic, but mobile conversion rates run at roughly half the rate of desktop. The gap is not a consumer behaviour issue. It is a checkout design issue.
Trust signals missing at the moment they matter most. A customer who is uncertain about a brand is most uncertain when they're about to hand over their card details. Generic, platform-template checkouts undermine the trust built everywhere else on the site.

The Baymard Institute - whose checkout usability research is the most rigorous in the industry - estimates that the average large eCommerce site has 32 specific checkout improvements it has not yet made. Each one represents revenue that is currently walking out the door.

"It's Not Possible" Is Not a Technical Verdict

When an agency tells you a checkout change is not possible, they are almost always telling you something true - about the specific platform you're on. What they are rarely saying, because it does not serve their immediate interest to say it, is that the limitation is architectural, not inherent.

There is no law of physics preventing guest checkout from being the default option. There is no technical reason a checkout cannot present Apple Pay and Google Pay as the primary call to action on mobile. Klarna is not inherently difficult to integrate. A single-page checkout flow is not a novel concept. These capabilities are achievable - just not on a platform that treats its checkout as a sealed component that merchants are not permitted to modify.

This is the reality of rigid, monolithic eCommerce platforms. Their checkouts are embedded in the stack and locked by design. Shopify's Checkout Extensibility - the replacement for the deprecated checkout.liquid - permits branding adjustments and the addition of UI blocks in predefined positions. It does not allow custom HTML or CSS. It does not allow a change to the step order. It does not allow third-party payment providers to offer Apple Pay unless the merchant is using Shopify Payments. The fixed checkout step sequence cannot be restructured.

Magento's two-step checkout flow is structurally fixed outside a narrow exception. WooCommerce's transition to block-based checkout broke compatibility with much of the ecosystem that classic checkout relied on, creating genuine developer friction without resolving the underlying inflexibility.

When your agency says "we can only add blocks in the positions the platform allows," or "the checkout step order is fixed," or "we can't change the payment gateway without losing digital wallet support" - each of those statements is accurate. None of them means the improvement you need is impossible. They mean it is not possible on this platform, as currently architected.

What Full Checkout Control Actually Looks Like

Headless checkout - where the checkout frontend is completely decoupled from the commerce backend and communicates via API - removes the platform as the gatekeeper of your customer experience. The checkout is built, owned, and iterated by your team, not licensed from a SaaS vendor with its own commercial interests in how the checkout behaves.

In practice, this means:

The checkout flow is yours to define.

Single-page or multi-step - structured for your specific customer journey, not for the average customer on the vendor's platform. Returning customers can see fewer fields. High-value orders can trigger alternative payment presentation. B2B buyers can see VAT fields. The logic follows your business, not the platform template.

Payment methods are genuinely open.

Klarna, Clearpay, Apple Pay, Google Pay, open banking, PayPal, Stripe, Adyen - integrated directly, surfaced in the sequence that best fits your customer profile and basket mix. BNPL is not buried in a dropdown; it is a first-class option on the page, where it drives actual uptake. Klarna's headless SDK is purpose-built for exactly this - full control over placement, behaviour, and flow.

Mobile checkout is actually designed for mobile.

Not reflowed from a desktop template. Digital wallets as the default CTA. Address autocomplete reducing form completion time significantly. Touch targets that work with actual thumbs. The fields that matter, without the ones that don't.

The checkout feels like your brand.

The URL, the typography, the confirmation page - these are extensions of the brand experience you have built, not a handoff to a generic template that signals to security-conscious UK shoppers that they have left your site. Research is clear that branded checkout domains and consistent visual identity at payment have a measurable impact on conversion.

You can test and iterate.

A/B testing checkout flows, payment method sequencing, field placement, and mobile-specific variations - without waiting for a platform release cycle or a sprint that requires a developer to interpret what the platform allows.

Why Mid-Market UK Retailers Are Most Affected

Enterprise retailers - the household names with eight-figure engineering budgets - run fully custom checkout experiences. Their checkout is not a Shopify template or a WooCommerce extension. It is infrastructure they have built to their specification.

Smaller retailers, where the volume does not justify the investment, operate within platform defaults and generally accept the trade-off.

It is mid-market retailers - typically those turning over between £5m and £100m online - who are caught in the most uncomfortable position. They have the customer volume where checkout friction is costing them meaningful revenue every day. They have a brand identity worth protecting at the checkout stage. They have eCommerce and marketing teams sophisticated enough to know exactly what is wrong and what needs to change. But they are on platforms whose architecture actively prevents the changes those teams are requesting.

The result is a predictable cycle: a problem is identified, an agency is briefed, a constraint is cited, the improvement is deferred, the conversion loss continues.

The Remarkable Difference

Remarkable Commerce's platform was built headless from the ground up, with a React and Next.js frontend that is fully decoupled from the commerce engine beneath it. There are no sealed checkout templates, no predefined zones where UI elements are permitted to live, and no payment provider that the platform restricts by design.

Checkout customisation at Remarkable is not a workaround or an expensive one-off - it is a standard capability of the platform architecture. The 300+ pre-built integrations include payment providers across the full spectrum: digital wallets, BNPL providers, PSPs, and local payment methods. The platform's API layer - supporting REST, GraphQL, webhooks, and event-driven protocols as standard - means that adding a new payment method or restructuring a checkout flow does not require an architectural project.

It requires development work, not a platform negotiation.

For UK mid-market retailers whose current platform cannot support the checkout their business needs, this is the distinction that matters. Not whether checkout customisation is theoretically possible somewhere - but whether the platform you are operating on treats it as a standard capability or an unsupported request.

If your checkout is underperforming and you have been told the improvements you need are not possible, the right question to ask is not how to work around the constraint. It is whether the constraint belongs to the platform - and whether it is time to change that.