The dispute email says fraudulent. The subscription it points at converted from a trial nine days ago, logged in twice, and sits on a card fingerprint that appears on four other accounts in your database. Subscription fraud is the phrase your processor used and the phrase you searched, and it covers three different attacks that show up at different billing events and need different responses.
Two of them look identical in the dispute feed. The third never reaches the dispute feed at all. Sorting them apart in data you already have is a day of work, and it decides what, if anything, you should buy.
Three attacks wearing one name
Stolen-card subscriptions. A card obtained somewhere else opens a trial or a paid plan. The account is used, or resold, until the real cardholder reads a statement. You lose the charge, the dispute fee, and whatever the account consumed, and the loss lands weeks after the signup that caused it.
Trial-to-chargeback. A real person with their own card converts, uses the product for a month, then disputes the renewal as unrecognized or already cancelled. The accounting looks the same as the stolen card. The person is your customer, and this is first-party fraud that no check at signup would have caught.
Seat sharing and resale. One paid seat serving six people, or a login sold in a group chat. Nothing declines and nothing is disputed. Billing sees a healthy customer; the only place the abuse exists is the session table.
Grouped under one word, these three produce a single unusable number. Split by the event where each one is visible, they produce three tractable problems.
The cheapest fraud in subscriptions is a card you validate for free
Start a subscription with a trial period and Stripe stores the card without charging it. In Stripe's own words, from its guide to recurring Apple Pay payments, the subscription "creates a SetupIntent that generates a 0 USD validation with the authorization network."
Read that from the attacker's side. They learn the stolen card is live, at no cost and with no charge on the statement to trigger an inquiry. They get the product for the length of the trial. The first amount anyone could dispute does not exist until day 14.
A free trial chargeback therefore always arrives late. The renewal charge posts, the cardholder sees it on a statement weeks later, and by then the account is spent: credits burned, output exported, or the login resold.
This is why "require a card up front to stop trial abuse" is bad advice for most of the people it gets given to. Against a casual repeat-truster the card form works. Against someone holding a stolen card it is a free card validator plus two weeks of product, and the charge that would have exposed them is deferred by your own trial length.
The card gate does buy you one genuinely useful thing, which is the processor's card fingerprint, stable across every account that pays with the same physical card. If you are not reading that fingerprint as a signal, the form is pure cost, and you would do better collecting the card at conversion. Free trial abuse has a different fix from stolen-card subscriptions even though both arrive through the same form.
Subscription chargeback fraud: 10.4 does not say which one you got
When the dispute lands, the network reason code is the first thing you look at, and it will not answer your question.
Stripe files Visa 10.4, "Other Fraud - Card Absent Environment," and Mastercard 4837, "No Cardholder Authorization," into the same fraudulent category. The same page describes a cardholder who does not recognize a payment on their statement as "effectively indistinguishable from the Fraudulent reason." A stolen card and a customer who forgot they signed up produce the same code, the same category, and the same debit.
What separates them is evidence you own: whether the account logged in, from which device, and whether the person who filed the dispute has behaved like this account before.
Visa's Compelling Evidence 3.0 is built on exactly that idea and, for recent subscriptions, will not help you. To qualify, Stripe's CE 3.0 documentation requires two previous undisputed transactions on the same payment method, within 120 to 364 days of the disputed one, matching either two main evidence elements (customer purchase IP, customer device fingerprint) or one main and one secondary element (email address, account ID). Validation charges are explicitly excluded, so the trial's 0 USD authorization counts for nothing.
A subscriber who converted three months ago and disputed the second renewal has no qualifying history. For the first year of any customer relationship you are on standard evidence, which means login timestamps, device and IP records tied to the account, product usage, and the terms they accepted.
Fighting it is mostly a bad trade. Stripe charges a $15 dispute fee in the US that is never returned, plus a $15 counter fee that comes back only if you win. On a $19 plan you are spending $30 to contest $19.
The reason to care anyway is the ratio. Visa's acquirer monitoring program does not consider dispute outcomes and flags an account as non-compliant at a 0.5% dispute-and-fraud ratio, excessive at 1.5% in the US and most regions. Winning does not lower that number. Preventing does.
Involuntary churn or fraud: split the number
Most subscription businesses have one line called failed payments and one line called disputes, and both are mixtures.
Split failed renewals by decline code first. Stripe's decline codes separate insufficient_funds and expired_card, ordinary involuntary churn worth retrying, from stolen_card, lost_card, fraudulent, pickup_card and restricted_card, which are the issuer telling you this card should not be charged. On the first three, Stripe's guidance is to show the customer nothing beyond a generic decline.
Which is where the second piece of standard advice breaks. Dunning and smart retries are the right tool for a card that expired and the wrong tool for a card the issuer has flagged. A retry on a compromised card has two outcomes: another decline, or a successful charge that becomes a fraud dispute with your name on it. Configure your retry rules to stop on the fraud codes and cancel the subscription instead of grinding through the schedule.
Then cohort the disputes by age of the subscription. Disputes on subscriptions less than 30 days old are a signup problem. Disputes at month six are a billing-clarity and cancellation-flow problem. If the first cohort is growing, no amount of statement-descriptor tuning will touch it.
The cheapest diagnostic you can run today is a group-by. Take every subscription from the last 90 days, group by card fingerprint, and count distinct accounts per fingerprint. Then join logins.
| What you see | Reading |
|---|---|
| Several accounts on one card fingerprint, no logins after day one | Card being tested or subscriptions being resold |
| One account, one card, real usage, dispute at renewal | First-party fraud or a cancellation flow people cannot find |
| One account, one card, steady usage, many devices across regions | A shared or resold seat |
Subscription fraud detection, event by event
Each of the three attacks is loud at exactly one moment and quiet everywhere else.
At signup and trial start, the useful signals are card fingerprint reuse across accounts, the number of accounts created from one device, the number of distinct cards seen on one device, email quality and disposable domains, and whether the connection is a datacenter or proxy egress. IP belongs in the score and never in the identity: shared egress means two accounts on one address are usually two colleagues.
At trial conversion, you have behavior the first check could not see. Did the account use the product before converting, or convert in the first minute and never return? Is the card at conversion the same card that started the trial? Has anything in the cluster been charged back since?
At login, you have the account's own history: unrecognized device against a baseline, how many distinct devices in a week, how far apart the geographies are, whether sessions overlap.
This is the shape of the tool I built. Portreeve returns allow, review or block with reason codes at signup, trial_start, trial_convert, checkout_attempt and login, in under 100 ms, with velocity counters per card, per device and per cluster and an identity graph that links accounts across hashed email, device fingerprint and card fingerprint.
A chargeback reported through the feedback API marks the whole linked cluster, not one email. review never blocks anyone: the flow proceeds, the event enters a queue, and a later deny reaches your server on a signed webhook so you can revoke the subscription with the evidence already in hand. The event payload reference covers what to send at each event, and the test mode and feedback guide covers reporting outcomes back.
Account sharing abuse is a login problem
Seat sharing produces no dispute, no decline, and no anomaly in Stripe. Your revenue is simply lower than your usage, and the gap grows quietly.
Seat limits do not fix it, because a seat limit counts invitations. Six people using one set of credentials consume one seat by that definition, and the sharer has every incentive to keep it that way.
The signal is device diversity on a single account: distinct browser fingerprints per week, concurrent sessions from cities that cannot be the same person, and login patterns that look like shift work rather than one schedule. Device fingerprinting is what makes that countable, because cookies clear and IPs move.
Enforcement is where teams overreach. A consultant logging in from a laptop, a phone, and a client's machine looks like sharing, and hard-blocking that login costs you a customer to save $19. Step up authentication on an unrecognized device, cap concurrent sessions rather than devices, and route the rest to a human with the device list attached.
Feed the disputes back into the gate
A chargeback is the best-labeled event your business will ever produce, and most teams file it under accounting and forget it.
Attach the outcome to identity keys rather than to the account: the card fingerprint, the device, the normalized email, and every account linked to them. The next trial that arrives on that card or that laptop then starts with the history of the last one, which is the only mechanism that raises the attacker's cost instead of your own. Record the false positives with the same discipline, or the graph learns in one direction and slowly strangles your signups.
Two practical notes. Revocation should be idempotent and driven by an event your server receives, since the same webhook can be delivered more than once. And keep the block list narrow: block on confirmed clusters, review on everything suggestive, and let the trial proceed while you decide.
If you would rather not build the graph yourself, Portreeve's free tier screens 1,000 events a month with no card. Create an account and put the first verdict on your trial start.