Stripe approved the payment. That's not the question a license-key store needs answered.

Here's a fraud scenario physical ecommerce rarely has to think about.

Someone buys a game key with a stolen card. The key is revealed instantly. Within minutes it's redeemed, or resold on a grey-market site.

Weeks later the chargeback arrives. You refund the money. You don't get the key back. No package to intercept, no return to process, no address to flag. The product left the moment the page loaded.

That's daily life for Increddy, a license-key storefront, and it's why "Stripe handles fraud" wasn't enough.

Why digital goods are a fraudster's favourite

Payment processors rank digital goods among the highest-risk categories, and the reasons stack up:

• Instant delivery. No shipping delay to catch a problem in.
• No address to verify. Nothing has to match anything.
• Instantly resellable. The value is liquid the second it's issued.
• Nothing to recover. Once the key is revealed, it's gone.

Every risk decision that matters has to happen before checkout completes. Afterwards, you're just counting losses.

What Stripe actually answers

To be clear: Stripe's fraud tooling is good, and it stays in Increddy's stack. It scores the payment (card, device, transaction pattern) against signals from across Stripe's network.

But it answers "is this payment risky?"

It doesn't answer "is this payment risky **given that the product is an instantly resellable key we can never claw back?"

Those are different questions, and a key store needs both answered.

A veto, not a footnote

The design choice that matters isn't any single fraud rule. It's where the risk check sits.

A check that runs after Stripe approves is only reacting to a decision that's already been made. So Increddy's risk scoring is a first-class Medusa module inside the checkout flow with the authority to block checkout completion on its own, whatever Stripe returned.

It gets a vote before the order exists, not a note attached to a transaction that already happened.

What we're not telling you

You might have noticed there's no list of signals or thresholds in this post. That's deliberate.

It's the same reason banks don't publish their fraud rules: a risk system works partly because the people it targets can't read the rulebook. The architecture is worth sharing. The heuristics aren't, because publishing them would make them worse at their job.

The rule

Treat fraud risk as a property of the product category, not only the payment. If what you sell is valuable the instant it's delivered and impossible to take back, give your own risk logic a real seat at checkout, with real veto power.

The fraud layer was one of several custom modules in Increddy's move off Shopify. See the full case study on kryeo.com →

The longer version of this post is on the Kryeo blog.

We're Kryeo. We build checkout and risk logic for headless stores through our Medusa development work.