How to Customize Shopify Checkout After checkout.liquid

What Does Checkout Customization Mean After checkout.liquid?

If you still think checkout customization means editing checkout.liquid or pasting JavaScript into Additional Scripts, that era is over. Shopify retired those surfaces in favor of Checkout Extensibility—a governed stack of editor branding, UI extensions, Functions, and web pixels. The migration is not one deadline for one audience. Plus merchants already moved off checkout.liquid for in-checkout steps in August 2024. The wave most stores face now is post-purchase: Thank you and Order status pages, plus script tags on those pages, with non-Plus merchants targeting August 26, 2026 for script-tag sunset.

That split matters for how you read every blog post that frames checkout customization as a Plus-only problem. Plus still owns the hardest lane—in-checkout UI on Information, Shipping, and Payment steps. But Advanced, Shopify, and Grow merchants have meaningful work on Thank you and Order status extensions and on moving tracking to web pixels. Starter merchants are excluded from several checkout technologies entirely. Plan for your plan before you pick tools.

What Is the Checkout Extensibility Stack?

Checkout Extensibility is not a single product. It is four layers that solve different problems. Treating them as interchangeable is how migrations balloon in scope.

UI extensions cannot scrape the DOM or run arbitrary JavaScript. Functions cannot call external APIs at checkout time. Pixels fire through Shopify's customer events pipeline—not through theme script tags. When something worked in Additional Scripts because it read hidden DOM nodes, extensibility forces a deliberate rebuild on the correct layer.

Which Shopify Plans Can Customize Checkout?

Shopify's official checkout technologies doc splits capabilities by plan. In-checkout Checkout UI extensions and checkout branding through the GraphQL Admin API require Shopify Plus. Thank you and Order status UI extensions and web pixel extensions are available on paid plans except Starter, though some Function APIs remain Plus-only. If you are on Basic, Shopify, or Advanced, your realistic starting points are post-purchase UI extensions, pixels, and public App Store apps—not custom in-checkout UI.

In-Checkout vs Thank You and Order Status: What's the Difference?

Extensions mount on specific checkout surfaces. In-checkout means Information, Shipping, and Payment—Plus only for UI extensions. Thank you and Order status are post-purchase pages where broader plans can add UI extensions and where script tags face sunset on a separate timeline: August 28, 2025 for Plus legacy pages, August 26, 2026 for non-Plus script tags on those pages. Map each legacy customization to the page where it lived, then to the layer that replaces it.

How Do You Inventory Legacy Checkout Customizations?

Before you install a single extension, list what checkout still depends on legacy surfaces. Miss one Additional Scripts block and you will discover it when tracking flatlines after auto-upgrade.

Merchant-safe inventory checklist:

1. Settings → Checkout → Additional scripts and custom JavaScript fields—copy contents to a spreadsheet.
2. Settings → Apps and sales channels—flag apps tagged for checkout, post-purchase, or tracking.
3. Customer events and pixels—note which tags still load via deprecated script injection.
4. Theme code (developer)—search the theme and any private apps for checkout.liquid references or checkout asset overrides.

Developer inventory adds version-control history, Script Editor remnants if you are Plus, and any custom checkout profile work done before 2024. The goal is a row-per-behavior list: what it does, which page it touches, which plan gate applies, and which extensibility layer should own it going forward.

How Do You Map Each Legacy Behavior to a Layer?

Every legacy behavior gets exactly one primary owner. Duplicating discount logic in both a Function and a UI extension, or firing the same event from a pixel and a leftover script tag, creates debugging debt.

For checkout-time logic that used to live in Shopify Scripts, see the Shopify Functions vs Scripts guide—the Function layer is separate from UI extensions and requires a checkout extensibility upgrade before APIs unlock. Theme-level Liquid patterns that touch checkout-adjacent surfaces are covered in the Shopify theme development guide.

How Do You Upgrade and QA on Real Checkout?

Shopify provides an admin checkout upgrade flow under Settings → Checkout. Completing upgrade is not optional cosmetic work—it unlocks Function APIs and removes legacy customization surfaces. Stores that remain unmigrated are auto-upgraded; legacy code is removed, not paused.

Merchant-safe QA workflow:

1. Run a test order on each market you sell into—extensions can behave differently per market.
2. Verify Thank you and Order status pages on mobile and desktop after upgrade.
3. Confirm pixels fire in Shopify's customer events debugger before you delete Additional Scripts.
4. Check that apps you depend on publish checkout extensibility-compatible versions.

Developer QA adds extension deployment via CLI, market override testing on Advanced and Plus, and validation that stateful UI survives market switches. Shopify documents that buyers switching resolved markets can remount extensions—UI that assumes a single stable page session should persist state in local storage.

Why Did Your Thank You Page Upsell Disappear After Aug 26?

If a post-purchase upsell, survey, or loyalty prompt vanished around August 26, 2026, checkout probably still works—the legacy surface that rendered the widget probably does not. Non-Plus script tags and Additional Scripts on Thank you and Order status pages sunset on that date. Shopify removes those injections during auto-upgrade; they do not pause in place. Rebuild visible post-purchase UI as Checkout UI app blocks on the page buyers actually see, and move any tracking that lived in the same script to web pixel extensions.

How Do You Use the Checkout Editor Page Selector?

Thank you and Order status are independent surfaces in the checkout and accounts editor. Configuring one does not copy to the other.

Merchant-safe walkthrough:

1. Settings → Checkout → Customize (or Checkout and accounts editor).
2. Use the page selector at the top—switch between Thank you and Order status; do not assume they share blocks.
3. On each page, open App blocks or Apps and confirm your post-purchase app block is added to the profile your buyers hit after payment.
4. Save, then place a real test order and note which URL loads—some buyers land on Order status when they use account links or email follow-ups instead of the immediate Thank you screen.

Developer step: if the store uses market-specific checkout profiles on Advanced or Plus, repeat the page-selector check per market override. A block on the default Thank you profile will not appear when a regional profile remounts a different layout.

What Should You Verify on Both Thank You and Order Status?

Upsell apps often default to one post-purchase page. After extensibility migration, merchants discover the widget on Thank you but not Order status—or the reverse.

Merchant-safe checklist—run on both pages:

• App block is added in the checkout editor for this specific page, not only installed in Apps.
• Block placement matches the app's docs—main content vs order summary vs footer regions render differently on mobile.
• No duplicate blocks from an old script injection and a new app block fighting for the same slot.
• Checkout profile is published; draft-only editor changes do not affect live buyers.
• Test order completed on the same market and payment method your customers use.

Developer step: confirm the app publishes a checkout extensibility-compatible UI extension version. Legacy post-purchase apps that injected HTML through Additional Scripts need an extensibility release—or a replacement block—not a theme edit.

Why Is the App Installed but the Upsell Still Missing?

Installation and visibility are different gates. Many post-purchase apps require a funnel, offer, or campaign marked Active inside the app before any UI extension renders—even when the app block is placed correctly in the checkout editor.

Merchant-safe checks:

1. Open the post-purchase app and confirm the upsell funnel or widget campaign status is Active, not Draft or Paused.
2. Verify audience rules still match after migration—first-time buyer, product tag, or cart-value filters can silently exclude every order.
3. Confirm the offer targets the same page you configured in the editor (Thank you vs Order status).
4. Re-save the app block in the checkout editor after changing funnel settings; some apps only sync on publish.

Developer step: inspect the app's extension deployment in Shopify admin → Apps → [app] → Extensions (or the partner's deployment logs). A placed block with no published extension version behaves like an empty slot.

Is the Problem Tracking or a Missing Widget?

Additional Scripts often carried two jobs in one paste: a visible upsell or survey and a purchase pixel. After August 26, the whole snippet disappears. Marketing may still see purchases in ad platforms while the on-page widget is gone—or vice versa if only the pixel was rebuilt.

Do not debug attribution inside this guide. If purchases still complete but ad platforms lost signal, use the Shopify pixel tracking breaks guide for Customer events, Pixel Helper, and CAPI split-brain checks—visible upsell UI and purchase pixels are separate extensibility layers. Rebuild visible upsell UI only after you know whether the old script also owned tracking.

What Is the Practitioner Audit Sequence?

When a merchant reports a missing post-purchase widget after the August 26 wave, work in this order so you do not rebuild UI on top of an unmigrated pixel—or chase pixels when the block was never placed.

1. Export archived Additional Scripts from Settings → Checkout (or your pre-migration inventory spreadsheet) and label each snippet: visible UI, tracking only, or both.
2. Map each snippet to one extensibility layer—UI behaviors to Checkout UI app blocks, purchase events to web pixel extensions. Never duplicate the same purchase fire across a pixel and a leftover script.
3. Open Customer events in Shopify admin and confirm checkout_completed fires for a test order before investing in upsell UI debugging. If checkout_completed is missing, fix pixels first.
4. Walk the checkout editor page selector on both Thank you and Order status; add or republish app blocks per page.
5. Confirm the post-purchase app's funnel is Active, then re-test with a live order on mobile and desktop.

What Are Common Checkout Migration Mistakes?

• Assuming theme editor checkout settings replace Plus in-checkout UI extensions—they do not.
• Migrating pixels last and losing weeks of attribution data when script tags sunset.
• Rebuilding DOM-scraping hacks that sandboxed extensions block by design.
• Treating auto-upgrade as optional—unmigrated legacy customizations are removed.
• Installing multiple apps that each inject overlapping checkout logic without an ownership map.
• Placing a post-purchase app block on Thank you but not Order status—or configuring the editor while the app's funnel stays Draft.

Checkout friction still hurts conversion even when the architecture is correct—if orders drop after migration, diagnose UX and performance separately from extensibility compliance. The conversion issues guide covers symptom triage; the Shopify performance optimization guide covers pixel and theme weight after migration.

When Should You Bring in a Shopify Developer?

Bring in a Shopify developer when your inventory surfaces any of the following: leftover Additional Scripts you cannot map to a pixel or extension, apps that no longer maintain extensibility-compatible releases, custom checkout logic that lived in Scripts or checkout.liquid, or multi-market stores where market overrides remount extensions mid-session.

You can often handle branding, simple post-purchase UI via certified apps, and pixel migration through App Store pixel apps without a custom build. Custom Checkout UI extensions, Function apps, and checkout branding via GraphQL are developer-owned work—especially on Plus.

Zqdo's Perspective

Checkout migrations are integration and governance projects, not theme tweaks. When Zqdo audits a store, the first pass is inventory: what still lives in Additional Scripts, which apps own checkout surfaces, whether tracking moved to customer events, and which plan gates apply to each requested behavior. Performance matters too—replacing one script tag with three pixel apps can improve compliance while hurting load time, which is why pixel weight belongs in the same conversation as extensibility.

If your inventory is clean and you only need Thank you page messaging through a certified app, you may not need an agency. If the inventory reveals Script-era logic, orphaned pixels, or apps fighting for the same checkout real estate, a structured migration plan beats another auto-upgrade surprise.