One Stolen Card, Twelve Accounts: Catching Cross-Account Fraud with Stripe Card Fingerprints

A SaaS founder we spoke with recently found something odd while investigating a chargeback. The disputed payment came from an account created three weeks earlier with a clean-looking Gmail address. But when he searched his Stripe dashboard for the card's last four digits, the same card showed up on eleven other accounts. Different emails, different signup IPs, different names. One card, twelve accounts, and by the time the first chargeback landed, eleven more were already in the pipeline.

Every one of those accounts passed email validation. Most were behind residential IPs. Individually, each looked fine. The only thing connecting them was the piece of plastic paying for them all.

That is the gap card fingerprint tracking closes. Here is the short version: Stripe attaches a stable hash of the card number, called a fingerprint, to every charge. Track it, and the same card reappearing across different customer identities becomes trivially visible. Fraudsters can rotate emails, devices, and IPs for free, but stolen cards cost them real money. Watch the scarce resource, and the cheap disguises stop mattering.

What the fingerprint actually is

Every Charge object in Stripe carries payment_method_details.card.fingerprint: a short opaque string like Xt5EWLLDS7FJjR1c. The same card number always hashes to the same fingerprint within your Stripe account. A different card never collides with it.

Three properties make it ideal for fraud work:

1. It survives identity rotation. New email, new account, new device, same fingerprint.
2. It is not card data. The hash is one-way. Storing it creates no PCI exposure, so you can index and query it freely.
3. You already have it. It arrives on every webhook you are receiving today. No extra API calls, no client-side collection.

The economics: why this signal beats email and IP checks

Think about what each signal costs a fraudster to change.

Email and IP checks are still worth running, and disposable email detection kills a huge amount of low-effort abuse on its own. But a determined fraudster treats identities as disposable and cards as inventory. When your detection keys on the thing they cannot afford to burn, their per-account cost stops being zero. Usually that alone is enough to send them somewhere softer.

Three patterns worth alerting on

1. One card, many accounts

The account-farming signature from the story above. Whether it is a stolen card funding fake accounts or one person repeatedly exploiting your free tier and trial offers, the tell is identical: distinct customer emails transacting with the same fingerprint.

A sensible starting threshold: flag when a card has been used by 2+ other customer identities within 30 days. Genuine overlap exists, a couple sharing a card across two accounts, so treat the first hit as a review signal rather than an instant block, and escalate severity as the count climbs. Five accounts on one card is not a family.

2. One card, rapid-fire charges

Many charges on the same fingerprint in a short window, across any identities. This catches abuse moving too fast for per-email velocity checks to connect. Three or more charges on one card in 24 hours is a reasonable trip wire.

3. One customer, many cards

The inverse, and the most dangerous: a single identity cycling through distinct cards. This is card testing, a fraudster validating a stolen card list with small charges to find the live ones. Three or more distinct fingerprints from one customer in 24 hours is the classic signature.

Card testing hurts twice. The successful tests become fraudulent charges and TC40 reports now, and the attack itself inflates your enumeration ratio under Visa's VAMP rules, which Visa tracks separately from your dispute ratio. Catching it protects you with the card networks on both fronts.

What this looks like in practice

Fidro now runs all three checks automatically on every Stripe payment it analyzes. The fingerprint is read from the payment_intent.succeeded webhook you have already connected, so there is nothing new to integrate. A flagged transaction comes back like this:

{
  "risk_score": 82,
  "recommendation": "refund",
  "risk_message": "HIGH RISK - Card used across multiple accounts, disposable email",
  "checks": {
    "card_reuse": true,
    "disposable_email": true,
    "card_velocity": false,
    "card_testing": false
  }
}

The reuse check only counts other emails seen with the card, so a returning customer paying with their saved card never trips it. All comparisons are scoped to your own account: fingerprints are never matched across Fidro customers, and Stripe's fingerprints are only stable within one Stripe account anyway.

When a card is confirmed bad, block the fingerprint itself, either with the Block this card button on the transaction page or through the API:

curl -X POST https://api.fidro.io/api/blocklist \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "card_fingerprint",
    "value": "Xt5EWLLDS7FJjR1c",
    "reason": "Confirmed stolen - funded 12 farmed accounts",
    "severity": 10
  }'

From that moment the card is dead on arrival across your entire platform. The fraudster can bring a fresh email, a new VPN endpoint, and a clean device, and the transaction still scores as blocked. The full setup, thresholds, and tuning options are in the card fingerprint tracking docs.

Rolling your own instead

If you would rather build this in-house, the recipe is short:

1. Persist payment_method_details.card.fingerprint from every charge webhook into your payments table, with an index.
2. On each new charge, count distinct customer identifiers sharing that fingerprint in the last 30 days, and distinct fingerprints for that customer in the last 24 hours.
3. Feed both counts into whatever risk logic gates your fulfillment.

The queries are simple. The ongoing work is everything around them: choosing thresholds that do not flag families and corporate cards, weighting the signal against your other checks, building the review workflow, and maintaining it all as your volume grows. That maintenance burden is the usual reason teams eventually consolidate their homegrown checks into a scoring layer they do not have to own.

Either way, start tracking the fingerprint today. It is the one identifier in your payment flow that fraudsters cannot rotate their way around, and it has been sitting in your webhooks all along.