# Pay-as-you-go abuse evaluation

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

The Radar API provides a non-payment abuse signal that can help you identify subscription customers who are unlikely to pay their next invoice. This is useful for post-paid billing models where customers accumulate usage before being charged. For example, 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

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.
A diagram showing the non-payment abuse evaluation flow for a subscription. (See full diagram at https://docs.stripe.com/radar/non-payment-abuse)
Use this endpoint for async evaluation outside of a checkout flow, such as a background worker that evaluates subscriptions mid-billing cycle. A Radar Session isn’t required—off-session subscription payments can’t generate one, 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:

```curl
curl https://api.stripe.com/v1/radar/payment_evaluations \
  -u "<<YOUR_SECRET_KEY>>:" \
  -H "Stripe-Version: 2026-02-25.preview; payment_evaluations_beta=v1" \
  -d "payment_details[amount]"=2500 \
  -d "payment_details[currency]"=usd \
  --data-urlencode "payment_details[payment_method_details][payment_method]"="pm_****" \
  -d "payment_details[money_movement_details][money_movement_type]"=card \
  -d "payment_details[money_movement_details][card][customer_presence]"=off_session \
  -d "payment_details[money_movement_details][card][payment_type]"=recurring \
  --data-urlencode "customer_details[customer]"="cus_****"
```

Stripe returns a `signals.non_payment_abuse` object in the response:

```json
{
  "id": "peval_***",
  "object": "radar.payment_evaluation",
  "created_at": 1773177872,
  "customer_details": {
    "customer": null,
    "customer_account": null,
    "email": "test@test.com",
    "name": null,
    "phone": null
  },
  "events": [],
  "insights": {
    "evaluated_at": 1773177872,
    "fraudulent_dispute": {
      "recommended_action": "continue",
      "risk_score": -1
    }
  },
  "livemode": false,
  "metadata": {},
  "outcome": null,
  "payment_details": {
    "amount": 2500,
    "currency": "usd",
    "description": null,
    "money_movement_details": {
      "money_movement_type": "card",
      "card": {
        "customer_presence": "off_session",
        "payment_type": "recurring"
      }
    },
    "payment_method_details": {
      "billing_details": null,
      "payment_method": "pm_****"
    },
    "shipping_details": null,
    "statement_descriptor": null
  },
  "signals": {
    "fraudulent_payment": {
      "evaluated_at": 1773177872,
      "risk_level": "normal",
      "score": -1
    },
    "non_payment_abuse": {
      "evaluated_at": 1773177872,
      "risk_level": "highest"
    }
  },
}
```

The `insights.fraudulent_dispute` and `signals.fraudulent_payment` fields return default values (`-1` and `continue`) because they don’t apply to the subscription invoice use case. 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:

```curl
curl -G https://api.stripe.com/v1/subscriptions/{{SUBSCRIPTION_ID}} \
  -u "<<YOUR_SECRET_KEY>>:" \
  -d "expand[]"=customer
```

Get the invoice amount:

```bash
curl -G https://api.stripe.com/v1/invoices/upcoming \
  -u "sk_test_26PHem9AhJZvU623DfE1x4sd:" \
  -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. |

## Outcome labeling

No outcome reporting is required for this use case. When the subscription invoice is eventually charged, it follows the standard Stripe payment processing flow and updates the Radar model automatically.

## Test mode

- In test mode, `signals.non_payment_abuse.data.risk_level` returns a default stub `risk_level` of `normal`.

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