Add payment method: the card-testing route with no order at all

Your gateway dashboard shows hundreds of failed card checks, but your order list is quiet. No failed orders, no junk guests. The attack is real, and it is going through the add payment method page.

What the route does

When a gateway supports saved cards, WooCommerce adds a Payment methods section to My Account. From there, a logged-in customer can add a new card. The form sits at the add-payment-method endpoint, usually at /my-account/add-payment-method/.

Adding a card does not create an order. The gateway checks the card and saves it for later use. With Stripe, for example, this goes through a SetupIntent, and the card issuer may run a zero or small authorization to confirm the card is real.

That check is exactly what a card tester wants. It tells them whether a stolen card works, and it leaves nothing in your WooCommerce order list.

Why it is easy to miss

Most store owners watch orders. They set up alerts on failed orders, and their fraud plugins look at orders. A route with no order skips all of that.

The only places it shows up are the gateway dashboard, your server access logs, and the customer list. That last one is the clue many stores find first: a sudden run of new customer accounts with random names and email addresses.

The account is part of the attack

The add payment method page needs a logged-in user. A bot gets one by registering. If your store lets anyone create an account on the My Account page, or during checkout, the bot registers, logs in, and starts adding cards.

One account can try many cards. WooCommerce has a short built-in delay between added payment methods for the same user. The default is 20 seconds, and the notice reads "You cannot add a new payment method so soon after the previous one." That slows a single account down, but it does not stop a bot that creates a new account every few attempts.

How to spot it

• Card checks in the gateway dashboard with no matching WooCommerce order.
• A spike of new customer accounts, often with no orders.
• Access log POST requests to the add-payment-method path, often from a small set of IP addresses.
• Saved payment tokens on customer accounts that never bought anything.

A quick way to check the log, if you have shell access:

grep "add-payment-method" access.log | grep POST | awk '{print $1}' | sort | uniq -c | sort -rn | head

The path may be different if you renamed the My Account endpoints in WooCommerce settings. Use the slug your store actually uses.

What to do about it

Start by asking whether your customers use this page at all. Many stores enable saved cards for faster repeat checkout, but customers save cards during checkout, not from My Account. If nobody adds cards from My Account, you can close that page and keep saved cards working at checkout.

If you need the page, protect it the same way as checkout:

• Add a server-side bot check to the add payment method form, and refuse the request before the gateway is called if the check fails.
• Look at how accounts get created. Turn off registration on the My Account page if you do not need it, or put a bot check on registration too.
• Use your gateway's fraud rules. Some gateways can apply rules to card setup as well as to payments, so check that yours does.
• Delete the junk accounts after the attack, along with their saved tokens, so they cannot be reused.

Close or protect this route before you need to. It is a common second target after a store locks down its checkout.

A note on testing

To test the route, create a customer account in a private window, go to Payment methods in My Account, and add a gateway test card. If the request reaches the gateway without your bot check running, the route is open. Remove the test account afterward.

Where Checkout Bouncer fits

Checkout Bouncer treats add payment method as a checkout route. The Checkout Scanner lists it, and you can set it to Protect with a reCAPTCHA v3 check verified on the server, or to Block, which closes the endpoint for stores that never need it. Registration protection is outside what the plugin does, so handle that part separately.