Public preview

Pay-as-you-go abuse evaluation Public preview

Learn how to identify subscription customers at risk of service abuse by not paying their next invoice.

The Radar API provides a pay-as-you-go abuse signal that can help you identify subscription customers who are likely to abuse the platform by intentionally not paying their next invoice. Use this signal for post-paid billing models where customers accumulate usage before being charged. For example, use it for usage-based services that bill at the end of the month.

Use this signal to manually review high-risk accounts, issue an early invoice, or limit product access before a billing cycle ends.

How it works

To receive a non-payment abuse risk signal, simulate a future invoice payment instead of evaluating a payment at checkout. The risk signal indicates whether the customer’s upcoming invoice is at risk of abuse.

Use the Create a Billing Evaluation endpoint to evaluate subscriptions outside of a checkout flow, such as from a background worker during a billing cycle.

When to evaluate a customer

Non-payment abuse risk changes throughout a customer’s billing lifecycle. The signal becomes more accurate as you learn more about the invoice amount and payment method. You can predict non-payment at three points in the lifecycle, each requiring a different control.

The signal is most accurate when payment_details.amount is close to the final invoice amount. Instead of evaluating risk only at the beginning of a billing cycle, re-evaluate it as usage accrues and pass the latest projected amount each time.

Create a billing evaluation

To request a non-payment abuse risk level, provide a tokenised card payment method, customer reference or inline customer attributes and an expected invoice amount.

Identify the customer using exactly one of the following fields:

• customer _ details. customer : Pass a Customer ID.
• customer _ details. customer _ account : Pass the ID of a customer-configured Account .
• customer _ details. data : Pass the customer’s attributes inline if the customer isn’t represented by a Customer or an Account.

These fields are mutually exclusive, and every request must include one of them.

An email address is also required. If you pass customer_details.data, include data.email. If you reference a Customer or an Account, the referenced object must have an email address. Otherwise, the request returns a 400 error.

Command Line

cURL

Stripe returns a signals.non_payment_abuse object in the response:

{
 "id": "beval_***",
 "object": "radar.billing_evaluation",
 "created_at": 1704067200,
 "livemode": true,
 "metadata": {},
 "signals": {
 "non_payment_abuse": {
 "evaluated_at": 1704067200,
 "risk_level": "normal"
 }
 }
}

The response includes only the non_payment_abuse signal. Use signals.non_payment_abuse.risk_level in your evaluation logic.

Retrieve payment details from a subscription

To evaluate a Stripe Billing subscription, retrieve the required inputs from the subscription and its upcoming invoice.

First, retrieve the payment method and customer from the subscription:

Command Line

Select a language

cURL

Stripe CLI

Ruby

Python

PHP

Java

Node.js

Go

.NET

No results

Get the invoice amount:

Command Line

Use the subscription’s default_payment_method, or the customer’s invoice_settings.default_payment_method), and amount_due from the upcoming invoice.

Risk levels

Sandbox behaviour

In a sandbox, the following test cards return a predefined signals.non_payment_abuse.risk_level. Pass a test PaymentMethod ID in payment_details.payment_method_details.payment_method, or create a PaymentMethod using one of the card numbers and pass the resulting pm_... ID.

All other test cards, including those listed on the fraud prevention testing page, return a risk_level of not_assessed.

API behaviour

This endpoint fails open. A 4xx or 5xx response from Stripe doesn’t affect your subscription or billing flow. You can retry the request or proceed without the risk signal.