Reviewed November 9, 2026
App Conflicts: Two Apps Fighting Over the Same Checkout Script
When two apps touch the same checkout step, disable one app, test a checkout, and repeat until the symptom disappears. That is the whole diagnostic. The app whose removal fixes the problem is the one conflicting, and the fix is usually a setting in that app, a script order change, or removing one of the two.
The discount applies on one order and not the next. The checkout button works in the morning and does nothing in the afternoon. The shipping option appears, disappears, reappears. The store has not changed. The apps have not been updated. Nothing is reproducible, and that is the signature of a conflict.
Two apps that inject scripts into the same checkout step are sharing a space that was not designed for sharing. Each one assumes it is alone. Each one rewrites the same DOM, hooks the same event, or replaces the same function. The result is a race, and races do not reproduce reliably, which is why the symptoms feel random.
What a script conflict looks like
The symptoms are flaky by nature. A button that works sometimes. A discount that applies on alternate orders. A shipping rate that shows for one customer and not the next. The randomness is the tell: a broken setting fails consistently, and a conflict fails depending on which script loaded first, which is a race that changes with network speed, caching and the order the browser happened to fetch the files.
The usual suspects are the apps that touch checkout: discount apps, upsell apps, shipping apps, checkout customization apps, and anything that adds a field, a banner or a script to the checkout page. Two of them editing the same step is the conflict. Three of them is a guarantee.
The first step is not to read code. It is to list every app that touches checkout, with the date it was installed and the date it was last updated. The conflict usually started with the most recent install or update, and the list narrows the search before a single test is run.
Isolating it without breaking the store
Disable one app, test a checkout, and repeat. That is the whole diagnostic, and it works because it is binary: with the app on, the symptom appears; with it off, it does not. Start with the most recently installed or updated app that touches checkout, because that is the most likely culprit.
Do the test in a staging theme or with test orders, not on live traffic. A test order in Shopify's test mode, or a draft order run through the checkout, reproduces the symptom without charging a real customer. Run the same test three times with the app on and three times with it off, because a race condition can pass once by luck.
When the culprit is found, the fix is usually one of three things. A setting in the app that controls which checkout step it modifies. A script order change, loading one app's script before the other's. Or removing one of the two apps, because two apps doing the same job is not redundancy, it is a conflict waiting for a trigger. The third option is the one merchants resist, and it is the one that fixes the problem permanently.
Preventing the next one
The prevention is a rule, not a tool: one app per checkout job. One discount app, one upsell app, one shipping app. When a second app is proposed for a job that is already covered, the question is not whether it is better. It is whether the job needs two apps, and the answer is almost always no.
New app installs need a checkout test before they go live. Install, run three test checkouts, check the discount, the shipping rates and the payment step, then enable it for real traffic. The test takes ten minutes. The conflict it catches takes a week of support tickets to diagnose after the fact.
Keep a list of which apps touch checkout, with install dates. When a symptom appears, the list is the first thing you check, and it turns a week of guessing into an afternoon of testing. The stores that diagnose conflicts quickly are the stores that wrote the list down before they needed it.
Related reading
For the background behind “App Conflicts: Two Apps Fighting Over the Same Checkout Script”, these earlier guides help: Your Card Was Declined: What the Gateway Code Actually Means, 404s After a Theme Change: Where Shopify Redirects Actually Live, and Checkout Extensibility Broke Your Custom Code: Where the Old Scripts Went.
Frequently asked questions
How do I know if my checkout problem is an app conflict?
If the symptom is flaky, works sometimes and fails other times with no pattern, and no setting changed recently, it is likely a conflict. A broken setting fails consistently. A conflict fails depending on which script loaded first, which changes with network speed and caching.
Which apps most often conflict at checkout?
Discount apps, upsell apps, shipping apps, checkout customization apps, and anything that adds a field, banner or script to the checkout page. Two of them editing the same step is the conflict. Check the most recently installed or updated one first.
Can I test for a conflict without affecting live customers?
Yes. Use Shopify test mode or a draft order run through checkout, and run the same test three times with the suspect app on and three times with it off. A race condition can pass once by luck, so a single test is not enough.
Should I keep two apps that do the same job at checkout?
No. Two apps doing the same job is not redundancy, it is a conflict waiting for a trigger. Keep the one that works better, remove the other, and the class of problem disappears with it.