Fraud Scoring for SaaS Billing: Trial Abuse and Card Testing

No shipping address to lean on

Most card-not-present fraud signals include a shipping-address check — does the delivery address match the billing profile, has this address shipped fraudulently before. SaaS billing has none of that: the "product" is access, not a physical good, so the fraud surface is entirely about the signup and the recurring charge, not a delivery. That missing signal has to be made up somewhere else in the feature set, which is why device and account-linking signals carry more relative weight here than they might in a storefront with a shipping address to lean on.

Trial abuse

A free trial is meant for one new customer once. The abuse pattern is the same account, effectively, signing up repeatedly under a different email, card, or device to keep resetting the trial clock. This is caught the same way multi-accounting is caught anywhere else: device fingerprinting and "seen this device or payment method before" flags that don't care what email is on the new signup.

Card testing via subscriptions

A cheap or free-trial-then-charge signup is an inexpensive way to validate whether a stolen card is still live — the same card-testing velocity pattern e-commerce sites watch for small test purchases, just running through a subscription flow instead of a cart. A burst of trial signups from related devices or IPs, each testing a different card, is the tell.

Promo-code abuse

A discount code meant for new customers gets reused by the same person opening new accounts. It's a milder cousin of trial abuse — worth catching for margin reasons even where it isn't outright fraud, using the same account-linking signals.

A worked example

A SaaS product sees a burst of trial signups within a single hour, each using a different card, each abandoning the trial after the first login. Individually, a single abandoned trial is unremarkable — most trials don't convert. But the burst, combined with several of the signups sharing a device fingerprint, looks like card testing: someone validating a batch of stolen cards cheaply through the free-trial flow rather than genuinely evaluating the product. Flagging the shared-device cluster, rather than judging any one trial signup on its own, is what catches it.

The recurring-billing wrinkle

Unlike a one-off purchase, the fraud signal in SaaS billing isn't only at signup. A card that authorizes fine for the first two billing cycles and then starts failing, or a customer who disputes a charge after months of active use, are different patterns that need account history to catch — the feature store has to track subscription lifecycle state (trial, active, past-due, disputed), not just individual transaction events. A card that fails on cycle three after two clean charges is a different risk profile than one that fails on the very first charge, and only a model with lifecycle state can tell the two apart.

The architecture

The pattern from our fraud-scoring project applies with the feature set aimed at signup and billing-cycle behaviour rather than a single purchase: a boosted baseline on device and account-linking features, a concurrent reasoning layer where a signup's narrative context helps, and three-tier routing — auto-allow, auto-block, and a soft-hold band for signups that look like organic growth spikes as easily as coordinated abuse.

Where this stops being right

• Enterprise sales-led SaaS with no self-serve signup — there's no automated trial-abuse surface if every account is provisioned manually.
• Free tiers with no payment method collected — trial abuse still happens, but it's a growth/cost problem more than a fraud one until a card enters the picture.
• Very low signup volume — manual review of new trials may be cheaper than a model until volume grows.

FAQ

Why doesn't SaaS billing fraud look like ecommerce fraud? There's no shipping address and no physical good — the fraud surface is entirely in the signup, the trial, and the recurring charge instead.

How do you catch trial abuse specifically? Device and payment-method fingerprinting linking accounts across signups — the same "seen before" logic used for multi-accounting elsewhere.

Is a card that starts failing after a few good charges suspicious? It's a pattern worth tracking, not an automatic flag — it needs subscription lifecycle history to interpret correctly rather than being judged as a single event.

ISTRALLEN builds fraud scoring tuned to SaaS signup and billing patterns — see AI for Fintech.