Catch card testing before it costs you

Fraudsters use signup pages to check which stolen cards still work. Here is how a subscription team spots it in minutes, gets alerted the next time, and cleans up the accounts that got through.

Card testing is quiet until it isn't. Someone with a list of stolen card numbers needs to know which ones still work, and a subscription signup page with a cheap trial is an ideal place to check. Each attempt looks like an ordinary customer. Together they cost you decline fees, damage your standing with the card networks, and leave behind accounts that will turn into chargebacks.

What it looked like

An illustration, built from a real pattern we analysed with a subscription business. Numbers are rounded and nothing identifies the business.

At about 8:30 one evening, a single affiliate traffic source started sending signups. Over the next 38 minutes:

• about 350 new accounts were created, nine a minute;
• every account used a different card, and each card was tried about once, so no "too many attempts on one account" rule ever fired;
• the accounts came from roughly 90 IP addresses, four or so accounts each;
• 96% of the card checks were declined: insufficient funds, card number declined, call the issuer, and dozens marked as reported stolen;
• the cards were mostly from one country and matched their IP country, and the security codes mostly matched, which tells you the fraudster had complete card details and was testing which were still live;
• the fraud screen let nearly all of it through. The card issuers did the declining.

About a dozen accounts got through and started paid trials. Those are confirmed-working stolen cards, and if nothing is done they renew at full price and come back as chargebacks.

How a team finds it with Retrixus

Ask in plain words, in Claude or ChatGPT:

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

One source stands out immediately: hundreds of accounts, almost all declined, almost none paid. Then narrow it down:

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

Retrixus reads Recurly live, so this includes the attack that started an hour ago, not just what last night's report had.

How it gets caught next time

Ask for a watch:

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

Your AI asks the questions that matter (which traffic, what is normal, who should hear) and first shows you when the alert would have fired on your own recent history. Then it checks every 15 minutes and emails you, or posts to Slack, when the line is crossed. A burst like the one above is flagged within about 15 to 30 minutes of starting, not the next morning.

How the damage gets cleaned up

"Cancel the subscriptions of the accounts from that source that got through, refund their trial charges, and add a note saying why."

Retrixus plans it first and changes nothing until you confirm. You see how many accounts, the refund total, any account it expects to fail and why, and the note as it will read. Anything over your limits needs an Admin or Owner to approve. Then it runs in the background, never does the same thing twice, and records every change in your audit log.

Save it as a playbook, and next time you only supply the dates and the traffic source.

What you need

• A Recurly site connected to Retrixus. Finding works on the Team plan.
• Running the watch and the clean-up need Business, and the clean-up needs the site switched to read and write.