Card testing on your signup page: how to spot it in Recurly in minutes

The signs of a card-testing attack in your Recurly data, the questions that expose it, and how to stop the cards that got through from becoming chargebacks.

By Thomas Fitzgerald, Marketing · 2026-10-18

Card testing is when someone with a list of stolen card numbers uses your checkout to find out which ones still work. A subscription signup with a cheap trial is an ideal target: a small charge or a card check, an instant answer, and no human in the loop.

The attack itself usually isn't the expensive part. The expensive part is what comes after: decline fees on every attempt, a decline ratio that worries your processor, and the handful of cards that worked, which renew at full price and come back weeks later as chargebacks.

The signs, in your Recurly data

Card testing has a recognisable shape once you know what to look for:

• A burst of new accounts from one traffic source. Often an affiliate or a referral code, sometimes direct traffic with no source at all.
• One card per account. Testers create a fresh account for every card, so rules that count attempts per account never fire.
• Shared IP addresses. Hundreds of accounts from a few dozen addresses.
• A very high decline rate on card checks. 90% or more, against a normal rate well under half that.
• Telling decline reasons. Insufficient funds, card number declined, call the issuer, and cards reported lost or stolen.
• Matching security codes. If CVVs mostly match, the attacker has complete card details and is checking which cards are still live, not guessing numbers.

The questions that expose it

You can answer these from Recurly exports and a spreadsheet, but it takes long enough that the attack is over before you finish. In Claude or ChatGPT with Retrixus:

"How many trial signups came in over the last 24 hours, by traffic source, and what share of their card checks were declined?"

"For the worst source, how many distinct cards and IP addresses were used, and what were the top decline reasons?"

"Which accounts from that source have a successful charge?"

Retrixus reads Recurly live, so the answer includes the burst that started an hour ago.

What a real one looked like

An illustration from a real pattern, numbers rounded. One evening, a single affiliate source created about 350 accounts in 38 minutes, each with a different card, from roughly 90 IP addresses. 96% of the card checks were declined. About a dozen got through and started paid trials, and the business's fraud screen had let nearly all of it pass: the card issuers did the declining.

Catching the next one

Spotting it after the fact is useful. Knowing within 15 minutes is better. Set a watch:

"Watch signups from affiliate traffic and alert me if more than 40 come in within 15 minutes."

Retrixus first shows you when that alert would have fired on your own recent history, so you set the threshold where it means something. Then it checks every 15 minutes and emails you, or posts to Slack.

Cleaning up the cards that got through

The accounts with a successful charge are the urgent ones. Cancel their subscriptions before they renew and refund the trial charge, so the cardholder's bank sees a refund rather than a dispute.

"Cancel the subscriptions of the accounts from that source with a successful charge, refund those charges, and note the account as card testing."

Retrixus plans it first: how many accounts, the refund total, and the note as it will read. Nothing changes until you confirm.

Prevention still matters

None of this replaces the basics at checkout: a fraud screen tuned for your traffic, a CAPTCHA or rate limit on signup, and a hard look at affiliates that send traffic like this. But attacks get through every defence eventually, and the difference between a bad evening and a bad month is how quickly you see it.

Start free on one Recurly site, or see the full card testing use case.