Shopify Checkout Attack: What Happened and What to Do

Since October 10, 2026 some Shopify stores have shown customers a fake checkout. On clicking "Pay", the customer landed on a page identical to the real one that copied the card details and then sent them on to the genuine checkout: the order went through and nobody noticed anything. According to the vendors involved, the code was loaded through third-party apps installed in the stores. It is a lesson for anyone selling online, whatever the platform.

What happened

This account is based on information found on the web as of October 19, which cites the developer who found it and the vendors' statements:

October 10: developer Roman Zipp notices the fake page while buying from a Shopify store and reports it.
October 10 to 18: HulkApps, Selleasy and Swym confirm that an unauthorized party changed what their apps loaded on some stores.
October 18: Swym disables its app for all merchants after new unauthorized activity.

Nobody has yet published how the attackers got in, or how many stores and cards are involved.

How it worked

According to the reconstructions, the code acted on the click on "Pay", on the store pages that come before checkout. The malicious code waited for the click, sent the customer to a fake site with a different address, collected the card details and sent them on to the real checkout. Because the customer paid anyway, whoever ran the store saw nothing in the orders. The payment security standard (PCI) calls this technique double-entry skimming.

It is not just one platform's problem

Every app or script running on your store's pages is code that someone outside your company can change. It happens on any platform, Magento included: we covered it with StyleSmuggler and the October patch. The difference lies in who controls what.

Why control matters: Magento, Mage-OS and Adobe Commerce with Hyvä

On an open platform such as Magento, Mage-OS or Adobe Commerce, you, with your developer, decide which scripts may run and check it. In practice:

Script policy (CSP). A CSP tells the browser which scripts it may run and blocks the rest. According to Adobe Commerce documentation, from version 2.4.7 it is active in restrictive mode on payment pages.
Hyvä Checkout. According to the official documentation, from version 1.3 it applies a strict CSP on all checkout pages: every script needs an authorization, and no code can be injected dynamically. Hyvä states that this meets PCI DSS 4.0 requirements.
PCI DSS 4.0. For payment pages it requires keeping an inventory of scripts and detecting changes (requirements 6.4.3 and 11.6.1, in force since March 31, 2025). We cover it in PCI DSS 4.0 for e-commerce.

A word of caution: no platform or theme makes you compliant on its own. Third-party modules, marketing scripts and updates have to be checked over time, and Magento has its own vulnerabilities: maintenance is needed. More control also means more responsibility.

If you have a Shopify store

Run a checkout test in a private window, from the product to payment, and watch whether the address changes.
List the apps that load code on your pages and remove the ones you do not need.
Read the vendors' notices for the named apps (HulkApps, Selleasy, Swym).
Do not rely on orders alone: the customer paid anyway. Watch for reports of strange pages or card fraud after purchase, and tell your payment provider.

A checkout under control

If you want to understand how exposed your checkout is, or evaluate Magento, Mage-OS or Adobe Commerce with Hyvä Checkout, I can help with a risk review and with choosing the platform. See B2C e-commerce development and replatforming and migrations; to keep it under control over time there is the maintenance and support service.

Want to know whether your checkout is protected? Request a security audit and a free quote.

Informative article: the facts come from public reports as of October 19, 2026, and the situation is evolving. It is not PCI compliance advice: how your store is classified should be checked with your payment provider.