Shopify Checkout Components: What Plus Merchants Get

Checkout has been the least editable part of a Shopify store for years, and deliberately so. Checkout Components changes that for Plus merchants, allowing the post-cart flow to be composed with drag-and-drop blocks rather than code.

The benefit is obvious: a category of work leaves the development queue. The consequence is less discussed, and it is that the page which takes money can now be changed by more people, more easily, with no review step in between.

What actually became editable

Composition and arrangement. The order of steps, which blocks appear where, how information is grouped, what is emphasised.

Combined with checkout branding — colours, typography, logo, all configured in the admin — a merchant can now change how checkout looks and how it is organised without a developer.

What remains development work:

Logic. Anything conditional. Discount behaviour, delivery customisation, payment method rules — all Functions.

Custom fields with behaviour. Adding a field is one thing; validating it, acting on it, or sending it somewhere is another.

Third-party integration. Anything that has to talk to a system outside of Shopify itself.

Anything the extension points do not support. The model is deliberately bounded, and a handful of things simply remain outside it by design.

The rough division worth remembering: composition is merchant-editable, and behaviour is not.

The governance problem is new

Worth planning for deliberately, because it is the part that catches teams out.

Under the old model, checkout customisation was unambiguously a developer task. Nobody edited checkout.liquid casually — it was dangerous, but it had a clear owner and changes went through whatever review the team had.

Now several people can rearrange the highest-stakes page on the store, and those changes do not pass through a pull request.

The failure mode is not dramatic. It is a conversion drop of a few percent that nobody can explain because nobody recorded what changed that week.

The dated note is the highest-value item and the one most often skipped. The alternative is an investigation that takes longer than the change did.

Measure checkout completion, not conversion

A specific measurement point, because using the wrong number wastes weeks.

Store-wide conversion rate moves for a dozen reasons — traffic mix, campaigns, seasonality, a change three pages upstream. It is too noisy to isolate a checkout change.

The number that isolates it is the proportion of sessions reaching checkout that complete. If that ratio moves after a change, the change is the cause, and you will know within days rather than after a month of arguing about traffic quality.

Watch it by device separately. Mobile and desktop checkout behave differently enough that a change helping one can hurt the other, and an aggregate figure hides that entirely.

A worked example of testing one change properly

Take a concrete case: a merchant wants to move the order summary so it stays visible while scrolling on mobile, instead of collapsing into an expandable line at the top. This is exactly the kind of arrangement change Components makes easy to ship in minutes, which is also what makes it easy to ship carelessly.

Before touching anything, pull the current checkout completion rate for the period you plan to compare against, split by device, since a mobile-focused change should be judged mainly on mobile sessions. Note the date and the exact baseline number somewhere durable, not just in a dashboard you will look at again later and half-remember.

Make the one change. Not the order summary plus a second unrelated tweak someone suggested while you were in there, since a result that moves cannot then be attributed to either change individually. Record the date and description of the change in the same place as the baseline number, following the governance note above.

Where Shopify's native A/B testing for checkout is available, run the new arrangement against the existing one concurrently rather than sequentially. A concurrent test controls for the fact that traffic composition, campaigns and even the day of the week all move completion rates on their own, and a before-and-after comparison across time cannot separate the change from everything else happening at the same time.

Let it run long enough to cover a full weekly cycle at minimum, since checkout behaviour differs by day, and stop only once the sample size is large enough that the difference is not plausibly noise. If mobile completion rate moves against the concurrent control, you have a result you can trust. If it does not move, that is also useful. It means the change was cosmetic rather than the improvement it looked like on a demo device, and the effort is better spent on the funnel step that Shopify's own analytics show losing the most people, as the tip below points out.

Additions cost more than they appear to

The consistent finding about checkout, and the reason easy editability is a risk.

Everything added to checkout competes with completing the purchase. A survey, a newsletter opt-in, a promotional block, an extra optional field — each is individually defensible and collectively they reduce completions.

This is not an argument for a bare checkout. Trust signals, clear delivery information and visible returns terms genuinely help. The distinction is whether an element reduces a doubt or asks for something.

Everything in the lower half has a business reason behind it. The question is whether that reason is worth the completions, and the honest answer is usually that the same information can be collected after purchase, when it costs nothing.

The attribution survey is the clearest example. Knowing how customers found you is genuinely valuable, and asking at checkout is the worst possible moment to find out. Ask on the thank-you page instead: the order is banked, the shopper is relaxed, and response rates are frequently better because nothing is at stake for them.

Test the paths, not the appearance

Checkout is where a fault costs the whole order, so verification needs to be more thorough than for other pages.

• A complete purchase through every accelerated checkout method you have enabled, not just the standard flow.
• Every discount combination a real shopper could reach, including codes still circulating.
• A failed payment, confirming the recovery path works.
• An international address, if you sell across markets.
• Guest checkout, not only logged-in.
• A mid-range phone on a slow connection, which is where most traffic actually is.

Where to actually start

Given the ability to change checkout, the useful question is what is worth changing. The answer for most stores is narrower than the capability suggests.

Fix what is missing before adding what is new. Delivery estimates absent from checkout, returns terms not visible, an order summary that collapses on mobile — these are omissions that cost completions, and closing them is more valuable than any arrangement change.

Reduce steps where you can. Every field a shopper fills is friction, and friction on a phone is expensive. Remove optional fields you do not use. Confirm autofill works on every field. Do not require an account.

Make the total legible early. The most common checkout exit is the moment shipping appears and the total changes. Nothing in checkout fixes that properly — the fix is showing shipping cost earlier, in the cart or on the product page — but a checkout that presents the total clearly at least avoids compounding the surprise.

Then consider arrangement. Grouping, emphasis, order of steps. This is where Components are genuinely useful, and it is worth doing after the substantive problems are closed rather than instead of them.

The instinct with a new capability is to use it extensively. Checkout rewards the opposite — the best checkout is usually the one that asks least and explains most, and a merchant with drag-and-drop composition can build a worse checkout considerably faster than before.

What this signals about the platform

Read alongside the other 2026 releases, the direction is consistent. Horizon moved layout composition into the theme editor. Native A/B testing arrived for themes, checkout and customer accounts. Checkout Components moved the post-cart flow into the admin.

The pattern is that surfaces which previously required a developer are becoming merchant-configurable, one at a time.

For planning, that means budgeting a Shopify build on the assumption that every layout and variation is a development ticket is probably wrong. It also means the skills that matter on a Shopify team are shifting — less Liquid, more design judgement, measurement, and knowing which of the now-configurable things are worth configuring.

And it makes the governance point above more general than checkout. When several surfaces become editable by several people, deciding who changes what, and keeping a record, stops being bureaucracy and becomes the thing that makes a conversion drop diagnosable.

There is a reasonable objection to all of this, which is that review processes are exactly the friction merchants were trying to escape. That is fair, and the answer is proportionality rather than process for its own sake. A homepage banner needs no approval. The page that takes payment does. Distinguishing between them by surface rather than applying one policy to everything keeps the speed where speed is harmless and the care where a mistake is expensive.

For the wider migration picture, see checkout and payments. Functions and the development side are covered in Shopify development, and Horizon in storefront and design.