# Multi-account and account sharing abuse evaluation

Get risk evaluations for customer account registration and login events.

The [Customer Evaluation API](https://docs.stripe.com/api/radar/customer-evaluation.md) 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.

### Account sharing abuse 

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

## Customer evaluation lifecycle

To request a customer evaluation to detect abuse:

1. On the client side, use [Stripe.js](https://docs.stripe.com/sdks/stripejs-react.md) to create a [Radar Session](https://docs.stripe.com/radar/radar-session.md) that captures device metadata, then send the session token to your server.
2. [Create a customer](https://docs.stripe.com/api/customers/create.md) (or use an existing `Customer` object).
3. Request a `CustomerEvaluation` when customers register or log in.
4. 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.
A diagram showing the Customer Evaluation API sequence of interactions for a registration flow. (See full diagram at https://docs.stripe.com/radar/multi-account-and-account-sharing-abuse)
## Create a Radar Session

Before requesting a customer evaluation, you must capture device metadata from the client using Stripe.js. Pass the [Radar Sessions](https://docs.stripe.com/radar/radar-session.md) token from the response to your server to use it in the Customer Evaluation request.

> Radar Sessions expire shortly after creation—create 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 user’s IP address using `client_details.data` instead of `client_details.radar_session`. You can also include `user_agent` and `referrer` to improve signal quality.

```curl
curl https://api.stripe.com/v1/radar/customer_evaluations \
  -u "<<YOUR_SECRET_KEY>>:" \
  -H "Stripe-Version: 2026-03-04.preview" \
  -d event_type=registration \
  -d "evaluation_context[0][type]=customer_details" \
  --data-urlencode "evaluation_context[0][customer_details][customer]=cus_****" \
  -d "evaluation_context[1][type]=client_details" \
  -d "evaluation_context[1][client_details][data][ip]=203.0.113.42" \
  --data-urlencode "evaluation_context[1][client_details][data][user_agent]=Mozilla/5.0 ..." \
  --data-urlencode "evaluation_context[1][client_details][data][referrer]=https://example.com/signup"
```

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](https://docs.stripe.com/radar/radar-session.md) for more information.

## Create a CustomerEvaluation

After you create a [Radar Session](https://docs.stripe.com/radar/radar-session.md) to capture device metadata, request a [CustomerEvaluation](https://docs.stripe.com/api/radar/customer-evaluation/create.md) 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.

```curl
curl https://api.stripe.com/v1/radar/customer_evaluations \
  -u "<<YOUR_SECRET_KEY>>:" \
  -H "Stripe-Version: 2026-03-04.preview" \
  -d event_type=registration \
  -d "evaluation_context[0][type]=customer_details" \
  --data-urlencode "evaluation_context[0][customer_details][customer]=cus_****" \
  -d "evaluation_context[1][type]=client_details" \
  --data-urlencode "evaluation_context[1][client_details][radar_session]=rse_****"
```

### Login flow

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.

```curl
curl https://api.stripe.com/v1/radar/customer_evaluations \
  -u "<<YOUR_SECRET_KEY>>:" \
  -H "Stripe-Version: 2026-03-04.preview" \
  -d event_type=login \
  -d "evaluation_context[0][type]=customer_details" \
  --data-urlencode "evaluation_context[0][customer_details][customer]=cus_****" \
  -d "evaluation_context[1][type]=client_details" \
  --data-urlencode "evaluation_context[1][client_details][radar_session]=rse_****"
```

### 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` | 65–74 | Indicates an elevated risk of abuse. Consider applying additional friction or review. |
| `normal` | 0–64 | Indicates typical risk. No additional action recommended. |

## 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:

```curl
curl https://api.stripe.com/v1/radar/customer_evaluations/cuseval_abc123/report \
  -u "<<YOUR_SECRET_KEY>>:" \
  -H "Stripe-Version: 2026-05-27.preview" \
  -d status=blocked
```

### 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 wasn’t granted access. | A registration attempt is rejected outright, and the user can’t create an account. |

The `status` parameter is optional. If you omit it, Stripe records the evaluation with no specific outcome.

Reporting outcomes, especially for evaluations where you took action, trains Stripe’s 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.

```curl
curl https://api.stripe.com/v1/payment_intents \
  -u "<<YOUR_SECRET_KEY>>:" \
  -H "Stripe-Version: 2026-03-04.preview" \
  -d amount=1000 \
  -d currency=usd \
  --data-urlencode "customer=cus_****" \
  --data-urlencode "payment_method=pm_****" \
  -d confirm=true
```

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