Optimize fraud signals

Stripe Radar uses AI models that evaluate many signals to distinguish fraudulent and legitimate payments. It computes some signals automatically, but many depend on the data your integration sends. When you provide more relevant data, fraud prevention improves. Try to collect enough information to support accurate risk assessment without overloading your checkout experience.

Integrations and fraud signal completeness

Radar uses data from the Stripe network to detect and block fraudulent transactions across integrations. The integration you choose affects the completeness of the fraud signals you send to Stripe—the more payment data you capture, the better Radar can detect and prevent fraud.

If your integration doesn’t send enough payment data, you can add customer signals (user email, name, and billing address) to the Customer object. You can also add client signals (IP address, user agent, and checkout URL) to the PaymentIntent object.

Important signals to send to Stripe

Include the following information with your payments to improve fraud detection. Our recommended integrations automatically collect this data for you, while direct integrations typically require you to send it explicitly.

Best practices

To ensure that your conversion rate remains high while maximizing the performance of our AI models, adhere to the following best practices.

Collect advanced fraud signals

Stripe Payment Links, Checkout, Elements, and our mobile SDKs automatically collect important high-signal data, such as device information and IP addresses. If you’re not using one of our recommended payment integrations, consider using Radar Sessions to automatically collect advanced fraud signals.

Create payments using the Customer object

Use Customer objects when creating payments to let Stripe track the payment patterns for each one of your customers over time. This increases our ability to identify irregularities in purchasing behavior. To do this:

• Set up payment methods for future use and add a billing address to Customer objects, using them to create subsequent payments.
• Provide your customer’s email address when creating a Customer object.
• Provide your customer’s name when you tokenize their card information.
• Collect the customer’s shipping address, saving it to their associated Customer object if you ship physical goods.

Each Customer object can also store multiple payment methods, enhancing the checkout experience by letting your customers save multiple cards. Stripe continues to track payment patterns for each customer, regardless of which one they use.

If you’re manually creating a PaymentIntent, make sure to handle declines. If you reuse the PaymentIntent, track repeated attempts to help counter card testing.

Include Stripe.js

Include Stripe.js on every page of your site, not just the checkout page where your customer enters their payment information. This helps Stripe detect anomalous behavior as customers browse and provides additional signals that improve fraud detection.

<script async src="https://js.stripe.com/clover/stripe.js"></script>

Always load Stripe.js directly from https://js.stripe.com/clover/stripe.js. We don’t support using a local copy of Stripe.js, as it can result in user-visible errors, and reduces the effectiveness of our fraud detection.

Update your privacy policy

Radar collects information on anomalous device or user behavior that might be indicative of fraud. Make sure that your own privacy policy tells your customers about this type of collection. If your policy doesn’t include such a disclosure, consider adding the following paragraph:

We use Stripe for payment, analytics, and other business services. Stripe collects identifying information about the devices that connect to its services. Stripe uses this information to operate and improve the services it provides to us, including for fraud detection. You can learn more about Stripe and read its privacy policy at https://stripe.com/privacy.

Enable Radar for future use

Radar operates on a per-charge level, which means that during a PaymentIntent lifecycle, Radar might scan multiple charges if the payment has retries. By default, Radar doesn’t scan if you set up a Payment Method for future use without a charge. If you want to scan SetupIntents, go to your Radar settings and enable Use Radar on payment methods saved for future use.