The Customer Evaluation API provides risk intelligence for your registration and login flows to detect multi-accounting patterns and suspicious account sharing:

No payment collection required: Evaluate risk during registration and at login, before collecting any payment information.
Get risk scores upfunnel: Apply decision signals earlier in your workflow to get risk scores sooner (login or registration) than traditional Stripe PaymentIntents. This can help you make informed decisions about allowing or blocking account access where service abuse is suspected.

Multi-account abuse

The multi_accounting signal identifies whether a single fraudulent actor is registering multiple accounts to abuse your service.

The account_sharing signal identifies whether a single user account is being used simultaneously in multiple locations.

Request to join the preview for multi-account and account sharing abuse signals.

Enter your email to request access.

Customer evaluation lifecycle

To request a customer evaluation to detect abuse:

On the client side, use Stripe.js to create a Radar Session that captures device metadata, then send the session token to your server.
Create a customer (or use an existing Customer object). You can also pass user-identifying information directly instead of a customer ID. For more details, see Entityless evaluations.
Request a CustomerEvaluation when customers register or log in.
After the customer registers or logs in, report the outcome to Stripe to improve future evaluations.

The following diagram shows the high-level interactions between you (the business), Stripe, and your end customer at registration time.

Create a Radar Session

Before requesting a customer evaluation, you must capture device metadata from the client using Stripe.js. Pass the Radar Sessions token from the response to your server to use it in the Customer Evaluation request.

Note

Radar Sessions expire shortly after creationcreate the session as close to submitting the evaluation as possible to avoid a timeout.

If session creation fails or times out

If stripe.createRadarSession() fails or times out (for example, due to an ad blocker or network error), you can still request an evaluation by passing the users IP address using client_details.data instead of client_details.radar_session. You can also include user_agent and referrer to improve signal quality. For referrer, use document.referrer from the client if available.

An IP-only evaluation produces less accurate scores than a full Radar Session because it lacks device-level signals. When possible, resolve the root cause of session creation failures rather than relying on this fallback long-term. See Radar Session troubleshooting for more information.

Create a CustomerEvaluation

After you create a Radar Session to capture device metadata, request a CustomerEvaluation to get risk signals from Stripe.

Registration flow

Use the registration event type to evaluate new user registrations. You can reference an existing Customer. To ensure accurate fraud detection, preserve the customer ID to use in future payment requests.

Use the login event type to evaluate user login attempts and detect account sharing patterns. Use the same customer ID that you created during registration.

Risk signals

Stripe returns risk signals in the response based on the evaluation type. Use these signals to make informed decisions about allowing or blocking the action.

Evaluation type	Signal returned	Description
`registration`	`multi_accounting`	Risk that the same end customer is registering multiple times
`login`	`account_sharing`	Risk that the same account is being used from multiple locations simultaneously

Score interpretation

Each signal returns a score from 0 to 100 and a corresponding risk_level that categorizes the score into a qualitative band. Use the risk_level to make quick decisions, or use the raw score for fine-grained control.

Risk level	Score range	Description
`highest`	75-100	Indicates a high risk of abuse. Consider blocking or requiring additional verification.
`elevated`	6574	Indicates an elevated risk of abuse. Consider applying additional friction or review.
`normal`	064	Indicates typical risk. No additional action recommended.

Entityless evaluations

If you cant create a Customer object for your architecture at registration time, pass user-identifying information in customer_details.customer_data instead of customer_details.customer.

Note

Use the Customer object whenever possible. It helps Stripe make more accurate risk assessments over time.

In customer_details, provide a customer_data object instead of a customer ID. Include as many of the following fields as possible. Providing more identifiers improves the accuracy of the evaluation.

Field	Type	Description
`customer_data.email`	String (optional)	The customers email address.
`customer_data.name`	String (optional)	The customers name.
`customer_data.phone`	String (optional)	The customers phone number.

Example of entityless registration flow

Report outcome

After you act on a customer evaluation, report the outcome back to Stripe so we can improve future evaluations for your account.

Call the report endpoint with the status parameter to indicate the action you took:

Status values

Status	When to use	Example
`allowed`	You allowed the registration or login to proceed without restrictions.	A user registers and receives full access to your platform.
`restricted`	You allowed the registration or login to proceed, but applied restrictions based on the risk signal.	A new account gains access but receives fewer promotional credits, is placed on a probationary tier, or has limited access to certain features until additional verification.
`blocked`	You blocked the registration or login entirely. The user wasnt granted access.	A registration attempt is rejected outright, and the user cant create an account.

Reporting outcomes trains Stripes models to better distinguish abusive from legitimate behavior on your platform.

Test your integration

Use the following test email addresses in your evaluation requests to simulate specific risk scores in test mode:

Email address	Risk level	Score
`high_scoring_email@example.com`	`highest`	80
`elevated_scoring_email@example.com`	`elevated`	65
`normal_scoring_email@example.com`	`normal`	20

Reuse the customer at the time of payment

When creating payments, you must use the same customer ID that you used for the customer evaluation. This helps with providing accurate risk assessments by connecting registration, login, and payment activity for the same customer.

Note

The customer parameter at the time of payment must match the customer ID used when creating the CustomerEvaluation.

Was this page helpful?

Yes No

Need help? Contact Support.
Chat with Stripe developers on Discord.
Check out our changelog.
Questions? Contact Sales.
LLM? Read llms.txt.
Powered by Markdoc

On this page

Multi-account and account sharing abuse evaluationPrivate preview

Get risk evaluations for customer account registration and login events.

Multi-account abuse

Account sharing abuse

Customer evaluation lifecycle

Create a Radar Session

Note

If session creation fails or times out

Create a CustomerEvaluation

Registration flow

Login flow

Risk signals

Score interpretation

Entityless evaluations

Note

Example of entityless registration flow

Report outcome

Status values

Test your integration

Reuse the customer at the time of payment

Note