Pay-as-you-go abuse evaluationPrivate 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.

Request to join the preview for the pay-as-you-go abuse signal.

Enter your email to request access.

How it works

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

Use the Payment Evaluation endpoint for evaluation outside of a checkout flow, such as a background worker that evaluates subscriptions mid-billing cycle. A Radar Session isn’t required, so the client_device_metadata_details field is optional for this use case.

Create a payment evaluation

To request a non-payment abuse risk level, you need a payment method, customer, and the expected invoice amount. Call POST /v1/radar/payment_evaluations with the money_movement_details set to indicate a recurring off-session charge:

Stripe returns a signals.non_payment_abuse object in the response:

{
  "id": "peval_***",
  "object": "radar.payment_evaluation",
  "created_at": 1773177872,
  "livemode": false,
  "metadata": {},
  "recommended_action": "continue",
  "signals": {
    "fraudulent_payment": {
      "evaluated_at": 1773177872,
      "risk_level": "not_assessed",
      "score": -1.0
    },
    "non_payment_abuse": {
      "evaluated_at": 1773177872,
      "risk_level": "highest"
    }
  }
}

The signals.fraudulent_payment fields return default values (-1.0 for scores) because they don’t apply to the subscription invoice use case. The recommended_action field is at the evaluation level, not the signal level, so its value reflects the overall evaluation outcome and won’t always be continue. Use signals.non_payment_abuse.risk_level for your evaluation logic.

Retrieve payment details from a subscription

If you’re evaluating a Stripe Billing subscription, you can retrieve the necessary inputs by fetching the subscription and upcoming invoice.

Retrieve the payment method and customer from the subscription:

Get the invoice amount:

Command Line
curl -G https://api.stripe.com/v1/invoices/upcoming \
  -u "{{SECRET_KEY}}:" \
  -d "customer={{CUSTOMER_ID}}" \
  -d "subscription={{SUBSCRIPTION_ID}}"

Use default_payment_method from the subscription (or alternatively customer.invoice_settings.default_payment_method) and amount_due from the upcoming invoice.

Risk levels

Value	Description
`normal`	This level is low risk. No action is required.
`elevated`	This level is moderate risk. Consider manual review or usage limits.
`highest`	This level is high risk. Consider pausing usage or requiring prepayment.
`low`	This level is low risk. No action is required.
`not_assessed`	This signal wasn’t assessed.
`unknown`	The risk level is unknown.

Outcome labeling

No outcome or event reporting is required for this use case.

Sandbox behavior

In a sandbox, signals.non_payment_abuse.risk_level returns a simulated risk_level that can vary based on the input data. To test a specific risk level, use the following test payment method:

Payment method	Card number	Risk level
`pm_card_riskLevelHighest`		`highest`

For more test payment methods, see fraud prevention testing.

API behavior

This endpoint is fail-open. A 4xx or 5xx response from Stripe won’t affect your subscription or billing flow. You can retry the call or proceed without the signal.