Risk factors recommendations

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

Integrations and risk factor 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 risk factors 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 risk factors (user email, name, and billing address) to the Customer object. You can also add client risk factors (IP address, user agent, and checkout URL) to the PaymentIntent object.

Important risk factors 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 make sure that your conversion rate remains high while maximizing the performance of our AI models, adhere to the following best practices.

Collect advanced risk factors

Stripe Payment Links, Checkout, Elements, and our mobile SDKs automatically collect important high-risk factor 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 risk factors.

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 payment 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 flow by letting your customers save multiple payment methods. Stripe continues to track payment patterns for each customer, regardless of which one they use. This cross-payment-method history can help with detecting fraud, even when a customer switches to a different payment method.

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 risk factors that can help improve fraud detection.

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

Always load Stripe.js directly from https://js.stripe.com/dahlia/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.