Checkout branding: how far Shopify lets you go now

Two things confuse this conversation, and both are historical. The first is that checkout used to be a Liquid template some stores could edit, which set an expectation of total control that no longer applies. The second is that checkout UI extensions exist, so people assume extensions are the styling mechanism. They are not — extensions run in a sandbox with no access to the checkout page itself, and they render Shopify's components.

Branding is a separate, controlled surface. It attaches to a checkout profile, which is the unit you publish, and it is set either in the checkout and accounts editor by hand or through the Admin GraphQL API by an app. The API route is what makes it a development topic rather than a design one: it can be versioned, reviewed and applied to a draft profile before anyone sees it.

The plan requirement is the first thing to establish, because it ends a lot of scoping conversations early. Shopify documents the mutation as requiring a shop "on a Plus plan or a Development store plan", with the read_checkout_branding_settings and write_checkout_branding_settings scopes and a user holding the relevant permission. If you are not on Plus, checkout branding at this depth is not a project you can start.

The input splits into designSystem and customizations, and the split is a good piece of API design because it matches how the work should be sequenced.

`designSystem` holds the foundational decisions: colour — a global accent and colour schemes covering base, control and button variants — typography with a primary font group "used for most components such as text, buttons and form controls" and a secondary group "used for heading components by default", font sizing, and corner radius. Set these and most of checkout changes at once, correctly, because everything downstream inherits them.

`customizations` reaches into specific areas: the header and its logo, alignment and position; the main column; the order summary and its colour scheme; form controls and checkboxes; the primary button; the footer; the cart link; the buyer journey; the favicon.

The useful discipline is to get everything you can out of the first layer before touching the second. A team that sets schemes and typography properly usually finds that three-quarters of their customisation list is already done. A team that starts in customizations ends up with a set of component overrides that drift away from the design system and have to be re-reconciled every time the brand changes.

The assumption that checkout cannot carry your typeface is out of date. A font group can be a shopifyFontGroup — a family from Shopify's library — or a customFontGroup, which takes your own files.

The mechanism is specific and worth knowing before you promise it to a brand team. Each custom font is a genericFileId, described as "a globally-unique ID for a font file uploaded via the Files api", and the documented constraint is that "Allowed font types are .woff and .woff2", with a weight that "should be between 100 and 900". So the sequence is: upload the file, get its ID, reference it in the font group, apply it to the profile.

The practical catch is licensing rather than technology. A webfont licence that covers your storefront domain does not automatically cover a file hosted in Shopify Files and served into checkout, and that is a question for whoever bought the licence, not for the developer doing the upload. Ask it before the work is scheduled, because the answer occasionally changes what is possible.

The other catch is that you need .woff/.woff2. A brand team handing over .otf files is handing over a conversion step, not an asset.

Three constraints define the ceiling, and none of them is arbitrary.

You cannot style one step differently from another. Shopify states you "can't currently customize styling for individual pages", and that what you set applies across checkout, the checkout queue, UI extensions and customer account pages. Teams occasionally want a different treatment on the payment step, or a distinct look for the Thank you page. The answer is no, and the by-product is that extensions and accounts inherit your design system automatically rather than needing to be styled a second time.

SVG is not supported. "SVG is not a supported image type for styling checkout", so a logo goes in as a raster file at an appropriate resolution. Worth catching at asset handover.

Layout is not yours. You are configuring a design system, not writing CSS. The structure of checkout — what is asked, in what order, in which column — is Shopify's, and that is the trade that lets Shopify keep improving checkout without breaking every merchant who styled it. The last decade of ecommerce is full of bespoke checkouts that were a competitive disadvantage within two years.

One moving part to check rather than trust: the API reference currently marks checkoutBrandingUpsert as deprecated in favour of checkoutAndAccountsConfigurationUpdate, which requires write_checkout_and_accounts_configurations or write_checkout_settings and access to the checkout and accounts editor. If you are building an integration rather than making a one-off change, read the mutation page for the API version you are pinning to before you write against either.

Here is the part a checkout branding article is not supposed to say: almost none of the fine detail matters to revenue, and we would talk most stores out of the long version.

There is a real effect and it is narrow. A buyer arriving at checkout should not feel handed off to a third party — that moment of doubt is worth removing, and it is removed by four things: the logo, the colour scheme, the typeface, and the corner radius that makes buttons and fields look like the ones on your site. That is an afternoon of work with the API, most of it in the design system layer, and it captures essentially all of the available benefit.

Everything after that is taste, and taste at checkout is expensive taste. The order summary's exact background, the checkbox treatment, the header alignment — a week of iteration there competes for budget with the cart page, the delivery-date question, or the mobile product page, all of which are surfaces where buyers are still deciding rather than paying. Checkout is where they have already decided. The job is to not interrupt them.

This is also the honest answer to "should we move to Plus for checkout branding?" — no. Move to Plus for checkout Functions, B2B, multiple storefronts, the API limits or the support model. Branding is a pleasant thing that comes with the plan, not a reason to buy it. When we scope [a Shopify build](/services/build) that includes checkout, branding is a day in the plan and the rest of the checkout work is rules, not looks.

• Shopify store development
• Checkout UI extensions: what belongs in checkout and what does not
• Shop Pay, express checkout and the conversion you are leaving