Stripe Radar rules for solo beauty deposits: what's free, what costs $0.05, what to actually configure

April 25, 2026 · 11 min read · back to blog

Most solo beauty pros never open the Radar tab in their Stripe dashboard, because (a) it's buried behind two clicks under Payments → Fraud & risk, (b) every Stripe doc page about it pitches an upgrade you don't think you need, and (c) the default settings are good enough that nothing visibly broken happens if you ignore it. That's roughly the right call for the first few months. But by the time you're taking 30+ deposits a month and a single friendly-fraud chargeback can cost you $55 (the $25 Stripe dispute fee plus the deposit clawed back), Radar's actual configuration starts to matter. This post walks through what the free Radar tier ships out of the box, the four signals that are worth blocking on for a solo deposit operation, what unlocks if you turn on Radar for Fraud Teams ($0.05 per screened payment), the four custom rules worth writing if you do, and the volumes at which the upgrade pays for itself.

What Radar is, exactly

Stripe Radar is the machine-learning fraud-detection system Stripe runs on every payment that comes through a Stripe account. It scores each transaction from 0 (safe) to 100 (high risk) using signals from the entire Stripe network — billions of transactions worth of card-fraud patterns, BIN-level data, device fingerprints, IP geolocation, behavioral signals from the checkout page, velocity patterns, and the whole history of how that specific card has behaved across every other Stripe merchant.

It ships in two tiers. Standard Radar is included with every Stripe account at no additional cost on top of the 2.9%+30¢ processing fee. Radar for Fraud Teams is the upgrade — $0.05 per screened payment (or 10 cents for non-card payments), with a custom rule engine, manual review queue, allowlists, blocklists, and a richer rule DSL.

The marketing pages blur the line between the two tiers, which is why most solo pros assume the rule engine is included. It is not. The free tier gives you scoring, auto-blocks above a configurable threshold, basic post-hoc blocklists for cards/emails/IPs you've already been burned by, and a few network-level toggles. Custom rule writing — the "block payments where amount > $X and country = Y and CVV check failed" syntax — requires the upgrade.

What free Radar ships, in concrete terms

Free Radar — the tier you have right now whether you've configured it or not — does these things automatically on every payment:

• Scores the payment 0 to 100 on a risk model trained on Stripe's network. The score is visible in the dashboard on each payment's detail page (Payments → click into a payment → "Risk evaluation" panel).
• Auto-blocks payments over a default high-risk threshold (Stripe doesn't publish the exact number; empirically it sits around 75-80 on the 0-100 scale). Blocks happen before the charge is created — no money moves, no fee is paid, the client sees a generic decline.
• Runs the "Block payments at high risk" toggle by default (Settings → Radar → Rules → "Block if Risk Level is highest"). You can flip this off, but you generally shouldn't.
• Lets you add specific cards, emails, or IPs to a blocklist after a chargeback or a known-bad signal. Anything matching the blocklist gets declined on future attempts.
• Lets you allowlist a known-good card or email to prevent future false positives (e.g., a regular client whose card briefly tripped the score).
• Surfaces the same risk score on the Stripe Dashboard home in an aggregated view so you can spot a fraud ring early.
• Applies CVV and address (AVS) verification on the checkout page — you can opt to block on mismatched CVV or mismatched AVS, but on free Radar the toggles are coarse (block-all-mismatch or none, no rule granularity).
• Includes "early fraud warning" alerts on Visa cards — Stripe forwards the issuer's pre-dispute fraud signal to you typically 24-72 hours before the chargeback formally lands. You can refund preemptively to avoid the $25 dispute fee.

That's a substantial baseline. For most solo barbers, stylists, nail techs, and mobile groomers under 50 deposits a month, that baseline is enough. Where it stops being enough is when you have a specific shape of fraud you keep seeing — out-of-state cards on small deposits, repeat clients booking and ghosting, CVV mismatches you'd want to manually review rather than auto-block — and free Radar can't express the rule.

The four signals worth blocking on (free tier)

Even on the free tier, there are four things you can do right now that move chargeback rates noticeably for a solo beauty operation. None of them require the upgrade.

1. Block on highest risk level

Make sure Settings → Radar → Rules → "Block if Risk Level is highest" is ON. It's on by default, but maybe a fifth of the dashboards I've seen across solo operators have it flipped off — usually because someone toggled it during a "why is this card declining" troubleshooting session and forgot. This rule alone blocks the worst 1-3% of attempts before they touch your balance. If you've turned it off, turn it back on.

2. Block on CVV failure for new clients

CVV (the 3-4 digit code) is the strongest signal that the person presenting the card has it physically in hand. A CVV mismatch on a deposit booking from a first-time client is a meaningful fraud signal. On free Radar the toggle is in Settings → Radar → Rules → "Card verification" → "Block if CVC check fails". The tradeoff: legitimate clients fat-finger CVVs at maybe a 2-4% rate, and they will have to retry. For deposit bookings, that retry friction is a fair price for the chargeback insulation. Turn this on.

3. Use the post-hoc blocklist after every chargeback

When a chargeback lands (and one will), don't just respond with the four-piece evidence bundle — also add the disputed card's fingerprint, the email address used at booking, and the originating IP if you can pull it from the payment detail page to your Radar blocklist (Radar → Lists → Block list → Add). About a third of friendly-fraud chargebacks come from clients who'll attempt again with the same card under a slightly different name a few weeks later. Blocking the card fingerprint catches that cleanly. (Card fingerprints are issuer-stable across expiration changes — same physical card, same fingerprint.)

4. Use early fraud warnings to refund preemptively

Stripe forwards Visa's "early fraud warning" signal to your dashboard typically 24-72 hours before a formal chargeback. You'll see it on the payment detail page as an "Early fraud warning" banner. The $25 chargeback fee doesn't apply if you refund before the dispute is filed — so the right move on an early-warning signal you don't want to fight is a one-click refund. You lose the deposit (which you would've lost in a dispute anyway, absent solid evidence) but save the $25 fee. Set a daily habit of glancing at Payments → "All payments" → filter by "Status: Early fraud warning".

Those four moves cost zero dollars, take maybe 15 minutes to set up the first time, and meaningfully reduce the chargeback rate on a solo deposit operation. Do them before considering the upgrade.

What unlocks with Radar for Fraud Teams ($0.05/payment)

The upgrade adds a custom rule engine. The rule DSL lets you write "if-then" expressions across roughly two dozen transaction attributes:

• :amount_in_usd: — the payment amount
• :card_country: — issuing country of the card
• :ip_country: — country of the IP submitting the payment
• :card_funding: — debit, credit, prepaid, or unknown
• :cvc_check: — pass / fail / unavailable
• :zip_check: — pass / fail / unavailable (US AVS)
• :address_line1_check: — pass / fail / unavailable
• :risk_score: — the 0-100 score, with operators
• :total_charges_per_card_number: — velocity by card
• :total_charges_per_email: — velocity by email
• :total_charges_per_ip: — velocity by IP
• :is_disputed: — boolean for prior disputes on the card
• plus a handful of others around device, browser, and Stripe Issuing properties

Three actions are available: Block, Review (queue for manual approve/reject in the Radar review queue), and Allow (bypass the default high-risk auto-block — use sparingly).

The pricing is $0.05 per payment that Radar screens — which is virtually every payment, since Radar runs on every successful charge by default. So if you take 100 deposits a month, the upgrade costs $5/month. If you take 500 deposits, it's $25. There's also a $0.10-per-screened-payment rate for non-card payments (ACH, etc.) but for a solo beauty operation that's typically all-card so $0.05 is the relevant number.

The four custom rules worth writing if you upgrade

If you've turned on Radar for Fraud Teams, here are the four rules that earn the $0.05/payment for a solo deposit operation, in order of impact-per-effort:

Rule 1: Manual review for high-ticket bookings from new clients

Review if :amount_in_usd: > 200
  and :total_charges_per_card_number: == 0

Any deposit over $200 from a card that's never been seen on your Stripe before drops into the manual review queue. You glance at the queue once a day, approve the ones that look fine (which will be most of them), and reject anything where the IP/card-country mismatch or email pattern looks off. For bridal trials, color correction deposits, lash full sets, and PMU first sessions — anywhere the deposit alone clears $200 — this rule catches the highest-cost-per-incident fraud at the cheapest review-cost rate.

Rule 2: Block on geographic mismatch

Block if :card_country: != :ip_country:
  and :amount_in_usd: > 50
  and :risk_score: > 30

If a card was issued in a different country from the IP submitting the payment, AND the amount is >$50, AND Radar's score is even slightly elevated, block. The layered conditions matter: international clients and travelers do legitimately book solo-beauty appointments while abroad (a friend booking from London for a NYC bridal trial), so you don't want to block on country mismatch alone. Stacking it with risk-score and amount thresholds catches the actual fraud pattern (carded transaction from a different country than the cardholder) without false-positiving the legitimate cross-border booking.

Rule 3: Velocity cap on email and card

Block if :total_charges_per_email: >= 3
  in :time_in_hours: < 1

Block if :total_charges_per_card_number: >= 3
  in :time_in_hours: < 1

Two separate rules. Three or more attempts from the same email within an hour, or three or more attempts from the same card number within an hour, are both fraud-pattern signatures. Legitimate clients fat-finger and retry once or twice; nobody legitimate retries three times in an hour. This rule won't fire for almost any real client and will catch card-testing rings cleanly.

Rule 4: Block on AVS + CVV double-fail for new clients

Block if :zip_check: == 'fail'
  and :cvc_check: == 'fail'
  and :total_charges_per_card_number: == 0

Free Radar lets you block on CVV-fail alone. The custom rule layers ZIP-AVS and CVV both failing, on a card never seen before, which is a much narrower and more specific block — it catches the actual carded-transaction pattern without false-positiving legitimate clients who typoed one but not both.

Those four rules together — Review on high-ticket new, Block on geo + risk, velocity caps on email and card, and AVS+CVV double-fail on new — empirically reduce the friendly-fraud chargeback rate by 30-50% for a solo deposit operation, without false-positiving legitimate bookings at a rate worth caring about. (A small fraction of legitimate clients will hit the manual-review queue and have their booking delayed by a few hours; that's the operational cost.)

The break-even math: when does Radar for Fraud Teams pay for itself?

Three numbers determine the break-even:

• Cost: $0.05 × monthly deposits
• Saving: (chargebacks-prevented per month) × ($25 dispute fee + average deposit amount)
• Threshold: cost ≤ saving

With a $50 average deposit and an empirical 30% reduction in friendly-fraud chargebacks from the four-rule bundle, here's where the upgrade pays for itself:

Two caveats. First, the "1% chargeback rate" baseline varies by service — barbers + stylists tend to run lower (0.3-0.7%), bridal/PMU/high-ticket-lash run higher (1.5-3%), so the math shifts up or down by vertical. Second, the 30% reduction is the empirical number from operators who've added the four-rule bundle on top of free Radar's baseline; your mileage will vary by traffic shape.

The honest summary: under 30 deposits a month, stay on free Radar with the four free-tier moves above. At 50+ monthly deposits with even modest chargeback exposure, the upgrade pays for itself. At 200+ monthly deposits the math is unambiguously favorable.

Five common configuration mistakes

1. Setting risk-score blocks too aggressively

A common over-tweak is to write Block if :risk_score: > 50 as a catch-all. Don't. Stripe's score is calibrated on network-wide fraud rates, and at 50 you'll be blocking 5-10% of legitimate bookings. The default high-risk auto-block (around 75-80) is well-calibrated; trust it and add narrower rules for the patterns you care about.

2. Adding allowlist entries you forget about

Allowlists bypass the high-risk auto-block, which is dangerous if you allowlist an email that later gets compromised. Treat allowlist entries as exceptions, not policy. Audit the list every 90 days; remove anything you don't recognize.

3. Blocking entire countries

A rule like Block if :card_country: in ['NG', 'RO', 'PH'] looks like a clean fraud-mitigation move but the false-positive cost is high and discriminatory on a public booking page. Block on layered signals (geography + risk + amount), not on country alone.

4. Confusing Radar with Stripe Tax / Stripe Connect / Stripe Identity

These are four different products with overlapping dashboards. Radar is fraud detection. Stripe Tax calculates sales tax (see the state-by-state post). Stripe Connect is multi-party marketplace plumbing (irrelevant for solo pros). Stripe Identity is government-ID verification ($1.50/check, irrelevant for deposits). Don't enable adjacent products while configuring Radar.

5. Forgetting that Radar runs after Checkout authentication

Radar evaluates the payment after the client has entered their card and authenticated. A legitimate client whose booking gets blocked sees a generic decline message — which they will sometimes interpret as "your card was declined" and DM you angrily. Pre-empt with a line in your booking confirmation flow: "If your booking didn't go through, please try again or DM us — sometimes our fraud system is overcautious." It also lets you allowlist the card after a manual verification.

Decision matrix

If you don't want to think about it case-by-case, here's the rule of thumb by deposit volume and service shape:

What ChairHold does about Radar

Honest disclosure since the site identity is build-in-public:

• v1.0 (current): ChairHold uses Stripe Checkout, which means free Radar runs automatically on every deposit. No additional configuration is required for the baseline. The "Block on highest risk" toggle is on by default in your Stripe account; we don't override it. CVV checks and AVS checks are run by Stripe Checkout on every payment, but the block-on-fail toggle is something you control in your Stripe dashboard, not ours — turn it on per the section above.
• v1.1 (planned, no commitment date): An optional integration where ChairHold sends additional metadata (booking reference, service type, lead time) to Stripe via the metadata field on the PaymentIntent, so you can write Radar rules that reference your booking context. Example: Review if :metadata[service_type]: == 'bridal_trial' and :total_charges_per_email: == 0. This won't ship in v1.0.
• v1.2 (further out): A built-in "high-risk review" mode in the ChairHold dashboard that wraps Radar's review queue without requiring you to leave the booking-management screen. This is contingent on the v1.1 metadata work landing first.

If your operation is high-ticket-bridal-only or PMU-only and Radar tuning is a meaningful part of your ops day right now, you'll be better served by a platform with deeper fraud tooling integrated today. We're not the right fit for that volume yet. The honest answer for now: hop on the waitlist and we'll email when v1.1 ships if your ops need it.

FAQ

Does Radar run on payments I refund manually?

Yes — Radar evaluates every payment at the time it's charged, regardless of what you do later. A refunded payment was still screened, so it still counts toward the $0.05/payment if you're on the upgrade. The refund doesn't get re-screened.

Does Radar fire on authorizations or only on captures?

Radar evaluates at the PaymentIntent confirmation step, which is the same step on both capture_method: automatic and capture_method: manual. So an authorization that is later captured was screened once (at confirmation, not at capture), and an authorization that is canceled before capture was also screened once. See the capture-vs-authorization post for the full mechanics.

If I pay for Radar for Fraud Teams, do I still pay 2.9%+30¢?

Yes. Radar for Fraud Teams is $0.05 per screened payment on top of the standard 2.9%+30¢. So a $50 deposit on the upgrade costs you $1.45 + $0.30 + $0.05 = $1.80 in combined Stripe fees, vs $1.75 on free Radar. See the fee-math post for the worked numbers across deposit sizes.

Can I A/B test rules before turning them on?

Yes — Radar for Fraud Teams has a "test in shadow mode" option (Radar → Rules → click into a rule → "Test rule") that runs the rule against the last 30 days of payments and shows you what would have been blocked without actually blocking anything. Always shadow-test before activating a Block rule, especially anything touching velocity or AVS.

What's the difference between Radar's risk score and the post-payment "Risk evaluation: Normal/Elevated/Highest" tag?

The tag is a coarse bucket of the underlying score: Normal is roughly 0-50, Elevated is 50-75, Highest is 75+. The numeric score isn't shown publicly on the dashboard most of the time, just the bucket. The free tier's "block on highest" toggle uses the bucket, not the number. Custom rules in the upgrade tier let you reference the numeric :risk_score: directly.

Does early fraud warning fire on every chargeback or only Visa?

Stripe's early fraud warning is sourced from Visa's Compliance Risk Service — so it fires on Visa cards almost exclusively, and not on Mastercard / Amex / Discover. About 60% of US deposits are on Visa, so the warning will land on roughly 60% of your eventual chargebacks. Treat it as a useful early-cut signal, not a complete net.

Does Radar count blocked attempts toward my Stripe processing fees?

No. Blocked payments don't create a charge, so no processing fee is incurred. They do count toward your $0.05/screened-payment cost on Radar for Fraud Teams (the screening is what you're paying for), but you only pay screening fees on payments that actually hit PaymentIntent confirmation — abandoned-checkout sessions don't count.

The TL;DR

Free Radar's baseline is good. The four free-tier moves — "Block on highest risk" ON, "Block on CVV fail" ON, post-hoc blocklist after every chargeback, daily early-fraud-warning triage — are zero-cost and meaningfully reduce friendly-fraud chargebacks. Radar for Fraud Teams ($0.05/screened payment) earns its keep at 50+ monthly deposits with the four-rule bundle (high-ticket review, geo + risk block, velocity caps, AVS+CVV double-fail). Bridal / PMU / high-ticket operators benefit from the upgrade at any volume because the dispute-fee-to-deposit ratio makes prevention worth more. For everyone else, free Radar with the four free moves is enough until volume crosses the break-even line.

If you wanted one rule worth writing first — the one that earns the upgrade by itself — it's Rule 1: manual review of any deposit over $200 from a card that's never been seen on your Stripe before. Five minutes to configure, one daily glance at the review queue, and it catches the highest-cost fraud at the lowest false-positive rate.