Upgrading to Shopify's New Checkout: 3 Bugs That Cost Me 20% of Orders
After the forced migration to Checkout Extensibility, three silent bugs slipped through testing and cost me nearly $2,000 in lost orders. Here's exactly what broke, how I found each one, and the monitoring setup I built to prevent repeats.
Shopify gave us a deadline. August 26 for Scripts. August 28 for checkout. I marked my calendar, read the docs, migrated my pixels to Web Pixels, removed the old checkout.liquid customizations, and tested everything in incognito mode. Orders went through. Tracking fired. I called it done.
Three days later, I noticed my conversion rate was down 20% week-over-week. Revenue looked normal at first glance — but that was because returning customers were still buying. New customer checkout completions had cratered.
Here are the three bugs that caused it, how I found them, and what I wish I'd done differently.
Bug #1: Checkout UI Extension Rendering Race Condition
I had two checkout extensions installed: one from a shipping date picker and one from a loyalty points app. Individually, each worked fine during testing. Together, they created a race condition.
The symptom: On mobile, the checkout page would load the shipping method step normally. But when a customer tapped "Continue to payment," nothing happened. The button was there. It wasn't disabled. It just didn't respond to taps. On desktop, it worked fine — which is why my incognito-mode-on-a-laptop testing missed it entirely.
How I found it: A customer emailed saying "your checkout is broken on my phone." I grabbed my personal phone (not my dev phone, which has a different screen size and touch behavior) and reproduced it on the first try. Safari on iOS 18. The payment step simply wouldn't advance.
Root cause: Both extensions were binding to the same checkout step's onSubmit callback. The shipping date picker ran first and updated the shipping method. The loyalty points app ran second and tried to recalculate the cart total. When both callbacks resolved in the wrong order — which only happened on slower mobile connections — the checkout step's internal state got stuck. The button's click handler was attached, but the underlying checkout session had already moved past the "awaiting payment step" state without actually advancing to it.
The fix: I disabled the loyalty points extension temporarily, confirmed checkout worked, then reached out to the app developer with a reproducible test case. They patched it within 48 hours by adding a guard clause to check whether the shipping step was actually complete before attempting recalculation. Total time from discovery to fix: 4 days. Estimated lost orders: 30-40.
Bug #2: Web Pixel Firing But Sending Garbage Data
My Facebook conversion pixel migrated from Additional Scripts to Web Pixels without errors. The pixel showed as "Active" in Events Manager. Test events appeared in the test console. Everything looked green.
The symptom: Facebook's conversion reporting dropped to near zero for 11 days. Not completely zero — a few conversions trickled through — but 90%+ of purchases stopped being attributed. Because some data was still flowing, Facebook's algorithm didn't flag it. Campaign ROAS appeared to plummet. I paused two campaigns thinking the creative was dead, wasting $400 in paused ad spend that would have converted if tracking worked.
How I found it: I compared Shopify's actual order count for a 3-day period against Facebook's reported purchases. Shopify said 47 orders from paid social traffic (based on UTM parameters). Facebook said 4. That 10x discrepancy is what tipped me off.
Root cause: The Web Pixel was firing on the checkout_completed event, but the event payload format had changed. My old Additional Scripts code expected checkout.total_price in cents. The new Web Pixels event uses checkout.total_price.amount in decimal format. My pixel was sending undefined as the purchase value. Facebook was receiving the event but discarding it because the value field was invalid. Standard events require a valid value parameter — without it, the conversion isn't counted for optimization, only for reach.
The fix: Updated the pixel code to use the new event payload schema. Took 10 minutes once I found it. Also added a server-side conversion API (CAPI) call as a backup — if the browser pixel fails for any reason, the server-side event ensures attribution isn't lost.
Bug #3: Mobile Checkout CSS Broke After Theme Update
This one wasn't directly caused by Checkout Extensibility — it was a theme update I installed the same weekend. But because I attributed everything to "the checkout migration," I spent 2 days looking in the wrong place.
The symptom: On mobile devices, the checkout page's payment form extended below the visible viewport, but the "Place Order" button was hidden behind the fixed bottom checkout summary bar. Customers could fill in their payment details but couldn't actually complete the purchase because the button was visually obstructed.
How I found it: Session recordings. I use a tool that records anonymized user sessions (highly recommend this — without it, I'd still be guessing). I watched 8 recordings where users filled in their payment details, scrolled around confused, and abandoned. The button was literally hidden by a 60px overlay.
Root cause: The theme update changed the checkout container's padding-bottom from 80px to 40px. This was documented in the theme changelog as "improved checkout spacing" — but the change didn't account for the fixed checkout summary bar on mobile. The old 80px padding created enough breathing room. The new 40px padding let the button get swallowed by the summary bar.
The fix: Added padding-bottom: 100px to the checkout container via the theme customizer's custom CSS field. One line of CSS. Two days of lost orders because I didn't test on an actual phone after the theme update.
What I Changed After This
Three bugs. Two weeks of degraded checkout. Roughly $1,800 in lost orders based on my conversion rate and traffic during that period. Here's the monitoring system I built afterward:
- Daily checkout test: Every morning, I place a $1 test order on mobile (real phone, cellular data) and desktop. I verify the order appears in Shopify, the pixel fires in Facebook/Google, and the confirmation email arrives. Takes 3 minutes.
- UTM conversion audit (weekly): Every Sunday, I compare Shopify's order count for each UTM source against the ad platform's reported conversions. A discrepancy >15% triggers an immediate pixel audit.
- Session recording review (weekly): I watch 10 random checkout sessions per week. Not looking for anything specific — just watching how real users interact with the checkout. I catch more bugs in 20 minutes of watching recordings than in hours of manual testing.
- App update changelog monitoring: I added a calendar reminder to check every installed checkout-affecting app for updates every Monday. If an app updated, I test checkout immediately.
The total setup time for this system was about 2 hours. It's already caught one additional issue — a payment gateway timeout that only affected orders over $200 — before it impacted more than a handful of customers.
Loading comments...