For the past few weeks, members of the Advanced WordPress Facebook (AWP) group have been discussing methods of combatting Stripe Card Testing fraud. WordPress developer Jon Brown opened the topic after seeing fraudulent charges on five different websites, including four using WooCommerce and one using the Leaky Paywall platform.
“All five were on Cloudflare with bot fight mode on when it first happened,” Brown said. “I’ve added CAPTCHA to all 5, I’ve enabled CloudFlare’s ‘Under Attack’ mode on the cart/checkout page.”
The WooCommerce sites didn’t have a reoccurrence but the Leaky Paywall site did. Brown said the client didn’t notice it, as he had Stripe emails going to his spam folder.
“It went on for two weeks until the load spike took the site offline and I noticed it,” he said. “About 1,200 successful transactions for $2.99, with 100,000 blocked.”
Brown said he doesn’t understand why Stripe doesn’t recognize and block the fraudulent charges since they all follow a similar pattern using a randomized Gmail address. His client had to dispute approximately 100 of these transactions.
“Each dispute costs $15 to resolve,” Brown said. “Each non-disputed refund costs $0.40 since Stripe (like PayPal now) keeps the fee.
“So 100 * $15 + 1100 * $0.40 = $1940 in lost revenue to fees and that’s obviously AFTER also refunding the $2.99 per fraudulent transaction. That means $3,600 in fraud ($2.99 * 1200) just resulted in a net loss of $1940 – that’s insane.”
Many other developers in the conversation have been hit with similar attacks, some with honeypots in place that didn’t prevent anything. One recommended using the WooCommerce Fraud Prevention plugin. It allows store owners to block orders from specific IP addresses, emails, address, state, and zip codes. This might help once attacks have started but doesn’t fully prevent them. Some developers had success stopping attacks using reCaptcha for WooCommerce, a commercial plugin that implement’s Google’s reCaptcha V2 (checkbox) and reCaptcha V3 to stop things like unauthorized login attempts, fake registrations, fake guest orders, and other automated attacks.
“We ran into this about a year ago,” WordPress developer John Montgomery said. “It’s a way for hackers/thieves to check a list of card numbers for ones that are valid. Once they confirm the card works on a site, they can use to purchase products for real. In the end, a big annoyance but honestly not a huge deal for us in the end because we have digital products and they weren’t really interested in those.”
Montgomery installed a plugin called Limit Orders for WooCommerce, developed by Nexcess, that disallows orders after a certain threshold is met.
“I set it up to x orders per hour ( above any historical numbers)…so if we get say 100 orders in an hour it will shut off orders,” he said. “It’s a bit of a sledgehammer, but it did help us once already.”
Although many store owners are hesitant to add any friction to the checkout process, technology consultant Jordan Trask recommends requiring customers create accounts before continuing and verify emails. He wrote a guide on dealing with card testing attacks.
“The gist of the rules is blocking all countries except those you serve,” Trask said. “However, for WooCommerce, I would put in a JS Managed Challenge for the cart and checkout.
“There is rate limiting built into Cloudflare that might help, but it’s more request based versus per order which is what you need based on IP potentially. If the requests come from the same IP address, you can look at limiting orders per IP since the email differs each time.”
The Checkout Rate Limiter plugin, available on GitHub, offers checkout rate limiting on WooCommerce checkout based on IP address.
Trask’s guide also recommends checking payment processor logs when investigating fraudulent charges:
Always check your payment processor logs to verify where the charges are being created. A staging site may exist with production API keys, or your site was hacked, and the API keys were stolen. Most payment processors will have further details in their logs with additional information.
WordPress developer Rahul Nagare recommends checking out Stripe’s Radar fraud protection, which uses machine learning to provide advanced protection and identification of fraudsters.
“This will let you setup custom rules on Stripe to reject suspicious transactions,” Nagare said. “This used to be a free service with Stripe, but they changed it last year. I’d look into blocking all transactions with risk score higher than the average, and maybe the region of the card testers.”
WooCommerce’s documentation has a section on responding to card testing attacks, which has many of the same recommendations discussed in the recent AWP thread. A CAPTCHA plugin is the first line of defense. It also recommends avoiding pay-what-you-want or donation products with no minimum, as these products are often targeted for card tests with small transactions that cardholders might miss. Swiftly refunding any successful fraudulent orders will decrease the possibility of disputes.
Sorry for any misinformed comment but I’m completely new in ecommerce.
I’m thinking on starting some stores and this article took my attention.
So, if I understood correctly, the store owner wasn’t affected, but the clients did. The problem was that the card number of the client was stolen? I guess the shop owner has no responsibility..?
I don’t really understand where, objectively, the problem starts? Client’s machine, WordPress, Woocommerce, Stripe?
I can’t believe there isn’t a safe method yet.
Can’t the client receive a double check code in the email, or any other unique transactional token to confirm the transaction? This seems so simple to do.
This is very scary and “bad reputation” – I know there are millions of “good”examples but we know how this “bad news thing” works.
I think – even more now that having an online store is getting easier and a priority for all – it should be on WP Core (or Woo Core?) something to prevent it.
Reputation is at stake.