WooCommerce card-testing attack: what to do in the next 15 minutes

Before the clock starts

Confirm the pattern—not every failed order is card testing

Card testing usually produces a sudden concentration of low-value attempts, abnormal decline volume, repeated checkout submissions, or obviously synthetic customer details. Attackers may reuse one identity or rotate IP addresses, emails, and sessions. A gateway outage can also create many failures, so compare failed attempts with successful traffic and provider status before treating every decline as hostile.

0–3 minutes

Preserve enough evidence to investigate and escalate

Take a snapshot before logs expire, rotate, or are overwritten. Restrict the evidence to people who need it, and keep all timestamps in UTC so the store, host, and processor records can be aligned.

• Record the earliest known attempt, the current time, and whether the attack is still active.
• Export or note affected WooCommerce order IDs and their statuses.
• Save two or three example gateway transaction or request IDs, decline codes, and timestamps.
• Record counts of failed, blocked, authorized, and completed payments during the incident window.
• Note targeted products, amounts, checkout surfaces, and repeated IP, email, session, or user-agent patterns.
• Preserve relevant WooCommerce, gateway, host, CDN, firewall, and web-server logs before retention removes them.
• Capture screenshots of processor warnings and unusual dashboard graphs.

WooCommerce logs are available under its status/logs area. Some gateway logs exist only when logging was already enabled; turning on verbose logging during an incident can capture sensitive data and should follow the gateway vendor’s instructions.

3–6 minutes

Contact the payment processor with a useful incident summary

The processor can see authorization patterns that WooCommerce cannot. Ask whether it has detected card testing, whether provider-side controls are available, and whether it recommends voiding, refunding, restricting, or temporarily changing any part of the integration.

We suspect an active card-testing attack on our WooCommerce store.

Merchant/account ID: [ID]
UTC incident window: [start] to [now]
Approximate volume: [failed] failed, [blocked] blocked, [successful] successful
Example transaction/request IDs: [IDs — no card data]
Targeted amounts/products: [summary]
Observed checkout path: [Classic / Blocks / Store API / unknown]
Mitigations already enabled: [summary]

Please confirm whether you see card-testing activity, recommend immediate provider-side controls, and advise how to handle any successful suspicious payments.

Do not switch a live gateway into test mode, disable a payment method, or rotate production credentials merely because the option exists. Confirm the operational effect with the provider first.

6–10 minutes

Find the checkout path and apply the narrowest safe control

Classic Checkout often submits through ?wc-ajax=checkout. Checkout Blocks and headless storefronts can place orders through POST /wp-json/wc/store/v1/checkout. An attacker can target the Store API even when the visible Checkout Block is not the page customers normally use.

Check WooCommerce’s Store API rate limit

On supported current WooCommerce versions, review WooCommerce → Settings → Advanced → Features → Rate limiting Checkout block and Store API. WooCommerce documents this as a limit on Checkout Block order placement and Store API POST /checkout requests. It does not, by itself, protect every Classic Checkout or custom endpoint.

Review controls already available at the provider

Check the processor dashboard for card-testing alerts, fraud rules, velocity controls, 3D Secure options, CAPTCHA recommendations, and emergency support. Use the provider’s documented controls instead of inventing gateway-specific settings.

10–15 minutes

Add measured friction and verify that it is enforced server-side

A CAPTCHA badge on the visible checkout does not prove that the payment submission is protected. Confirm that the control covers the exact endpoint being attacked, including Checkout Blocks and Store API traffic where applicable.

• Update an existing CAPTCHA or Turnstile integration to a version that explicitly supports the checkout surface in use.
• Confirm the challenge is validated on the server; a client-side widget alone can be bypassed.
• Avoid stacking multiple CAPTCHA plugins, which can create duplicate challenges or broken checkout flows.
• Prefer a recoverable challenge for uncertain traffic and temporary blocks for clearer repeated abuse.
• If Checkout Firewall is installed, use a time-limited Emergency Mode rather than permanently tightening every threshold.

If the normal checkout path appears to be bypassed

Ask the processor whether an API or secret credential could be compromised. Coordinate any credential rotation with the provider and your developer so callbacks, webhooks, subscriptions, and production checkout are not broken. Card testing alone does not prove that WordPress was breached.

Separate money movement from failed attempts

Review suspicious successful payments before fulfillment

A failed order usually has nothing to refund. An authorized, processing, or completed order may represent captured money and needs a different workflow.

1. 1

   Place suspicious successful orders on hold and do not ship goods or deliver digital value while reviewing them.

2. 2

   Match WooCommerce orders to the processor’s payment records and risk signals.

3. 3

   Follow the processor’s instructions for voiding or refunding confirmed fraudulent payments. Do not refund every small or failed order automatically.

4. 4

   Record the action and transaction ID so later disputes can be reconciled.

Do not assume a setting worked

Verify containment without sacrificing legitimate checkout

Change one control at a time where the attack permits it. Record the time of each change so you can tell which mitigation helped and reverse the one that harmed legitimate checkout.

After the first 15 minutes

Monitor, document, and close the incident deliberately