Shopify Checkout Extensibility: what died on August 26, 2026 and how to keep tracking Purchases

On August 26, 2026, Shopify finished auto-upgrading all non-Plus stores to Checkout Extensibility. If your Meta Purchase tracking lived in checkout "Additional Scripts," it stopped running that day. Nothing errored. Nothing warned you. Your Purchase events just stopped.

What changed on August 26?

Shopify replaced the old liquid-based checkout with Checkout Extensibility on every remaining non-Plus store, and the "Additional Scripts" box in checkout settings stopped executing. Any code pasted there — Meta Pixel Purchase snippets, GTM containers, affiliate postbacks — no longer runs on the checkout, thank-you, or order-status pages.

The upgrade was automatic. You did not have to approve it, and Shopify did not migrate your scripts for you. The replacement mechanism is a Custom Pixel running inside Shopify's Web Pixels sandbox — a very different environment, which we cover in detail in our Web Pixels sandbox explainer.

Exactly which scripts stopped firing

Everything in Settings → Checkout → Additional Scripts (the "Order status page" scripts box). In practice that means:

• Meta Pixel fbq('track', 'Purchase', ...) snippets pasted on the thank-you page
• Google Tag Manager containers loaded from checkout, and every tag inside them
• Conversion snippets for affiliates, TikTok, Pinterest, email platforms
• Any custom JavaScript that read checkout.total_price or other Liquid order variables

Scripts in your theme (theme.liquid) still run on storefront pages. That is precisely why the failure is so hard to spot.

Why the failure is invisible

Your storefront Pixel keeps firing PageView, ViewContent, and AddToCart, so Events Manager still shows a live, active pixel. The only thing missing is the event that pays for everything: Purchase. Unless you look at Purchase counts specifically, every dashboard looks green.

Meanwhile Meta's delivery system quietly loses its conversion signal. In the Andromeda era, delivery leans heavily on dense, high-quality conversion feedback. Starve it of Purchases and your campaigns drift toward whatever cheap actions still report — clicks, ViewContent — while CPA climbs.

How do I verify the damage?

Open Events Manager, select your pixel, filter to the Purchase event, and compare daily counts before and after August 26. If Purchases dropped sharply on or after that date while orders in Shopify admin stayed flat, Additional Scripts was your Purchase source and it is now dead.

Cross-check against Shopify: admin → Analytics → total orders per day. Orders steady, Meta Purchases cratered — that gap is the upgrade. If you want a second opinion, run your store through the scanner or the Shopify tracking check.

The three fix paths

1. The native Facebook & Instagram app

Shopify's official Meta integration fires both browser Pixel and CAPI events. It is free and takes minutes. Tradeoffs: you get no control over what is sent, limited visibility when events silently fail, customer-data settings that are easy to misconfigure, and no per-event feedback on match quality. For many small stores it is good enough. When it breaks, you find out the same way you found out about August 26 — late.

2. A Custom Pixel in the Web Pixels sandbox

You can subscribe to checkout_completed in a Custom Pixel and fire the browser Pixel yourself:

jsanalytics.subscribe("checkout_completed", (event) => {
  fbq("track", "Purchase", {
    value: event.data.checkout.totalPrice.amount,
    currency: event.data.checkout.currencyCode,
  }, { eventID: event.data.checkout.order.id });
});

This restores the browser half. It does not restore the server half: the sandbox cannot make direct Conversions API calls to Meta's Graph API. Every buyer on iOS with tracking prevention, behind an ad blocker, or on a network that filters Meta domains still vanishes — a meaningful share of purchases on modern Safari and iOS never fire the browser Pixel at all.

3. A server-side sender outside the sandbox

Send Purchase events to the Conversions API from a server — either your own, a tagging server, or a managed service. Server events are immune to blockers and ITP, can carry hashed email and phone for matching, and keep flowing whatever Shopify does to checkout next. The tradeoff is that someone has to run that server: hashing, retries, monitoring, and deduplication are now your problem — or your vendor's.

The strongest setup is 2 + 3 together: Custom Pixel for the browser signal, server sender for reliability, joined by a shared event ID.

The double-counting warning

If you run a Custom Pixel and a server-side sender, both must send the same `event_id` for the same order — typically the Shopify order ID. Meta deduplicates matching event name + event_id pairs; without it, every order can count twice, inflating ROAS and corrupting optimization. If you cannot share an ID between the two senders, run only one. Details in our deduplication guide.

Fixing it without building it

Caply is the third path as a service: one snippet at https://trycaply.com/v1.js, and managed servers that send Purchase and Lead to Meta's CAPI with SHA-256-hashed email and phone, automatic retries, and event_id deduplication against your browser Pixel. A per-event Match Forecast scores how likely Meta is to recognize each buyer, and Ghost conversions compares what Caply sent against what Ads Manager counted, day by day — so the next silent breakage is not silent. Plans start at $29/month on pricing, with a 14-day trial.

Whatever you choose, choose this week. Every day since August 26 is a day of Purchases Meta never saw.