Who pays for declined authorizations during card testing

A card-testing run can leave you with hundreds of failed orders and no revenue at all. It is easy to assume that no sale means no cost. That assumption is usually wrong, and the bill tends to arrive weeks later, spread across a few places.

This note walks through where the cost lands. It stays in general terms, because the exact amounts depend on your gateway, your contract, and your country. Your own pricing page and merchant agreement are the only sources for real numbers.

The attempt reaches the gateway before anyone says no

Each card test is a real authorization request. Your checkout sends the card to the gateway, the gateway passes it to the card network, and the network asks the issuing bank. The bank says no, or occasionally yes.

Every step in that chain did work, and some of that work is billable. A decline is not free just because no money moved.

Gateway fees on failed attempts

Gateways price declines differently. Some charge a per-attempt or authorization fee whether the card succeeds or not. Some bundle declines into a flat percentage on successful charges and do not bill failures directly. Some do one thing on a standard plan and another on a custom contract.

Read the fee section of your agreement for words like authorization fee, attempt fee, or declined transaction. If the gateway charges for them, a run of a few thousand attempts can add up even at a small unit cost. If it does not, the direct fee may be zero, but the other costs below still apply.

Some stores also run a separate fraud screening service that bills per screened transaction. Those charges count every attempt too.

The cards that succeed cost more

Card testers want to find live cards. When one passes, the attacker may place a small charge, or the authorization may settle as a real order in your store. That order looks like a sale.

The real cardholder eventually sees the charge and disputes it. The dispute brings its own costs:

• You lose the sale amount, because the issuer pulls it back.
• Most gateways charge a dispute fee, and many keep it even if you win.
• If you shipped goods, you lose the goods and the shipping cost.
• You or your staff spend time gathering evidence, which is rarely worth it for a small fraud order.

Refunding a suspicious small order before the cardholder notices can sometimes head off a dispute. Ask your gateway how they treat refunds on orders they later flag. Policies vary.

Account health is the cost that hurts most

Gateways and acquirers watch ratios, not only totals. A sudden spike in declines tells them your checkout is being used as a test rig. A rise in disputes tells them fraud is getting through.

The responses range from mild to serious. A gateway might email you, hold payouts, add a reserve on your balance, ask you to add fraud tools, or pause card payments. In the worst case, it closes the account.

Card networks run their own monitoring programs for merchants with high fraud or dispute levels. Fines in those programs usually go to the acquirer, and contracts often let the acquirer pass them on to you. Your merchant agreement will say whether it does.

A closed account is the most expensive outcome. You lose the ability to take cards while you look for a new provider, and a record of a terminated merchant account can make that search harder.

Who pays, in short

• Your store pays per-attempt fees if your plan has them, plus dispute fees, lost goods, and staff time.
• The cardholder pays nothing in the end if they dispute, but deals with a replaced card and a stressful week.
• The issuing bank absorbs the cost of reissuing cards and handling disputes it cannot pass back.
• The attacker pays almost nothing, which is why card testing keeps happening.

The last line is the one to remember. Card testing is cheap to run and expensive to receive. Anything that adds cost or friction to the attacker's side changes that math.

What to do during and after an attack

1. Stop the flow first. Turn on whatever checkout protection you have, or switch to a payment method that needs a redirect, while you work out the rest.
2. Count attempts in the gateway dashboard, not in your WooCommerce order list. One failed order can hold several declines.
3. Find any approved orders from the attack window. Hold them, and refund the ones that clearly came from the bot before they ship.
4. Contact your gateway's support team. Tell them you had a card-testing attack, what time it ran, and what you changed. A merchant who reports early usually gets a calmer response than one whose ratios they spot first.
5. Ask whether any declines will be billed, and whether they waive or credit fees for confirmed attacks. Some providers do this case by case.
6. Watch for disputes over the next several weeks. They arrive slowly, so the true cost of the attack shows up late.

Prevention is cheaper than any refund

Each attempt you stop at your own checkout never reaches the gateway, never counts toward a decline ratio, and never becomes a dispute. That is why front-end checks are worth having even when your gateway already screens for fraud.

We built Checkout Bouncer for that part. It scores each order submission with reCAPTCHA v3 on every route an order can take, and adds an order-rate throttle that works with any gateway, so a scripted run gets rejected before the gateway is asked to charge a card. It is free, and it works alongside whatever screening your gateway already does.