Why Stripe flags AI companies as "high-risk" — the 6 signals decoded.

We've helped 14 AI companies through Stripe risk reviews since 2024. In every single case, one or more of six signals was the trigger. None of those signals actually indicated fraud. All of them indicated "business that looks unfamiliar to a model trained on 2018 SaaS."

This essay is the long version of which signals matter, what threshold they likely trip at, and the specific fix for each. Read this whether your Stripe account is fine today or already showing the early indicators.

What "high-risk" means inside Stripe

Stripe doesn't use a single "high-risk" flag. Internally there are several scores: a fraud risk score (per transaction), a merchant risk score (per account), a chargeback risk score, a content/compliance score. The account-level state you see externally (reserve, payout delay, pause) is the output of these scores crossing thresholds.

The model is mostly automated. A human reviewer is involved only when the automated decision exceeds a confidence threshold or when an account appeals. By the time a human is looking at you, the system has already decided you're a problem; the review is generally to confirm, not to reconsider.

The six signals below are what trip the automated scores. Each one has a fix that moves you below the threshold without changing what your business actually does.

The six signals

1. MRR volatility

Stripe's model treats sudden weekly revenue spikes as a fraud signal. The underlying assumption: legitimate SaaS revenue grows steadily; fraud spikes when a ring is testing cards. A 4× weekly spike — completely normal for AI products after a Product Hunt launch, a viral tweet, or a Reddit feature — looks identical to the bad-actor pattern.

The threshold we've inferred from cases:

• Weekly volume increases of > 3.5× sustained over 14 days triggers a soft flag.
• Daily transaction count increases of > 5× in 24 hours triggers a hard flag.

The fix:

• Notify Stripe Risk proactively before a launch you expect to spike. There's no formal channel for this but a dashboard support ticket explicitly flagging an upcoming spike helps.
• Stage the spike if possible — invite-only or waitlist roll-outs avoid the cliff edge.
• If you're already past the threshold, send Risk a one-pager with the launch source, expected duration, and a forecast — they'll usually back off if the data is in writing.

2. International card mix

Stripe's baseline fraud model treats non-issuer-country cards as elevated risk. For a US-domiciled merchant, every Brazilian card, Indian card, Nigerian card, and Philippine card adds to the risk score. Some BIN ranges (especially in countries with high payment-fraud rates in 2018-era data) are scored harder than others.

Threshold patterns we see:

• > 35% of transactions on non-US, non-EU, non-UK, non-CA, non-AU cards raises baseline merchant score.
• > 20% on cards from a single high-risk BIN country triggers a deeper review.

The fix:

• Use Stripe Radar rules to require 3DS / SCA on cards from elevated-risk BINs. This both reduces actual fraud and tells Stripe's model you're managing the risk.
• Add explicit billing-country verification at checkout (AVS for US/UK, postal-code match elsewhere).
• Split international volume across two processors. International to a second processor or MoR reduces concentration on Stripe.

3. Chargeback and fraud rate

The visible threshold is 1% disputes / 0.5% fraud (Stripe's published policy limit). The functional threshold where reserves get added is lower:

• > 0.7% dispute rate over 60 days → reserves likely added.
• > 0.4% fraud-coded dispute rate over 60 days → reserves with payout delay.

The fix:

• Submit evidence for every dispute. Even on disputes you expect to lose. Stripe's model looks at your evidence-submission rate, not just your win rate. Submitting auto-generated evidence packets is better than nothing.
• Add a clear refund policy to your checkout. Reduces "I didn't recognise this" disputes.
• Explicitly preview the first charge amount in welcome emails. Reduces "I didn't expect this" disputes 5-10 days into a paid plan.
• If you're past 0.5% disputes, the cleanup is hard — usually involves moving consumer volume to a different processor while you tighten up.

4. Descriptor mismatch

The descriptor on the credit card statement should match what the customer remembers signing up for. Mismatches trigger "I didn't recognise this charge" disputes, which Stripe codes as fraud (the worst category for your risk score).

Common patterns we've seen trip this:

• Product name "PromptCo" but descriptor "PROMPT LABS INC."
• Marketing brand "Atria" but descriptor "ATR HOLDINGS" (the parent LLC).
• Trial signup that says "You won't be charged" but charges $1 for card validation under your business name.

The fix:

• Set the dynamic descriptor in Stripe to your product name, not your legal entity name.
• Limit to 22 characters (more is truncated on most card statements).
• Don't use abbreviations the customer wouldn't recognise.
• Test it by making a $1 charge on your own card and looking at how it appears on the statement.

5. Content adjacency

This is the signal most specific to AI companies. If your product cangenerate content in adult, violent, political, financial-advice, or pharmaceutical categories — even if your customers don't typically generate it — Stripe's content compliance team treats the business as operating in that category.

Triggers we've seen:

• Image generation models tagged as "adult-capable" in regulatory filings.
• Voice cloning products flagged as potentially deceptive (deepfake-adjacent).
• LLM products that don't have explicit safety filters surfaced in product copy.

The fix:

• Add explicit safety policy language to your marketing site, not just internal docs. The compliance team looks at the public-facing description.
• Reference your content moderation pipeline (which models, which providers, which categories).
• For image/voice models specifically, publish a usage policy and a takedown process.

6. Refund rate spike

High refund rate is itself a risk signal — Stripe's model reads it as "the merchant is unable to deliver what they sold." A 30-day refund rate above ~3% on a consumer SaaS is unusual; above 5% is a flag.

Refund spikes most often follow:

• A pricing change customers didn't expect.
• A model downgrade (you swapped GPT-4 for GPT-3.5 silently to save margin; customers noticed).
• A bug that delivered degraded results for a few days.

The fix:

• Announce any price/model change ahead of the billing cycle. Two-week notice minimum.
• If you're refunding because of a bug, refund proactively via a single batch instead of letting customers initiate; the batch refund counts cleaner in Stripe's model than a wave of customer-initiated requests.
• Communicate downtime / degradation publicly (status page). Customers who see the status page are less likely to refund.

Defusing each signal in 30 days

A realistic 30-day plan if you're currently showing one or more of these signals but haven't been paused yet:

We were 12 hours from a Stripe pause when we shipped a Radar rule that filtered out a single BIN range that was generating 60% of our chargebacks. Two weeks later, Stripe upgraded us to a lower reserve. The rule was 8 lines of code.— Helena Park, COO, Pact Labs

If you're already in a pause and reading this, our companion piece on the 72-hour recovery playbook walks the next steps. The piece on what specifically happens to your funds during the hold is here.