Your Checkout Runs Code You Didn’t Write

A customer emails on Tuesday morning. She bought a lamp from your store yesterday, her card was charged, and she never got a confirmation. You check the orders. Nothing under her name. You place a test order yourself, from start to finish. It goes through perfectly.

Everything on your side looks fine. Her money still went somewhere.

This is what a Shopify checkout hijack can look like from the inside, and several confirmed incidents this autumn followed exactly this pattern. If you run a Shopify store with a handful of apps installed, this guide explains what happened, how the attack works, why your test order may not catch it, and what to check today.

What happened with Shopify apps this autumn

Between July and October 2026, several app developers published notices confirming that attackers had used their apps to send shoppers to fake payment pages:

• Orichi OC Quantity Breaks (September 11): malicious JavaScript in campaign custom code intercepted shoppers before the real checkout and sent them to a fraudulent page.
• Hulk Product Options (October 10): unauthorized configuration changes in the app’s theme extension redirected some checkouts to a fake external page. Shopify temporarily disabled the extension.
• Selleasy (October 13): an attacker gained access to an internal Selleasy tool and used it to add a malicious script to store settings. The developer says it was removed from all stores the same day.
• Swym Wishlist Plus (October 14): an unauthorized configuration change loaded a script on a limited subset of stores for about two hours. Swym says it removed the code and rotated credentials.

Each developer says the investigation is ongoing or that an independent review is underway. Shopify has not published a statement on the cause or on how many stores were affected. Other apps have been mentioned online without confirmation, so we’re only naming cases where the developer itself confirmed the incident.

How the attack works

To see why this is hard to spot, it helps to know how apps get into your storefront.

Many apps add a piece of JavaScript to your store pages. That’s how a wishlist button, an upsell popup or a product options picker appears. The code usually loads from the app developer’s servers, and much of it reads settings the developer controls: a block of custom HTML, a “custom JS” field, a configuration file.

So the attacker doesn’t need to break into your store. In the confirmed cases, they got into something on the app developer’s side: an internal tool, a settings panel, a configuration channel. One change there, and the malicious script appeared in every store using that app at the same time.

The script then does one simple thing. It waits for a shopper to click the checkout button and sends them to a page on another domain that looks like a payment form. The shopper enters card details. The fake page collects them. Shopify’s real checkout is never touched, so no order is created and nothing in your admin raises an alarm.

Two details make it worse:

Not every visit is redirected. Developers reported that only some checkouts were affected, and some browsers blocked the redirect on their own.

The first attempt is the one that counts. In one documented case the script left a marker in the shopper’s session. The first checkout attempt went to the fake page. A second attempt in the same session went to the real checkout. A store owner running a quick test, or a shopper trying again after “an error,” would see a normal checkout.

That’s how the customer in our example ends up charged while your test order looks perfect.

Why your usual protection doesn’t catch it

Most store security is about your admin: a strong password, two-step login, staff permissions. All of that still matters. None of it stops a script that arrives through an app’s own settings, because the break-in happened at the supplier, not at your login screen.

Your orders list doesn’t help either. People who typed their card into a fake form never became orders. If you only count failed or missing orders, you’ll underestimate how many customers were exposed.

This isn’t a problem with one bad app. Any app that loads code into your storefront is part of your checkout’s security, whether you think of it that way or not.

A 30-minute check for your store

You can do most of this yourself.

1. List every app that touches your storefront. Go through your installed apps and your theme’s app embeds. Remove what you no longer use. Shopify’s own guidance notes that some apps leave code in the theme after uninstalling, so check the theme too, or ask whoever maintains it.

2. Look for custom code fields in app settings. Upsell, popup, bundle and announcement apps often have “custom JS” or “custom HTML” fields. If you see code there that nobody on your team added, treat it as urgent.

3. Test checkout the way a first-time shopper would. Use a fresh private window for every attempt, on at least two browsers and a phone. Add a product, click checkout and look at the address bar before the payment step. It should be your store’s checkout, not an unfamiliar domain. Don’t enter real card details on any page you’re unsure about.

4. Watch customer signals. Messages like “I paid but didn’t get a confirmation,” or card charges from a merchant name customers don’t recognize, are the most reliable early warning you have.

5. Ask each app developer one question. “Was my store affected, and in what time window?” Reputable developers will answer this directly.

If you do find a redirect: restrict access to your Online Store right away (switch it to private or password-protected), contact Shopify Support and the app developer, and keep the customer reports with their times. Don’t ask affected customers to enter their details again. Talk to your payment provider or an adviser about whether you need to notify anyone.

Before you turn an app back on

Several affected apps have been fixed and relisted. Reinstalling may be fine, but don’t do it on trust alone. Ask the developer:

• What was the exposure window for my store?
• What exactly was fixed, and were access credentials rotated?
• Was configuration already stored in my store cleaned, or only the code going forward?

Then repeat the private-window checkout test after reinstalling and keep an eye on customer messages for the next couple of weeks.

Why this will keep happening

Attacks like this are getting cheaper to run. In September, Gambit Security described a campaign in which an attacker used AI agents to find and exploit weaknesses in websites with very little human involvement. At least 27 companies were breached between September 10 and 15, more than 600,000 card records were stolen, and the whole operation cost about $8,000, with some targets costing as little as $3.13

The point for store owners is simple: when an attack costs a few dollars per target, attackers can afford to try thousands of stores and every app those stores use.

How we approach a storefront script audit

When we audit a store, the slow part used to be reading through every script the storefront loads, many of them minified and spread across a dozen apps. Now we capture every script loaded on the product, cart and checkout path, give them to an AI model, and ask it to flag anything that listens to checkout buttons, rewrites links or sends data to unexpected domains. A developer then checks each flag by hand.

The other half of the work is reducing how many outside vendors can change code in your store. A small feature that sits close to checkout, like a quantity discount or an upsell block, can often be rebuilt as a custom app you control instead of a third-party app with its own servers and settings panel.

When you don’t need to rebuild anything

You can’t remove all third-party code, and you shouldn’t try. Large, established apps have had incidents too, and a custom app is only safer if someone maintains it. For a store with three or four well-known apps, the 30-minute check above, done once a month, plus attention to customer messages, covers most of the risk.

Custom replacements make sense when an app sits right before checkout, when it has had a confirmed incident, or when you’re paying for a big app to use one small feature.

FAQ

Can a Shopify app redirect my checkout?
Yes. In the confirmed incidents, a script delivered through an app’s settings intercepted the checkout button and sent shoppers to a fake payment page on another domain before they reached Shopify’s checkout.

Does two-step login protect my store from this?
It protects your admin, which still matters. It doesn’t stop a script that arrives through an app developer’s systems, because that break-in happens on the supplier’s side.

How do I know if my store was affected?
Ask each app developer for your store’s exposure window, test checkout in fresh private windows on several devices, and look for customer reports of charges without confirmations. Your orders list alone won’t show it.

Were wallet payments affected?
Swym said wallets such as Shop Pay, PayPal and Google Pay were not affected in the same way in its incident. That’s one developer’s statement about one incident, so test every payment path anyway.

Should I uninstall apps that had an incident?
Not automatically. Ask the developer what was fixed and for your exposure window, then test after reinstalling. Replace the app if the answers are vague or it sits right before checkout.

Start your Shopify checkout hijack check today

The customer in the opening story wouldn’t show up in your orders, your analytics or your test purchase. That’s why this check matters more than it seems. Spend 30 minutes on the five steps, ask your app developers one direct question, and repeat it monthly. A Shopify checkout hijack depends on nobody looking at the code that runs before checkout.

Want a second pair of eyes on what runs in your storefront? Send us your store URL and your list of apps. We’ll check what loads before checkout and tell you what to remove, replace or keep.