Shelly Store UK, an independent reseller of smart home equipment, has warned customers that their payment details may have been compromised after its payment provider, Stripe, flagged unauthorised software running on its website. In an email to customers, the company said “unauthorized software” had been found on its website and server. It said it has removed the malicious software, strengthened access security, applied security updates, introduced ongoing monitoring and reported the incident to the Information Commissioner’s Office (ICO).
The company says it cannot determine whether customer data was accessed or copied. It is contacting everyone who placed an order during a window it has not specified. The data potentially affected includes payment card details, names, billing addresses and contact details. Its investigation is continuing.
For one customer, the warning arrived too late. They told The Register that, hours before the breach notification email landed, they had already started a payment dispute with their card provider over a fraudulent £221.28 transaction made in Australia using their card details, dated 26 October 2026. They believe their full card details were most likely stolen between 12 October, when they placed their first and only order with the company, and 27 October, when the notification arrived — a window of roughly two weeks.
The pattern matches what security researchers call web skimming, or “Magecart–style” attacks: malicious code injected into a website’s checkout process that captures card details as customers type them. It is a threat that falls disproportionately on small online retailers, because those businesses rarely have anyone watching the code that runs in their customers’ browsers.
What Shelly Store UK has said
Shelly Store UK describes itself as an independent, authorised reseller of Shelly smart home products. It is not part of the main Shelly Group, a point the manufacturer was quick to make. In a statement, Shelly said: “Shelly Store is a reseller of Shelly and is not part of, owned by, or directly affiliated with Shelly Group. We do not manage the Shelly Store website, its business operations, and we do not direct our customers from any of our websites to Shelly Store UK.”
According to the reseller’s email, the problem came to light after a warning from Stripe. The business then took a series of remedial steps:
- removed the malicious software from its website and server;
- strengthened access security;
- applied security updates;
- introduced ongoing monitoring;
- reported the incident to the ICO.
It has advised customers to contact their card issuer about a replacement card and to check their transaction history for anything suspicious. Those are sensible steps, and they match standard guidance after a suspected card compromise. The company has not said how the software got onto its server, how long it was there or how many customers placed orders during the affected period.
That uncertainty is common in incidents of this kind. Small businesses often have limited logging on their web servers, and the evidence needed to say exactly what was taken, and when, may simply not exist. Saying “we cannot determine whether data was accessed” is honest, but it leaves customers to assume the worst — which is what they should do.
Web skimming code runs in the customer’s browser, inside the checkout page your website serves. Standard antivirus on office PCs and the firewall on your network do not inspect front–end website code, which is why skimmers often run undetected for weeks. In this case, it was the payment provider that raised the alarm, not the retailer’s own tools. If you run an online shop, ask yourself honestly: would you notice if an extra script appeared on your checkout page tonight?
How the timeline unfolded
The sequence below is based on what Shelly Store UK and one affected customer have said. Where the reporting gives no date, the step is marked accordingly.
The timeline shows the gap that makes web skimming so damaging. By the time a small business learns its checkout has been compromised, card details may already have been sold and used. In this case, the fraud landed before the warning did.
What web skimming is, in plain terms
When a customer visits an online shop, their browser downloads the shop’s pages along with a collection of scripts — small programs that power menus, basket updates, analytics, chat widgets and, crucially, the checkout. A web skimming attack adds one more script to that collection. It sits quietly on the payment page, copies whatever the customer types into the card fields and sends a copy to a server controlled by the attacker. The genuine payment still goes through, the customer receives their order and nothing appears to be wrong.
That is what makes these attacks so effective. The shop keeps trading normally, the payment provider keeps processing payments and the customer has no reason to suspect anything until fraudulent transactions appear on their statement. The term “Magecart” is often used for this whole family of attacks, after the groups that made them notorious.
Skimming code reaches a website in a handful of familiar ways. Attackers may exploit an unpatched flaw in the shop software or one of its plugins, log in with stolen or weak administrator credentials, compromise a third–party script the site loads, or gain access to the hosting server itself. Shelly Store UK’s description — unauthorised software on its website and server, followed by strengthened access security and security updates — is consistent with more than one of these routes, and the company has not said which applied.
Why small online stores are hit hardest
Large retailers are not immune to web skimming, but they usually have security teams, change controls on their checkout code and tools that watch for unexpected scripts. A small online store typically has none of these. Its website may have been built by a freelancer years ago, run on a shared hosting account and rely on a dozen plugins that are updated whenever someone remembers.
Several factors combine to make small stores attractive targets:
- Unpatched software. E–commerce platforms and their plugins publish security updates regularly. A store that falls behind is easy to find and easy to compromise.
- Shared or weak admin accounts. A single administrator login, reused by several people and without multi–factor authentication, is a common way in.
- No monitoring of front–end code. Changes to the scripts on a checkout page go unnoticed because nobody is looking for them.
- Card fields on the store’s own page. Where customers type card details into fields that the store’s page controls, a malicious script on that page can read them.
- Limited logs. When something does go wrong, there may be too little evidence to say exactly what happened, as Shelly Store UK’s statement illustrates.
None of this requires a sophisticated attacker. Many skimming campaigns are automated, scanning large numbers of sites for known weaknesses and planting code wherever they succeed. A small shop is not targeted because of who it is; it is compromised because it was reachable and vulnerable.
Which controls make the biggest difference
The chart below is our indicative assessment — not measured data — of how much each control reduces the risk of a small online store suffering a web skimming incident.
The top bar deserves particular attention. Payment providers including Stripe offer hosted checkout pages and secure card fields that keep card entry under the provider’s control rather than the shop’s. That does not make a store immune — an attacker who controls the site can still try to redirect customers or tamper with the page around the payment step — but it removes the easiest route to reading card numbers as they are typed. The reporting does not say how Shelly Store UK’s checkout was configured, so we draw no conclusion about its set–up.
The bottom bar is a reminder of where many small businesses put their security effort. Antivirus on office computers is worthwhile, but it plays almost no part in protecting a website’s checkout from injected code.
A readiness score card for small online stores
The score card below rates common positions for UK businesses that take card payments on their own websites. It is a judgement framework to support conversations with your web developer or IT partner, not an audit result.
Backups appear in the middle of the card for a reason. After a compromise, a business needs to know what its website looked like before the attacker arrived. Restoring a clean copy is often faster and safer than trying to pick malicious code out of a live site — but only if backups exist, are kept for long enough to predate the compromise, and have been tested.
What prevention costs compared with a breach
The figures below are indicative ranges for a smaller UK online store. They are planning estimates rather than quotations, and they will vary with the platform, the number of plugins and how the site is hosted.
| Measure | Indicative one–off cost | Indicative ongoing cost | What it addresses |
|---|---|---|---|
| Move card entry to the provider’s hosted page or secure fields | £500–£3,000 | Usually none beyond existing provider fees | Keeps card numbers out of fields the shop’s own page controls |
| Security review of the shop platform, plugins and hosting | £750–£3,500 | Repeated annually | Finds outdated components, unused plugins and weak configuration |
| Managed updates and website maintenance | None | £50–£300 per month | Closes known vulnerabilities before automated scanners find them |
| Multi–factor authentication and individual admin accounts | £0–£500 to set up | Minimal | Stops stolen or shared passwords opening the admin panel |
| Script change monitoring for checkout pages | £250–£1,500 to configure | £20–£200 per month | Alerts when new or altered code appears on payment pages |
| Off–site website and database backups | £100–£750 to set up | £10–£80 per month | Allows a clean restore to a known–good state |
| Cyber Essentials certification | A few hundred pounds upward, depending on organisation size | Annual renewal | Baseline controls on the devices and accounts that manage the store |
Against those costs sit the consequences of a skimming incident: forensic investigation, emergency rebuilding of the website, possible requirements from the payment provider, staff time handling customer queries, a report to the ICO and, hardest to price, the loss of customers who no longer trust the shop with their card. For a small reseller whose reputation rests on being a safe place to buy, that last cost can be the largest.
Card fields on your page versus the provider’s
Card form on the shop’s own page
Common on older or heavily customised stores
Provider’s hosted page or secure fields
Recommended for most small stores
Neither column is a guarantee. The right–hand approach reduces risk sharply, but a store that is otherwise neglected remains a target. The point is to remove the softest target first and then build sensible controls around it.
How ready are small UK online stores?
The gauge below is our indicative estimate of how well a typical small UK online store is protected against web skimming. It is a judgement based on the patterns in the score card, not a survey figure.
A score of 24 reflects how many small stores are run: the website was launched, it works, and nobody has the time or expertise to look under the bonnet. Updates are applied occasionally, admin access is shared, and nobody monitors the checkout page. The good news is that the steps that make the biggest difference are neither exotic nor expensive.
In this case, Stripe spotted the problem first. If your payment provider, bank or card scheme contacts you about suspicious activity on your website, act the same day: put the checkout into maintenance mode if needed, bring in someone who can examine the site and server, change every admin and hosting password with multi–factor authentication enabled, and preserve logs before anything is rebuilt. Make sure provider alerts go to an inbox someone actually reads — not an old address belonging to the developer who built the site.
What customers of any affected store should do
Shelly Store UK’s advice to its customers is good general guidance for anyone who receives a similar notification:
- contact your card issuer and ask about a replacement card;
- check your transaction history for anything you do not recognise, including small payments that may be tests;
- be wary of follow–up emails, calls or texts that refer to the breach and ask for details, as criminals often exploit the confusion;
- keep the notification email, as it may help if you need to dispute a payment.
The affected customer’s experience shows why speed matters. Their card was used fraudulently in Australia before they heard from the store. Card providers are generally well placed to handle disputes of this kind, but the sooner a compromised card is replaced, the smaller the window for misuse.
Analysis: the lesson is about who is watching
The most striking detail in this incident is who spotted it. It was not the retailer, its hosting company or its own security tools. It was Stripe. That is not a criticism of a small business that has, by its own account, responded and reported. It is an accurate picture of how many small online stores operate: the security of the checkout is assumed rather than watched.
Web skimming exploits that assumption. Because the attack lives in front–end website code, it slips past the tools most small businesses rely on. Because the genuine payment still succeeds, there are no failed orders or angry customers to raise suspicion until the fraud starts. And because many small sites keep limited logs, even after discovery it may be impossible to say who was affected, which is why Shelly Store UK is contacting all customers who ordered during the window.
There is also a reputational wrinkle that small resellers should note. The manufacturer moved quickly to make clear that the store is independent and that it does not direct customers there. Customers often assume an authorised reseller is closely connected to the brand it sells. When something goes wrong, the brand may protect itself publicly, and the reseller is left to manage the fallout alone. Our coverage of ASOS’s breach notification and the wave of attacks on UK retailers shows that larger businesses face the same pressures, with far more resources to absorb them.
The regulatory side matters too. Reporting to the ICO is the right step when personal data may have been compromised, and UK GDPR expects organisations to have appropriate security in place for the data they handle. Our report on the Supreme Court ruling on the data protection threshold explores how claims and expectations around personal data are evolving. A small online store holding card details, names and addresses is handling exactly the kind of data regulators expect to see protected.
At a glance
| Item | Detail |
|---|---|
| Business affected | Shelly Store UK, an independent, authorised reseller of Shelly smart home products |
| Relationship to Shelly Group | Not part of, owned by or directly affiliated with the manufacturer, according to Shelly |
| How it was found | Payment provider Stripe flagged unauthorised software on the website |
| Where the software was found | On the store’s website and server |
| Data potentially affected | Payment card details, names, billing addresses and contact details |
| Was data taken? | The store says it cannot determine whether data was accessed or copied |
| Who is being contacted | All customers who placed orders during an unspecified window |
| Reported fraud | One customer reported a £221.28 fraudulent transaction in Australia, dated 26 October 2026 |
| Store’s response | Removed the software, strengthened access security, applied updates, added monitoring, reported to the ICO |
| Advice to customers | Contact the card issuer about a replacement card and check transaction history |
| Attack pattern | Consistent with web skimming, also called Magecart–style attacks |
For related coverage, see our reports on ASOS and the Snowflake breach notification, the cyberattack wave hitting UK retailers, the critical PHP remote code execution flaw, offline card payments and business continuity and the Supreme Court’s data protection threshold ruling.
Is your online shop’s checkout being watched?
We build and maintain secure e–commerce websites for UK businesses, with card entry handled by your payment provider, platforms and plugins kept up to date, admin access locked down and monitoring on the pages that matter most.
Talk to us about Web DevelopmentFrequently asked questions
Get a security review of your e–commerce site
We review UK online stores for outdated plugins, risky checkout set–ups, shared admin access and missing backups, then fix what we find — so your payment provider is never the first to tell you something is wrong.
Talk to us about Web DevelopmentShelly Store UK’s investigation is still running, and it may never be able to say exactly what was taken. The lesson for every small online retailer is clearer: if nobody is watching your checkout, the first sign of trouble may be a customer’s card being used on the other side of the world.













