Stripe Radar and a checkout captcha do different jobs

A store owner on Stripe asks a fair question. Stripe already has Radar, so why add a captcha to checkout? Another owner asks the reverse. The captcha is on, so is Radar still doing anything?

Both questions treat the two tools as rivals. They are not. They look at different things, at different moments, and they stop different kinds of harm.

Where each one sits in the request

Follow one checkout submission from start to finish. The shopper's browser posts the form to your WordPress site. WooCommerce validates it, creates the order, and hands payment to the Stripe gateway plugin. That plugin talks to Stripe, Stripe runs the charge through Radar, and the card network asks the bank.

A checkout captcha runs on your server, early in that chain, before the gateway is called. Radar runs inside Stripe, after your site has already decided to attempt the payment. That one difference explains almost everything else.

What Radar is good at

Radar scores the payment itself. It sees the card, the amount, the device and network signals Stripe collects through its own scripts, and patterns across a very large number of merchants. A card that was used for fraud somewhere else on the Stripe network can look risky to Radar the first time it reaches your store.

That makes Radar strong at the question it was built for: is this card, used this way, likely to end in fraud or a dispute? It can block the charge, send it to manual review, or let it through, and on some plans you can write your own rules.

Stripe also runs its own card-testing detection. When it sees a run against your account, it can start declining attempts on its side.

What Radar does not see

Radar only sees what reaches Stripe. It does not know whether the request came from a real browser that loaded your checkout page, or from a script that posts straight to the checkout endpoint a thousand times.

By the time Radar blocks a test, the attempt already happened. Your site built an order, the gateway made an API call, and the attempt counts in the data your provider keeps about your account. Radar reduces the damage. It does not stop the traffic from arriving.

Radar also has nothing to say about orders that never touch Stripe. If the bot picks cash on delivery, bank transfer, or another gateway, Radar is not involved.

What a checkout captcha is good at

A captcha asks a different question: is this request coming from a person using a real browser on my checkout page? reCAPTCHA v3 answers with a score based on how the page was loaded and used, without showing a puzzle.

Because it runs before the gateway call, a low score can reject the request with no order created and no charge attempted. That is the cheapest possible place to stop a scripted run. The attacker gets a generic error and learns nothing about whether the card is live.

What a captcha does not see

A captcha knows nothing about the card. A real person with a stolen card, typing it into your checkout by hand, will pass a bot check easily. That is ordinary payment fraud, and it is Radar's job.

Captchas can also be beaten. Solver services and real-browser automation can earn passing scores, especially against a loose threshold. A captcha raises the cost of an attack. It does not make one impossible.

The overlap, and the gap

• A bot posting stolen cards from a script: the captcha should stop it before Stripe sees it. Radar catches some of what gets past.
• A bot driving a real browser well enough to pass the captcha: Radar and Stripe's own card-testing checks become the main line.
• A person using a stolen card by hand: the captcha passes them. Radar is the tool for this.
• A bot using a non-Stripe payment method: Radar never sees it. Only checks on your own site apply.

Each tool covers a case the other misses. That is the reason to run both.

Practical settings

Keep Radar on with its default rules unless you have a clear reason to change them. If your Stripe plan allows custom rules, consider blocking or reviewing payments where the CVC or postal code check fails, since card testers often guess those.

On the captcha side, cover every route an order can enter, not only the main checkout form. The Checkout block, pay-for-order links, and the add-payment-method page in My Account can all reach Stripe. A bot will find the one you missed.

Then watch both logs during the first busy week. If Radar starts flagging fewer test attempts after the captcha goes live, the captcha is doing its part.

Where Checkout Bouncer fits

Checkout Bouncer is the site-side half. It scores every order route with reCAPTCHA v3 before the gateway is called, and it works with Stripe or any other gateway. It does not replace Radar, and we do not suggest turning Radar off.