Card-testing attack incident checklist.

1. Confirm it's card testing (first 15 minutes)

• A burst of payment attempts far above normal volume, often small amounts.
• A high share of declines, frequently with "do not honor", invalid card or CVV/AVS mismatch responses.
• Attempts from many IP addresses or the same browser with rotating names and emails.
• Billing details that don't match, or nonsense names and addresses.

2. Contain it (first hour)

• Turn on or tighten the gateway's velocity and fraud filters (per IP, per hour, minimum amount).
• Add a challenge (CAPTCHA or bot check) to the payment form, or raise CardSecurity to Strict.
• If attempts keep landing, take the public payment form offline temporarily.
• Rotate any API keys or public client keys that may be exposed in a reusable checkout.

3. Tell the processor (same day)

• Call or open a ticket with the processor or gateway; give the time window and sample transaction IDs.
• Ask whether they can block the source and whether fees from the attack can be reviewed.

4. Clean up (first day)

• Void unsettled approved test authorizations; refund any that settled.
• Export the attack's transactions for your records.
• Watch for chargebacks and fraud notifications over the following weeks.

5. Prevent the next one (first week)

• Keep velocity filters and bot checks on permanently, tuned to normal traffic.
• Require AVS and CVV matching where your customers allow it.
• Set a minimum transaction amount if your business allows it.
• Put checkout-level protection in front of the processor so scripted attempts never reach it.
• Write down who to call and who decides to take checkout offline, before the next attack.