Fake card-testing orders in WooCommerce/PayPal

I’ve had multiple WooCommerce clients this year (2025) plagued by failed orders in WooCommerce. After lots of log-file analysis, it turns out to be a card-testing attack exploiting the WooCommerce/PayPal REST API.

The botnet card-testing attack

Instead of simulating a user navigating the website’s front-end, the bots create multiple low-value transactions using the site’s REST API. Most transactions are declined by PayPal, but some are authorised. Presumably the criminals behind the attack use the authorised cards to make cash withdrawals, before the cards are blocked by the issuer.

Dealing with the attack as it happened

The attacks are usually intense, with new fake orders created in waves. There would be 10 minutes of multiple orders every 10 seconds. Then there would be some respite of 10 minutes. The attacks are relentless, continuing until either the PayPal gateway is deactivated, or all their IP addresses are blocked. But they have an awful lot of IP addresses at their disposal.

Anatomy of the attack

Analysis of the web server access logs show the attack works with the REST API like this:

First… find the cheapest in-stock product in the shop:

GET /wp-json/wc/store/products?stock_status=instock&order=asc&orderby=price&min_price=100&...

Get the cart object as JSON then add the cheapest product to the cart (qty=1):

GET /wp-json/wc/store/cart
POST /wp-json/wc/store/cart/add-item

Set the customer’s billing details with some semi-random data:

POST /wp-json/wc/store/cart/update-customer

Create the order via the PayPal gateway

GET /checkout/
POST /?wc-ajax=ppc-data-client-id
POST /?wc-ajax=ppc-create-order

Creating a defence

The bot uses the same API endpoints used by the block-mode cart & checkout pages. So blocking the endpoints would break some website front-end functionality – not a realistic option. Which is a shame, because that would be easy – we could even do that in “.htaccess”.

The user billing data seem to be formatted similarly, with a lowercase first & last name, a single capitalised word for the billing company, and a US-style phone number (regardless of the billing country). I initially looked at building a defence around this and it worked for customers who only sell to the UK and Europe. But it would’ve blocked legitimate sales for my Woo customers that sell to the US, so I needed something else.

It’s all about cookies

I put in a trap to analyse which cookies exist when the checkout endpoints are requested, and it’s quite a minimal collection. Because the bot hasn’t visited the front-end of the site, it’s only got the bare-bones Woo cookies such as “woocommerce_items_in_cart” and “woocommerce_cart_hash”. There aren’t any Google Analytics (_ga) or cookie-consent cookies.

On one of my client’s sites, there’s a cookie that exists on every page, “cookieyes-consent”. This cookie is set by the CookieYes system and is present regardless of whether the user has consented to any additional cookies being present. So a bot that targets the REST API directly will not have this cookie, but a human visitor’s browser will have it.

So a snippet to block spammy card-test orders on sites that running CookieYes can work like this:

// Block direct access
defined( 'ABSPATH' ) || die();

function custom_block_rest_api_bot_orders() {
	// The (POST) URL paths we want to check against.
	$endpoints = array(
		'/wp-json/wc/store/checkout', // ...
		'/?wc-ajax=checkout',
		'/?wc-ajax=ppc-create-order',
		'/?wc-ajax=ppc-approve-order',
	);

	// Set this to a cookie that's on your site (but not a
	// standard Woo cookie).
	//
	// Some Examples:
	// If you use the CookieYes plugin: cookieyes-consent
	// if you have the Stripe payment gateway: __stripe_sid
	// If you have Google Analytics: _ga
	$required_cookie = 'cookieyes-consent';

	if ( ! is_array( $_SERVER ) || ! is_array( $_COOKIE ) ) {
		// Probably running from WP CLI
	} elseif ( ! array_key_exists( 'REQUEST_METHOD', $_SERVER ) ) {
		// Unknown request type.
	} elseif ( $_SERVER['REQUEST_METHOD'] !== 'POST' ) {
		// Not a POST: we're not trying to create an order.
	} elseif ( ! array_key_exists( 'REQUEST_URI', $_SERVER ) ) {
		// No request path. Weird.
	} elseif ( ! in_array( $_SERVER['REQUEST_URI'], $endpoints ) ) {
		// The requested endpoint is not in our list.
	} elseif ( in_array( $required_cookie, $_COOKIE ) ) {
		// OK: The cookie is present.
	} else {
		// Add a customer message to the site's error logs,
		// which you can use to add the attacker's IP address
		// to your firewall.
		error_log( 'FakeOrderDetected' );
		wp_die( 'Suspicious activity detected' );
	}
}
add_action( 'init', 'custom_block_rest_api_bot_orders', 10 );

To summarise, if we’re trying to access one of the listed endpoints and the “cookieyes-consent” is not present, write a message to the site’s error log and then wp_die(). This will stop any further code executing, so the order will not be created.

If you’re not running CookieYes, you can use your browser’s dev tools to find a list of cookies your site uses, under the “Storage” tab.

IMPORTANT: This code has the ability to block orders in your Woo site’s checkout, so make sure you test it thoroughly. Make some test purchases as a guest user in a private browsing winder. Check your site’s error logs and/or use a plugin like Query Monitor to make sure things are running smoothly.

It’ll be interesting to see for how long this code will remain useful. I’m sure the bots will change tactic, or the Woo/PayPal will add another workflow vulnerability. But for now, this should help reduce a few Woo admin headaches.