WooCommerce Store Owners Combat Fraudulent Stripe Charges

• Updated on: 2023-05-10
• Read original article here

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.

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.