Stripe Radar vs RequestGuard: when to use both

Stripe Radar and RequestGuard solve different parts of the fraud timeline.

Stripe Radar protects the payment. RequestGuard protects the path to payment. That distinction matters when the risky event happens before the card is charged: fake accounts, trial abuse, coupon abuse, card testing preparation, suspicious devices, and high-risk digital fulfillment.

What Stripe Radar is good at

Stripe Radar is strongest inside the Stripe payment flow. It can use Stripe payment and network context to help detect risky transactions and support payment-specific fraud workflows.

If your only fraud problem is payment authorization inside Stripe, Radar may be enough.

What RequestGuard adds

RequestGuard runs before you create a Checkout Session. It scores IP, email, domain, device, user, session, and behavior context so your backend can decide whether the session should reach payment at all.

That lets you:

• Block obvious abuse before payment infrastructure is touched.
• Challenge uncertain users before Checkout Session creation.
• Review digital goods and subscription risk before fulfillment.
• Store a RequestGuard request ID with the order or customer.

Recommended flow

const assessment = await requestGuard.assess({
  ip,
  email,
  userAgent,
  event: "checkout",
  metadata: { cart_total: total, coupon },
});

if (assessment.decision !== "allow") {
  return requireVerification(assessment.request_id);
}

// Continue to Stripe only after the pre-checkout risk gate passes.

When to use both

Use RequestGuard before checkout when abuse starts in your product. Keep Stripe Radar active during payment authorization.

This gives you two boundaries: one for the account/session path and one for payment authorization. The result is cleaner than forcing one tool to cover every stage.

Bottom line

RequestGuard is not a full replacement for Stripe Radar. It is the earlier fraud layer. If your risk starts before payment, add a pre-checkout decision before Stripe enters the flow.