The signups that cost you the most money last quarter passed every check you have. Real name. Real card, issued to that name. Home IP, residential ASN, the same browser they use for banking. Your risk score came back clean because it was clean.
First-party fraud is the category where the person committing it is the account holder. Stripe's definition is people who "misrepresent themselves or manipulate their own accounts for financial gain," as against third-party fraud, "where the perpetrator exploits another person's information" (Stripe, what is first-party fraud). There is no stolen card to detect and no synthetic identity to unpick. The identity is genuinely theirs.
Which is why every tool you bought is pointed at the wrong question. Identity verification, card checks, Radar, your email validator: all of them answer "is this person who they claim to be?" and for first-party fraud the answer is yes, every time, right up to the moment the money leaves.
What first-party fraud actually is
In a SaaS or subscription business it shows up in three shapes.
Trial and promo abuse. One person, many accounts, each one taking a fresh 14 days or a fresh block of free credits. Stripe's own analysis of the pattern reports that 7.4% of customer sign-ups at AI companies are implicated in suspected multi-account abuse, which is the highest-cost version of this because inference is metered and the free tier is real money going out the door.
Refund abuse. The customer uses the product through the billing period, exports what they needed, then asks for the money back. Your refund policy is generous because generosity is cheap when most people do not exploit it, and this is the person who read the policy first.
Chargeback-as-cancel. They dispute the charge instead of clicking cancel. The issuer refunds them immediately, debits you, and files it under a fraud reason code.
Friendly fraud vs first-party fraud
Stripe's docs treat the two as aliases and then define the pair narrowly. Friendly fraud, "also known as 'first-party misuse' or 'first-party fraud'," is what happens when "a legitimate cardholder makes a purchase, but then disputes it at a later date" (common types of online fraud). That definition is chargeback-shaped, and it is smaller than the problem you have.
The largest part of first-party fraud never touches a card at all. A user cycling free trials on a plan that requires no payment method generates no charge, no dispute, and no Stripe object of any kind. You will not find that loss in your dispute report. You will find it in your compute bill.
What unites the three shapes is that the abuser and the customer are the same legal person, so no identity signal separates them.
Why your fraud score says everything is fine
Radar is a good product aimed at a different problem. Stripe describes the model as using "hundreds of risk factors about each payment and data across our network of businesses to predict whether a payment is likely to be fraudulent," reported as a score from 0 to 99 where 65 is elevated risk and 75 is high (Stripe, transaction risk prevention). "Fraudulent" there means unauthorized. Stripe says so in one line on the fraud types page: a payment "is considered fraudulent when the cardholder didn't authorize it."
Your first-party abuser authorized it. They are the cardholder, on their own device, at their own address, with matching AVS and a CVC they typed from the card in their hand. Every feature that flags a stolen card resolves in their favour. A per-transaction model looking for a stranger cannot flag the account holder, and it is not broken when it fails to.
There is a second gap worth knowing about if you sell subscriptions. Stripe's docs state that "the Radar fraud models only score the initial payment of a recurring Stripe Billing subscription, but evaluate rules for all payments". The month-one charge gets scored. The month-seven renewal, which is the one that gets disputed, does not.
So the signal that separates a good customer from an abuser is not present at the moment of the transaction at all. It arrived earlier, as an outcome: a chargeback in March, a refund in June, four trials that never converted. History is exactly what a per-transaction score is designed to throw away.
The chargeback that replaces the cancel button
From the customer's side the choice is not close. Cancelling means finding your account settings, your billing tab, and whatever retention flow you put in the way. Disputing means opening a banking app, tapping the transaction, and choosing a reason from a list. Nobody asks them to prove anything.
The reason they pick is usually a variant of "I don't recognise this," which Visa files as network reason code 10.4, card-absent fraud. That code is the expensive part. Disputes count toward your dispute activity whether you win them or lose them, and Stripe notes that the industry treats dispute activity above 0.75% as excessive, with a sudden spike or steep upward trend enough to put you in a monitoring program before you reach that threshold. A customer who disputes rather than cancels takes the MRR back and spends a piece of your processing relationship on the way out.
Visa's Compelling Evidence 3.0 exists because the networks now accept that a real chunk of 10.4 disputes come from the actual cardholder. To use it you need at least two previous undisputed transactions on the same payment method, 120 to 364 days before the disputed one, and the transactions must match either two main evidence elements or one main plus one secondary. The main elements are customer purchase IP and customer device fingerprint or device ID; the secondary ones are shipping address, customer email address, and customer account ID (Stripe, Visa CE 3.0 disputes). We covered the evidence side of this in friendly fraud: why the customer disputes and how to win.
Read that requirement list again as a specification rather than a dispute form. Visa is telling you that the merchant-side facts worth anything are IP, device fingerprint, email, and account ID, recorded per transaction and kept for at least a year. If you are not logging those today, CE 3.0 is unavailable to you, and so is everything else in this post.
Trial abuse and refund abuse are the same person
Now put the two halves together. The customer who disputed in March comes back in April with a new email address, and to your database that is a new user.
What actually changes between the two signups is less than founders assume. The email changes, because email is free and infinite. The IP changes, because they are on a phone or a home connection with a rotating address, or because they clicked a VPN. Almost nothing else does, unless they are working hard at it.
| Identity key | Survives a fresh signup? | Why |
|---|---|---|
| Email address | No | Free, unlimited, plus-addressing and disposable domains |
| IP address | No | Rotates on mobile and residential ISPs; shared by many real users behind CGNAT and office egress |
| Card fingerprint | Usually | The processor returns a stable fingerprint for the same card number across accounts |
| Device fingerprint | Usually | Requires a different browser profile or machine to change |
| Phone number | Usually | Real numbers cost money and receive SMS |
That is not a novel observation among people running these businesses. On the Hacker News thread Stripe is friendly to "friendly fraud", shash7 gives the rule they run after a chargeback: "completely ban the customer from your db," listing a card ban, an email address ban, and fingerprinting the customer's access to ban that too.
The instinct is right. The hard part is that a ban list is only as good as the moment you write to it and the keys you write. Most teams have a banned_emails table, which is the one key that does not survive.
Memory beats prediction here
Prediction asks what this transaction looks like. Memory asks who this is and what happened last time. For first-party fraud the second question is the only one with an answer, because the defining signal is an outcome you already observed and recorded.
The shape that works is an identity graph with outcomes attached. Every event, paid or free, records the keys the person exposed: hashed email, device fingerprint, card fingerprint, phone. Keys that co-occur on an account link that account into a cluster. When an outcome lands, a chargeback, a fraudulent refund, a trial that burned 40,000 tokens and never converted, you write it against the cluster, not against the row. The next signup that presents any key in that cluster inherits the record even though the email is brand new.
IP does not get to link accounts. Two users behind the same corporate NAT or the same mobile carrier gateway are not the same person, and a graph that links on IP will merge half a university into one abusive cluster. IP is worth counting velocity on and worth nothing as an identity.
Stripe gives you a fragment of this and it is worth turning on: refunding a payment with reason: 'fraudulent' "adds the email address and card fingerprint associated with the payment to the default email address and card fingerprint block lists" (transaction risk prevention). Two keys, one direction, and only for people who reached a charge. It does nothing for the free-tier abuser who never entered a card, and nothing at signup, which is where trial abuse has to be stopped.
This is the thing I built Portreeve for. It links accounts across hashed identity keys, email, device fingerprint, card fingerprint, phone and other identity hints, and payer wallet, and confirmed abuse on one account marks the whole linked cluster; IP stays a soft signal that never links accounts on its own. The Feedback API takes confirmed_abuse, false_positive, or chargeback against an event or against an account id, so a dispute you report on Tuesday changes the verdict for that cluster's next trial start or checkout. And a review verdict never blocks the user: the flow proceeds, the event lands in a queue, and a later deny reaches your server on a signed webhook so you can revoke the trial after the fact (handling verdicts, test mode and feedback).
What to do with a known repeat offender
Knowing is most of the work. What is left is a policy decision, and it differs by moment.
At trial start, block. There is no revenue to protect and no customer relationship to damage, because this is the sixth account belonging to someone whose first five ended in a dispute or a burned credit balance. Show a generic error, not "you are banned," which tells them which key to change next.
At checkout, prefer review over an outright block unless the cluster carries a confirmed chargeback. Let the charge go through, hold the entitlement upgrade or the fulfilment, and resolve it in a queue within the hour. Being wrong in that direction costs you nothing: a good customer never notices the flag, and a bad one gets revoked when the review resolves against them.
At the refund request, say no and cite the logs. Someone who consumed the full month, exported everything, and asked for a refund on day 29 is a different conversation once you can see two prior accounts with the same device and the same pattern.
And write the outcome back every time. A dispute lands four months after the charge and long after the signup it belongs to, so the record has to be addressed to the account rather than to the original event id, or it never reaches the cluster that needs it. Report the false positives with the same discipline. A graph you only ever teach to say no drifts into blocking people who share a laptop.
What to change this week
Three things, in order of leverage.
Collect a device signal at signup, including on free plans. It is the key CE 3.0 asks for, the key that survives a new email address, and the only one you can get from a user who has not paid you anything. A browser fingerprint snippet is a script tag and a token you pass server-side.
Capture the card fingerprint even when you are not charging. If you collect a payment method for a trial, you already have one from the processor; store it against the account. Never store the card number, which you should not be able to see anyway.
Stop treating representment as the fix. Winning a CE 3.0 case recovers one charge and teaches you nothing, because the same person signs up again next week under a new address and your system has no record that anything happened. Fight the dispute if the evidence is there, then write the outcome down somewhere the next signup will read it. Cycling trials is the same problem wearing different clothes; we went through that specific case in how free trial abuse works.
The policy is not what is being exploited. The lack of memory is.
If you want the memory without building the graph yourself, Portreeve's free tier screens 1,000 events a month with no card: create an account and point your signup and checkout at it.