Carding tool abusing the WooCommerce API downloaded 34K times on PyPI: How to protect your checkout
A PyPI package downloaded 34,000 times automated stolen-card testing against WooCommerce stores. What it did, what would have stopped it, and what to fix first.
By 3 mins readPublished Updated On this page
A carding tool published as an ordinary Python package on PyPI (the Python Package Index) was downloaded more than 34,000 times before it was caught. It used the WooCommerce API to run stolen credit cards through store checkouts, automating card testing at a scale that put thousands of stores and their customers at risk.
The damage lands on the merchant. Each test is a small order on a stolen card, and each one that clears becomes a chargeback a few weeks later. Below: what to have in place, what went wrong, and what a payment risk score would have caught.
Groundwork every store needs before an attack
Three things, none of them optional for a store that takes cards:
- Audit plugins, APIs and custom code on a schedule, third-party integrations first.
- Keep WordPress, WooCommerce, plugins and dependencies current. Known holes in old components are where attackers start.
- Give every person and every API key the least access it needs, and log what they do.
Practices that make carding expensive
Make a thousand card attempts cost the attacker more than they earn:
- Two-factor authentication on every admin account.
- Rate limits on the API and the checkout, with IP filtering for the addresses that keep coming back.
- HTTPS on every page, so card data and sessions cannot be read in transit.
- Backups you have tested, and a written plan for the day a breach happens.
- API logs you read, or a tool that reads them for you: calls you did not expect, and request volumes no human customer could produce.
What could have been done differently
The package sat on PyPI for a long time and worked against WooCommerce stores because nobody was watching either side. Three things would have shortened its life:
- Tighter checks on new packages, and on the dependencies you pull in.
- Rate limits and traffic analytics on the WooCommerce API, so a burst of small, repeated payment attempts raised a flag.
- Restricted, rotated API keys, in case a leaked key was part of the abuse; a leaked key turns a store's API into a free card-testing endpoint.
What a payment risk score would have caught
Card testing has a shape. One device, or a small pool of IP addresses, places many low-value orders in a short window, each with a different card number, and most decline. A score built from device, network and behaviour signals sees that shape within the first few attempts.
Sensfrx scores every payment, login and signup that way. Against this tool it would have:
- Tied the attempts together by device fingerprint and network, even as the card numbers changed.
- Blocked, or held for review, the orders that matched the pattern, under rules you set.
- Shown you the attempts as they happened, not as next month's chargebacks.
Where Sensfrx fits
Sensfrx installs as a WooCommerce plugin, with plugins for Shopify, WHMCS, Blesta and WISECP and a REST API for custom checkouts. There is a free plan and a 14-day trial, so you can watch it score your own traffic before paying anything.
It does not replace the groundwork above. Patching, least privilege and rate limits shrink the attack surface; the score deals with what still reaches the checkout.
Start with the plugin on the free plan. If you need help wiring the API into a custom checkout, write to us.