Taking a different approach here - this is neither a solution guide or a thought exercise, and I'm expecting it to take a while to accumulate value over time. This will be an ongoing process to document the common questions surrounding Shopify's Checkout, from my perspective.
Note: Everything here is simply my personal opinion, and is not officially endorsed by Shopify in any way.
I'll reference dev documentation wherever possible, as I don't intend this to be a a replacement for the official docs. This is for any of you who have read the docs, but still have a lingering '...what?' thoughts which need to be settled.
Hopefully we can all admit to being in that camp every so often, regardless of experience levels. So here it is, a work-in-progress general guide to support a foundational understanding of the Shopify Checkout as of 2025.
USING SHOPIFY REQUIRES THE USE OF SHOPIFY'S CHECKOUT
We have to start here. Using Shopify without it's Checkout would be like booking a table at restaurant, but bringing your own home-cooked meal to eat instead of ordering anything. You get none of the intrinsic benefits of the platform, it's much more difficult on you to maintain, and everyone has a disjointed experience. Bypassing Shopify's Checkout violates the terms of service, which definitively underlines how tightly coupled the Checkout is with the rest of the platform.
If you've been around the Shopify ecosystem for a while prior to 2023, you no doubt remember checkout.liquid and all it's intricacies. Every so often, a new version of checkout would be introduced to bring quality of life features or regulatory changes and if you had a customised checkout, you'd have to ensure the new version was compatible with your custom code, or otherwise stay on an outdated checkout version which meant missing out on all of the features that Shopify was researching and building on your behalf.
Now, as of the Introduction of Checkout Extensibility in Feb 2023, everyone gets the same base Checkout to build upon. Modifications to Checkout are sandboxed so that compliance and security of the base aren't impacted, and you can't as easily shoot yourself in the foot by 'breaking' your own Checkout. There's no longer any required upgrade path, so everyone gets the same benefits of Shopify's Checkout research and development regardless of their customisations.
HOW MUCH CAN I DEVIATE FROM THE BASE CHECKOUT?
Essentially, the Checkout you get when you first spin up a Shopify environment includes more or less the foundational pieces that you can't move around. A good way to see this baseline is starting a developer preview store (as a Shopify Partner) and just seeing what the defaults of Checkout are for a fresh store.
For example, I can't bring the Order Summary over to the right hand side of the screen, or align the shipping & payment sections to be side by side.
If you're a little less hands-off, here's a quick visual guide:
WHAT ABOUT OPTIMISING CHECKOUT FOR MOBILE?
While we're on the topic of a 'base' Checkout, it makes sense to clarify that Shopify's Checkout comes pre-optimised for mobile screens as standard. As you can see in the example above, there are only minor differences to the structure when viewing the experience in mobile browsers.
To be very clear here - mobile screens are served the exact same Checkout Profile that desktop screens are served. At least at the time of writing (early 2025), there is no separate 'mobile only' profile to split the two experiences based on what type of device is viewing the Checkout.
Serving the Shopify Checkout within an iOS/Android native app is also astonishingly easy, through the Checkout Sheet Kit. You can effectively cross off an entire 12-month native mobile Checkout build from your roadmap.
In theory, when it comes to Extensions, it would be possible to conditionally render or execute them depending on the user's devices. I would approach that via something like this:
-
Identify the session device type on the frontend (whatever your favourite method is).
-
Set the device type for the session as a hidden attribute on the Shopify cart object. [Headed - Cart Ajax API] [Headless - Storefront Cart API]
-
Within the Checkout UI Extension (or a Function's Input), read the cart attribute containing the device type, and conditionally render or execute the extension as a result of the value. [Note - I've written an example of this in practice in an older post.]
HOW FAR CAN I TAKE THE VISUAL IDENTITY?
Pretty far, but with defined boundaries. Today in early 2025, the way you modify the visual identity of Checkout is via the Branding API. Without going into the minutiae of the API, the two major things to note are that:
-
You set a
designSystemwhich determines the visual elements across the whole experience; base Checkout, extensions, apps, etc. -
You can specify
customizations(with the 'z', woof) which determine the specific values of sections or components.
Can you have your own font, colours, spacing, etc? Yes.
Can you have jquery fireworks shoot across the screen after payment? No.
Compare the two versions of the same Checkout below, which I have set up in different Checkout Profiles in my test environment. Note how the framework of the Checkout doesn't drastically change, but I have flexibility over how the base components look, how and where my extensions are rendered, the font and styling, etc.
The visual look and feel Checkout UI Extensions are a completely different discussion. While they inherit the visual identity as defined by the designSystem laid out by the use of the Branding API, extensions declare their interface using the supported UI Components. While Shopify has some UX suggestions, there are no defined rules within UI extensions as to how to implement the components, so they allow for some creative flexibility of what your ultimate build looks like - much in the same way a set of Lego pieces might suggest an x-wing, but your personal result could be a castle.
I WANT TO MAKE NETWORK CALLS FROM CHECKOUT
Cool! Do you know why you want to do that?
In my experience discussing Checkout Extensibility solutions often, this is one of the least understood situations across every size of business. Based on what I typically hear, the 'why' is usually because the team planning an implementation doesn't quite understand the Shopify platform's ethos of being a central source of commerce data, from which all connections can make decisions during a purchase process.
To put it simply - if you can store the data you need within Shopify instead of externally, that should be your first choice.
Not only is it more efficient within Checkout, but the business becomes more efficient with more data closer to the commerce objects that Shopify manages. For example, instead of storing static data like membership validity statuses in an external system, just store it as a customer metafield and keep any changes synced. Save yourself the external request round trips at both the Storefront and Checkout.
I've written about this topic in another post, regarding informing a Function based on external data fetched by a UI Extension.
Checkout UI Extensions can request network access in their configuration. You'd use that to take an input from a customer, send it downstream to do whatever, and then pass any resulting data back to the UI Extension for use within Checkout.
Functions with Network Access is gated to custom apps built for Enterprise clients. This might be used for validating inventory levels from an ERP before allowing the Cart or Checkout to proceed.
Here's an example workflow for an imagined UI Extension using external network access to serve dynamic pick up locations to Checkout:
Again, in both those scenarios, questions should be asked. Is there a good reason why Shopify couldn't be a source of truth for the necessary data? Sometimes the only reason is "that's how our legacy systems work", which should be a wake up call that the business is being held back from progress by a tech team stuck in their old habits.
IS 'SHOP PAY' THE CHECKOUT?
Not really. It's got it's own thing going on entirely. I would describe it as an accelerated wallet that is tightly coupled with the base Checkout and shares a lot of it's core feature set.
The cool thing is because it's a little bit on it's own, it gets some special considerations as to how you can customise it. In this example video, you can see that I'm able to specify if an Extension is rendered or not within the Shop Pay Checkout.
I say this in a purely personal capacity - it's a joy to use. If you can use it, you should. I'm more inclined to purchase something from a brand that has Shop Pay enabled, because it's an easier checkout process that I trust. That said, it's not a requirement, and you can utilise Shopify's Checkout entirely separate from the Shop Pay functionality.
HOW CAN I TRUST THAT CHECKOUT IS SCALABLE?
This is a fair question - until you spend some time in the Shopify landscape and see a few major sales events for yourself.
Yes, the big collaboration you're doing with an influencer is important. A similar influencer is pretty likely to be doing another collab with another brand running on Shopify. Now multiply that scenario by several thousand brands, spread it worldwide, and consider that that's happening every day. The Shopify Platform has to be ready for all of that and more at any given moment, which can't be said for any self-hosted architecture.
I've seen major brands NOT running on Shopify literally close their site and trickle in traffic based on how much capacity their Storefront or Checkout can handle at any given time. Ever bought a concert ticket? You know what I mean.
Regardless of how much I might understand a production engineer's desire to have control over a business' tech architecture, I can't reconcile that with the clear disadvantages it presents. It's expensive and stressful. Why not offload that to a platform that is built to manage those challenges?
It's exceedingly rare on a global scale, but there are cases where Shopify might engage a queue to manage throughput into a store's Checkout. You can actually preview what this page looks like to a customer by adding this query string to the end of any Checkout URL:
?preview=queue
That will send you to a page that looks like this (branded based on your unique Checkout's settings):
I WANT TO IFRAME MY OWN PAYMENT FORM INTO CHECKOUT
Payment Gateways are an integral part of Checkout, so I suppose I couldn't really avoid mentioning them (payments and finance topics make me sleepy). If you have an interest in this question, I have to assume you're either a major multi-national with it's own payment gateway, or are otherwise being asked to pursue this by that type of company.
The short answer is - you cannot do this as stated. You can't insert an iframe into Checkout full stop, for good security and compliance reasons.
What you're looking for is Payment Extensions. In order to take control of the Payment form within Checkout, you're essentially going to be building a custom Payment Gateway integration with Shopify, and supplementing the base payment form with any additional fields your gateway might require to process the transactions and complete a Checkout.
If you'd like to suggest any questions, or correct something I've gotten wrong - please get in touch! You can find a contact form at: www.mackiec.xyz/contact
[Last Updated: 03-12-204]