Shopify’s August 26 Checkout Deadline: What Breaks Silently for NetSuite-Synced Stores

Shopify’s August 26, 2026 deadline retires checkout.liquid and the Additional Scripts field on the Thank You and Order status pages for every non-Plus store — the last phase of a deprecation Shopify announced in February 2023 and already ran Plus stores through in 2025. Every post covering it this month — and there are a lot of them — treats it as a tracking-pixel problem: Meta Pixel, GA4, TikTok, GTM, gone, replace with app pixels. That’s real, and it’s table stakes. What none of them cover is the non-Plus store where that same Additional Scripts field is doing backend work: firing order data at a NetSuite middleware endpoint, a custom sync service, or an ERP webhook substitute, because nobody built a proper Shopify webhook subscription when the integration first shipped. This post covers both the deadline mechanics and that specific failure mode — what breaks, how to tell if it’s you, and the webhook-based migration that survives the cutover.

On this page

• What changes on August 26, 2026
• Who this deadline actually affects
• The failure mode the marketing-pixel guides skip
• Pre-migration audit: find out if you’re exposed
• Additional Scripts vs. Web Pixels vs. webhook + queue
• Step 1: Read what the script actually does
• Step 2: Register the webhook subscription
• Step 3: Build the ack-fast, HMAC-verified handler
• Step 4: Add dedupe, ordering, and a reconciliation job
• Step 5: Trigger your own cutover
• Rollback plan
• Post-migration monitoring checklist

What changes on August 26, 2026

The deprecation runs in two phases, and conflating them is the most common mistake in coverage of this deadline. Phase one already happened everywhere: checkout.liquid for the Information, Shipping, and Payment steps moved to Checkout Extensibility years ago, and Shopify’s developer docs now call that phase settled — checkout.liquid there is simply unsupported. That part of checkout has nothing to do with this deadline and isn’t at risk.

Phase two is what’s actually ending August 26, 2026: checkout.liquid and the Additional Scripts field on the Thank You and Order status pages. Shopify’s own documentation states plainly that these were sunset for Plus stores on August 28, 2025, and script tags on those same pages “are sunset for non-Plus stores on August 26, 2026.” The field itself went read-only for every store on that same August 2025 date — you can’t add or edit code in it anymore, on any plan — but on non-Plus stores the code already there keeps executing until the auto-upgrade actually happens.

Shopify’s non-Plus upgrade guide is direct about the mechanism: if a store takes no action, “your Thank you and Order status pages will be auto-upgraded to the new pages” on the deadline. Order creation and payment capture are unaffected — those already run on Extensibility from phase one. What changes is only what renders and executes after payment, on the confirmation page.

Who this deadline actually affects

Three conditions, all three required:

• The store is on a non-Plus plan — Basic, Shopify, or Advanced. Plus stores already went through this in 2025; the Pause and Build plan is upgraded on Shopify’s own separate schedule regardless of this date.
• The Additional Scripts field on the Thank You or Order status page currently contains code that does more than fire a known ad-platform pixel — a fetch() or XMLHttpRequest call to a domain you or an integration partner control.
• Nothing downstream already listens for the same event through Shopify’s Admin API. If an ORDERS_CREATE or ORDERS_PAID webhook subscription already exists and does the same job, the page script is redundant, not load-bearing, and this deadline is a non-event.

That third condition is the one worth checking carefully, because it’s the difference between “nothing happens on August 26” and “NetSuite silently stops getting new orders.” Shopify itself is increasingly a system of record for the transactions an ERP needs, which is exactly why so many non-Plus merchants ended up wiring a page script to their NetSuite sync in the first place — it was the fastest thing that worked at the time, long before anyone thought about what happens when Shopify retires the page it runs on.

The failure mode the marketing-pixel guides skip

Every top-ranking piece on this deadline — agency blogs, Shopify’s own help docs, the community threads — frames it as a marketing-tracking problem. That’s the majority case: a Meta Pixel or GTM container pasted into Additional Scripts, replaced with an app pixel, done. It’s also the case Shopify built a formal migration path for, categorizing installed apps into “tracking and analytics” and “page customizations” inside the upgrade guide itself.

What that migration path assumes is that the code in Additional Scripts is trying to observe the order, not act on it. A script that fires a fetch() call to a NetSuite middleware endpoint, a custom sync service, or any integration platform isn’t tracking anything — it’s the entire data path for getting that order out of Shopify. Swapping it for a Web Pixels API event doesn’t fix that, and Shopify’s own documentation explains why: post-upgrade, “Personal Identifiable Information (PII) isn’t accessible through your additional scripts, checkout.liquid, or checkout_completed pixel events.” The sanctioned pixel replacement is built to keep customer and order data out, by design. A backend integration built on the wrong replacement doesn’t fail loudly — it just never gets the fields it needed.

And when the old script goes, nothing in Shopify’s system notices. Payment still captures. The order still completes. Shopify’s own confirmation flow has no dependency on whatever that script was doing, because it never tracked that script’s success in the first place — there was no webhook subscription to fail, no retry to exhaust, no alert to fire. The sync just stops, on whatever date the auto-upgrade lands, with nothing in any dashboard to say so.

Pre-migration audit: find out if you’re exposed

Run this before touching any code. It takes under an hour on most stores and answers the only question that matters: does this deadline require a migration project, or nothing at all.

• Open Settings → Checkout → Configurations → the upgrade notice, and read every line currently in the Additional Scripts field — it’s read-only, but still fully visible.
• Flag any call to fetch(), XMLHttpRequest, navigator.sendBeacon, or an <img> pixel pointed at a domain that isn’t a recognized ad or analytics platform.
• For each flagged call, identify the destination: your own domain, an integration platform, or a middleware service is a backend dependency, not a tracking pixel.
• Query the Admin API for existing webhook subscriptions and check whether an ORDERS_CREATE or ORDERS_PAID topic is already registered independent of the page script.
• Cross-check NetSuite: does every Shopify order today produce a matching sales order or custom record, and through what mechanism.
• Click into Review customizations on the upgrade notice — Shopify’s own Apps section shows which installed apps are already flagged compatible, narrowing what’s left to check by hand.
• Separate app-owned scripts, which the app developer migrates, from scripts an agency or an in-house developer pasted in directly — those are the store’s responsibility.
• Record today’s order count and NetSuite record count as a baseline, so any gap after the cutover is immediately visible.

Additional Scripts vs. Web Pixels vs. webhook + queue

Three mechanisms, three different jobs. Picking the wrong one is what turns this deadline into an incident.

Verdict: Web Pixels API is the correct, Shopify-sanctioned replacement for tracking — use it for anything that used to fire a pixel. It is not a replacement for anything that used to write data to a system of record. If Additional Scripts was doing that job, a webhook subscription is the only option that gets full order data back.

Step 1: Read what the script actually does

Before writing any replacement code, get the exact payload the old script sent and the exact endpoint it hit. Most of these scripts were written once, years ago, and never documented — the person who wrote it may not still be at the company. Pull the literal source from the read-only Additional Scripts field, trace every network call, and list the fields it reads from Shopify’s checkout Liquid objects (order number, line items, customer email, shipping address, whatever it was pulling).

This step also decides scope. A script that only fires a marketing pixel needs an app-pixel swap, covered above, and nothing in the rest of this runbook applies. A script that writes to NetSuite, a middleware layer, or any system of record needs the full webhook migration below. Don’t guess — a script can do both, firing a tracking pixel and a backend call from the same block.

Verify: you should be able to state, in one sentence, what data leaves Shopify through this script and where it lands. If you can’t, the audit isn’t done yet.

Step 2: Register the webhook subscription

Register the subscription through the Admin GraphQL API, pinned to an explicit version — shopify.dev’s mutation reference is current as of API version 2026-07. Match the topic to what step 1 found: ORDERS_CREATE for a script that fired on order placement, ORDERS_PAID if it specifically needed payment confirmation.

mutation RegisterOrderWebhook(
  $topic: WebhookSubscriptionTopic!
  $webhookSubscription: WebhookSubscriptionInput!
) {
  webhookSubscriptionCreate(topic: $topic, webhookSubscription: $webhookSubscription) {
    webhookSubscription {
      id
      topic
      uri
    }
    userErrors {
      field
      message
    }
  }
}
# POST to /admin/api/2026-07/graphql.json — pin the version explicitly;
# an expired or missing version falls forward silently instead of erroring.

Verify: check the mutation’s userErrors array is empty, then confirm the subscription exists with a webhookSubscriptions query before writing a single line of handler code. A subscription pointed at an endpoint that doesn’t exist yet still registers successfully — it just fails delivery silently, the exact failure mode this migration exists to eliminate.

Step 3: Build the ack-fast, HMAC-verified handler

Shopify gives the endpoint a one-second connection timeout and a five-second timeout for the entire request. Verify the signature before parsing anything, acknowledge inside that budget, and hand the payload to a queue — never call NetSuite in the same request that Shopify is waiting on.

const crypto = require('crypto');

// Raw body, read before any JSON parsing — the HMAC covers the exact
// bytes Shopify sent, not a re-serialized object.
app.post('/webhooks/shopify/orders-create',
  express.raw({ type: 'application/json' }),
  (req, res) => {
    const hmac = req.get('X-Shopify-Hmac-Sha256') || '';
    const digest = crypto
      .createHmac('sha256', process.env.SHOPIFY_APP_SECRET)
      .update(req.body)
      .digest('base64');

    const digestBuf = Buffer.from(digest);
    const hmacBuf = Buffer.from(hmac);
    const valid = digestBuf.length === hmacBuf.length
      && crypto.timingSafeEqual(digestBuf, hmacBuf);

    if (!valid) return res.status(401).end();

    // Ack inside the 5-second budget, then process off the request path.
    res.status(200).end();
    enqueue({
      webhookId: req.get('X-Shopify-Webhook-Id'),
      triggeredAt: req.get('X-Shopify-Triggered-At'),
      topic: req.get('X-Shopify-Topic'),
      payload: JSON.parse(req.body),
    });
  });

Verify: trigger a test event (the Shopify CLI’s webhook trigger command, or a real test order in a dev store), confirm a 200 response inside the 5-second window in your own logs, and confirm the queued job shows up before checking anything on the NetSuite side.

Step 4: Add dedupe, ordering, and a reconciliation job

Three properties the old page script never had, and the ones that actually make this migration safer than what it’s replacing, not just compliant with the deadline. Shopify is explicit that delivery is at-least-once, not exactly-once, and that “Shopify doesn’t guarantee ordering within a topic, or across different topics for the same resource.”

Dedupe against a persistent store keyed on X-Shopify-Webhook-Id — duplicates are routine, not an edge case. Order writes by the X-Shopify-Triggered-At header or the payload’s own timestamp, never by arrival time; this matters most around refund and fulfillment events for the same order landing out of sequence. And run a reconciliation job independent of the webhook path entirely — a scheduled bulk query that diffs Shopify order counts against NetSuite records, the same discipline already covered for webhook-based order sync in wholesale architectures. The old script had no equivalent safety net — if it silently failed to fire, nothing caught it either. The difference now is that a reconciliation job catches a gap within a day instead of a quarter.

Verify: intentionally send a duplicate test event and confirm exactly one NetSuite record results; intentionally send two events out of order and confirm the later timestamp wins, not the later arrival.

Step 5: Trigger your own cutover

Once the webhook path is verified end to end, don’t wait for August 26 to find out what time the automatic upgrade runs. Shopify’s non-Plus upgrade guide documents a self-service path: from the admin, go to Settings → Checkout → Configurations, open the upgrade notice, and click through to Upgrade once Review customizations shows nothing outstanding. That replaces the Thank You and Order status pages immediately, on a schedule you control, rather than on whatever moment Shopify’s automatic process picks.

Run the cutover on a low-order-volume window, with the team that owns the NetSuite sync watching the reconciliation job in real time for the first few hours. There’s no staging environment for this specific switch — the upgrade applies to the live store — so the verification from steps 2 through 4 is what stands in for a dry run.

Verify: place one real order immediately after the manual upgrade, confirm the webhook fires, confirm the NetSuite record appears, and confirm the new Thank You page itself renders correctly for the customer.

Rollback plan

Be precise about what can and can’t be rolled back. Shopify’s cutover to the new Thank You and Order status pages is not reversible through any documented self-service path — there is no “revert to checkout.liquid” button, on your schedule or Shopify’s. The rollback plan that matters is for the sync mechanism you built, not for Shopify’s own deprecation.

If the webhook handler misbehaves after cutover — malformed payloads, an unexpected topic shape, a downstream NetSuite error — disable the handler’s write path but leave the webhook subscription and queue running; nothing is lost, because the queue is durable and events keep accumulating for reprocessing once the bug is fixed. For the gap while that’s happening, the reconciliation job from step 4 becomes the interim sync: run it manually, on demand, to backfill orders NetSuite is missing, the same way a scheduled sync would carry the whole load in a store that never used webhooks at all.

What doesn’t work as a rollback: reverting to the old page script. It’s gone, on non-Plus stores, the moment the cutover — manual or automatic — completes.

Post-migration monitoring checklist

• Confirm the webhook subscription is still active weekly — 8 consecutive delivery failures auto-deletes it with no notification, the single most common way this exact setup goes dark again.
• Run the reconciliation diff on a fixed schedule (hourly for orders is a reasonable default) and alert on any non-zero gap, not just a rising trend.
• Watch endpoint response time against the 5-second budget — a handler that starts responding slowly risks being counted as a delivery failure before anyone notices.
• Check the dedupe store’s hit rate; a sudden drop to zero duplicates usually means the X-Shopify-Webhook-Id matching broke, not that Shopify stopped sending them.
• Audit refund and fulfillment events specifically for ordering bugs — they’re the pair most likely to arrive out of sequence.
• Confirm no app reinstall or theme edit references the old Additional Scripts field expecting it to still execute.
• Log and alert on any X-Shopify-API-Deprecated-Reason response header, so the next API version deprecation doesn’t produce a second silent gap.

None of this is unique to a deadline migration — it’s the same operating discipline any webhook-based NetSuite sync needs permanently. The deadline just forces the store that was running without it to build it now, instead of after the first unexplained gap in NetSuite.

If a page script is the only thing standing between Shopify and NetSuite today, this deadline is a forcing function, not just a cleanup task — an e-commerce sync audit is built exactly to find every point where a store’s order flow depends on something this fragile, and to specify the webhook-based replacement before Shopify makes that decision on its own schedule. More on building that sync correctly the first time is in the Shopify + NetSuite integration guide library.

Frequently asked questions

Related guides

• Shopify to NetSuite: 7 Sync Pitfalls Most Teams Hit in Month Two
• Real-Time vs Scheduled NetSuite to Shopify Sync: Why Cadence Is Not What Causes Oversells
• Shopify B2B and NetSuite: Integration Architecture for Wholesale in 2026