Malware
Magecart
Magecart is the name for groups that inject card-stealing JavaScript into online checkouts, first seen on Magento stores. The crews change, the trick stays the same: a few lines of script read the card form before the payment processor does.
How it is measured
You do not measure Magecart as a rate. You confirm it by finding script that does not belong on a payment page: an extra <script src> on /checkout, an inline block that listens for submit or blur on card fields, or a request to a host your payment provider never mentioned. Diff the checkout HTML and its loaded scripts against a known-good copy.
Watch the outbound requests while you type a test card. Legitimate checkout traffic goes to your own origin and to the processor. A POST or an image beacon carrying the card number to a third host is the tell. Content-Security-Policy reports and file-integrity checks on theme and plugin files catch the change; server logs alone usually do not, because the theft happens in the buyer's browser.
Worked example
A candle shop on Magento 2.4 gets a call from its acquirer: eleven customers reported fraud after buying in the last three weeks, all on cards used nowhere else. A review of the checkout page shows a 2 KB script loading from 'g-metrics-cdn.net', a name chosen to look like an analytics vendor, referenced in a CMS footer block no admin remembers editing.
The script waits for the card field to hold sixteen digits, then sends the form values as a base64 string in an image request. Removing the footer block stops the leak, but the shop still has to rotate the admin password used to add it and give the acquirer the dates the script was live.
How it differs
A skimmer is the script itself. Magecart is the family of crews and campaigns behind many of them, and the label usually implies a shop platform or a third-party supplier was the way in. A skimmer found on a one-off brochure site is still a skimmer; calling it Magecart says something about who or how, which you often cannot prove.
Common errors
Assuming a passed PCI scan means the checkout is clean. Scanning only server files when the script sits in a CMS database block or a third-party tag. Testing checkout with a saved card so the card fields never fire. Removing the visible script and leaving the admin account or plugin flaw that let it in. Treating a hosted payment page as immune when the page that embeds it can still be altered.
In practice
This week, list every script that loads on cart and checkout and write down why each one is there. Pin the ones you control with Subresource Integrity, add a CSP that names only the payment domains, and set an alert for changes to checkout templates. If you do find the skimmer, assume admin credentials leaked and rotate them before you clean.