Reading your checkout events after an attack
After a card-testing attack, your events export shows when it ran, which route it used, and whether real buyers got blocked. Here is how to read it.
What we find in real checkouts, and what a shop owner can check for themselves.
After a card-testing attack, your events export shows when it ran, which route it used, and whether real buyers got blocked. Here is how to read it.
Turning off guest checkout rarely stops card testing. It often hands bots an account and the add payment method page, which never shows in your orders.
Cloudflare can drop crude checkout floods at the edge. It cannot see cart or gateway state, and a challenge on the checkout submit breaks real orders.
Radar judges the card after your site sends it. A checkout captcha judges the request before anything reaches Stripe. You want both.
A new checkout rule is a guess about normal traffic. Monitor mode checks that guess against a week of real orders before it can turn a buyer away.
Card testing brings in no revenue, but it still costs you. Here is where the bill lands: gateway fees, disputes, and the health of your merchant account.
X-Forwarded-For is a header the client writes. Here is why trusting it turns an IP allowlist or rate limit into a bypass, and how to fix it.
A low reCAPTCHA v3 score is doubt, not proof. Why real customers score low, and why checkout should fail open when Google is slow.
Theme demos, page builder tests, and staging pushes leave extra WooCommerce checkout pages that still take orders. How to find and remove them.
Bots can test stolen cards through the WooCommerce add payment method page and never create an order. How to spot it and close it.
Pro waitlist
The free plugin stays free. Join the launch list for founding pricing on Pro and one email when it is ready. Nothing else.
Received