This One Stripe Field Could Save You from Fraud (And No One Talks About It)

You’re getting new signups. Growth looks good. Everything seems fine… until it isn’t.

A few weeks in, the support tickets start. Refund requests. Chargebacks. Confusing logins from different countries. It feels like something’s off, but it’s hard to tell exactly what. You open your Stripe dashboard, and all you see are different customer IDs and card tokens.

But what if they’re not as different as they look?

Stripe has a hidden field that links everything together. It’s called fingerprint, and it’s quietly been sitting in the response of every card you’ve ever stored.

Most developers ignore it. You shouldn’t.

How One Card Can Be Used to Exploit You

Let’s walk through a simple scenario.

Someone signs up for your SaaS product. They start a free trial. After 14 days, the trial ends.

A day later, you get a new signup. New email. New customer ID in Stripe. But this time, it’s the same credit card.

Then they do it again. And again.

Different emails, different accounts, but same card.

If you’re not tracking it, you’d never know. It looks like 10 new users, when it’s actually one person gaming your system.

This is incredibly common for abuse cases:

• Free trial abuse
• Discount code reuse
• Fake churn and reactivation behavior
• Even coordinated refund fraud

The good news is: Stripe knows when it’s the same card. The fingerprint field gives it away.

What Is Stripe’s fingerprint Field?

Every time you add a card to a customer using Stripe, they generate a fingerprint. This value uniquely identifies the underlying card number. Not the token. Not the customer. Just the number.

So even if someone creates a new Stripe customer, or uses a different card token, the fingerprint stays the same if the card number is the same.

Here’s what a card object might look like:

{
  "id": "card_1Nc0sF...",
  "brand": "Visa",
  "last4": "4242",
  "fingerprint": "Xt5EWLLDS7FJjR1c"
}

You can find this field:

• Under card.fingerprint when using the PaymentMethod API
• Or under sources.data[].fingerprint if you’re still using the older Sources API

Reference: Stripe Card API Docs

This value is persistent. If two customers have cards with the same fingerprint, they’re using the same card.

Using Fingerprint to Detect Abuse

Here’s how you can start catching this kind of behavior with minimal effort.

1. Save the fingerprint when a user adds a card

When a user signs up or adds a payment method, fetch the card’s fingerprint from Stripe and store it in your database.

If you’re using Prisma, this might look like:

const card = await stripe.customers.createSource(customerId, { source: token });

await prisma.user.update({
  where: { id: userId },
  data: {
    cardFingerprint: card.fingerprint
  }
});

2. On new cards, check for duplicates

Whenever a new card is added, look up other users with the same fingerprint.

const duplicates = await prisma.user.findMany({
  where: {
    cardFingerprint: card.fingerprint,
    NOT: { id: userId }
  }
});

if (duplicates.length > 0) {
  console.warn('Duplicate card detected');
  // Optional: trigger alert, flag for manual review, block signup
}

That’s it. You now have a simple system to detect if the same card is being used across multiple accounts.

Real-World Example: What We Found

In our own product, we noticed a pattern. A bunch of new signups coming from the same region, using our free trial. Then a week later, more signups. Same pattern. Different emails.

Chargebacks followed. Support requests increased. Something didn’t add up.

We pulled the fingerprints for each card and discovered that over 12 accounts had been created using the exact same card. The emails were fake and the names were randomized, yet the card was revealed through Stripe.

Once we added a check for duplicates, trial abuse dropped off completely.

What You Can Do With This

The fingerprint field can be used for more than just catching free trial abuse.

Here are a few ideas:

• Stop duplicate trials Only allow one trial per card fingerprint. If someone tries to sign up again with the same card, block it or require payment.

• Detect shared accounts If you notice multiple users with the same fingerprint but very different usage patterns or IPs, it could be someone reselling your product access.

• Group risky behavior Track chargebacks, support issues, or suspicious logins by fingerprint and catch clusters of abuse.

• Flag edge cases for review Build a queue of users with shared fingerprints and let your support or risk team manually review them.

Building a Simple Dashboard

If you’re running a product at any sort of scale, consider surfacing this data internally.

Here’s how to build a quick report using Prisma to find fingerprints used by multiple accounts:

const suspiciousCards = await prisma.user.groupBy({
  by: ['cardFingerprint'],
  _count: { cardFingerprint: true },
  having: {
    cardFingerprint: {
      _count: { gt: 1 }
    }
  }
});

You can then build a table showing:

• The fingerprint
• Associated emails
• Number of linked accounts
• Signup dates
• Country/IP metadata (if you track it)

Even just glancing at it once a week can help spot patterns early.

Caveats and Limitations

The fingerprint field is powerful, but it’s not perfect.

• Apple Pay and Google Pay: When users pay with tokenized methods like Apple Pay, Stripe may only give you a tokenized number that changes every time. In some cases, this means no consistent fingerprint.

• Shared cards aren’t always abuse: A team might use the same company card for multiple employees. A couple might share a card across two accounts. Use the fingerprint as a signal, not a strict rule.

• Doesn’t detect all fraud: Sophisticated attackers may still find workarounds, or use new cards for every account. This won’t catch everything, but it catches a lot.

Final Thoughts

Stripe gives you more than just payment processing. It gives you tools to understand your users and protect your business. The fingerprint field is one of those tools. It’s sitting there quietly in the API. All you have to do is use it.

If you’re building a product and care about improving visibility into user behavior, you might also want to check out UserJot. It helps you collect user feedback, organize it publicly or privately, and close the loop with changelogs and roadmaps. Simple, useful, and built for teams who care about building the right thing.