The Shopify checkout hijack and how to check your store

Last updated 20 October 2026. Still developing.

Shoppers on working Shopify stores have been clicking the checkout button and landing on a fake payment page that asks for their card. The store stays online, nothing errors, and uptime monitoring says all clear.

Most of what anyone knows about this comes from developer Roman Zipp. On 10 October his password manager offered to fill in his card on a checkout page at biliing[.]top. He traced the code to an app and reported it to the merchant, HulkApps, Shopify and Germany's national CERT. Shopify removed it from that store the same afternoon. He has kept his investigation updated since. It's careful work and worth reading in full.

What happened

The code came in through apps. In the case Zipp traced, an app's storefront script fetched its settings from the developer's servers, the settings came back with extra JavaScript, and the script ran it. That code hooked the checkout button and sent the shopper to the fake page.

Then it hid. After the first redirect it set a marker in the browser's sessionStorage and stayed quiet for the rest of the session. A merchant who tests twice in the same tab sees a normal checkout.

The apps named in public reports are HulkApps (Hulk Product Options) and Selleasy. Swym Wishlist Plus and Privy have each come up in a single unconfirmed report. In comments on Zipp's post, both said unauthorised code was added through their apps, and HulkApps says an independent firm is investigating. How it got there hasn't been established, and none of this means an app is malicious or that every store using one was affected.

Reported phishing domains include biliing[.]top, checkout-confirm[.]top and order-confirm[.]top. Treat them as examples, not a blocklist.

A Plus merchant came to us with something very similar

On 14 October a Shopify Plus merchant got in touch after a very similar redirect. Their team spotted the wrong checkout address and uninstalled the responsible app within minutes. We can't say it was the same campaign.

They asked us to catch it automatically. I'll be straight: our first version reached checkout through a cart link. It would have missed this attack completely, because the code sat on the checkout button and a cart link never touches it. You have to do what a shopper does: product, cart, checkout button. The other lesson: decide where checkout may go and fail on anything else, rather than chase bad domains.

How to check your store

1. Open a new private or incognito window.
2. Go to a product, add it to the cart and click your real checkout button. Don't paste a checkout link.
3. Read the address bar. It should show your own domain or Shopify's checkout.
4. Repeat in a fresh window on desktop and phone, including the cart drawer and any buy-now buttons.
5. Remove apps you don't use, and check app custom JavaScript settings for code you didn't add.
6. If checkout lands anywhere unexpected, note the address and time and contact Shopify Support.

Or let our free scan do it for you.

What Revenue Shield does

Revenue Shield runs the purchase journey on a schedule, on desktop and mobile, in a fresh real browser every time, so a once-per-session trick can't hide. Where we can, that means clicking your real checkout button; on stores whose bot protection blocks automated browsers, the check may start from the cart. If the shopper doesn't end up on your store's Shopify checkout, the check fails and your team gets an alert by email, Slack or SMS, with a video of the run.

Nothing goes on your theme. The app only asks for read access to products and adds no storefront scripts, which matters when this attack came in through one.

Since 20 October every check also records where checkout landed and shows the address next to the run.

This is monitoring, not protection. It doesn't block anything, and a targeted or cloaked attack can slip past a scheduled run. What it does is shorten the time between your checkout going wrong and you knowing.

Updates

• 20 Oct 2026: 135 apps have now left the App Store, including Privy, Rebuy, Boost and Consentmo. Most aren't linked to this attack, and delisting doesn't remove an app from stores that have it. What it means, and the full list.
• 19 Oct 2026: Zipp adds Privy after a commenter named it. He's trying to confirm it and notes the app is de-listed from the App Store.
• 16 Oct 2026: In comments on Zipp's post, Selleasy's co-founder says the script reached some stores on 13 October and was removed that day, and Qikify says its July incident was separate.
• 15 Oct 2026: Seven merchants have contacted Zipp, and DNS for biliing[.]top has been removed.