# Reduce subscription fraud and nonpayment risk

Configure subscription updates, credits, payment recovery, and access controls to reduce fraud and nonpayment risk.

Your business model affects how you handle subscription changes, credit prorations, and customer provisioning after failed payments. The following settings and integration recommendations can help you reduce opportunities for abuse, such as credits for unpaid service or continued unpaid access. When choosing these controls, consider how to balance nonpayment risk with giving legitimate customers time to resolve payment issues.

## Before you begin

For help building your subscriptions integration, see the [Build a subscriptions integration guide](https://docs.stripe.com/billing/subscriptions/build-subscriptions.md).

## Require outstanding invoices to be settled before restoring access

Your application can use the subscription’s status to decide when to grant or restore access to your product. We recommend using the `All invoices` setting for subscription status resolution if you want to ensure customers pay all their invoices. This prevents a subscription from becoming `active` while an applicable outstanding invoice remains. With the default `Most recent invoice` setting, paying a later invoice can restore `active` status even if older invoices remain unpaid.

With the `All invoices` setting, when your application receives an `invoice.paid` event, we recommend checking that the subscription is `active` before restoring access. Your application can revoke access for `unpaid` or `canceled` subscriptions and allow a grace period for `past_due` subscriptions.

Read [Configure subscription status resolution](https://docs.stripe.com/billing/subscriptions/overview.md#subscription-status-resolution) for configuration instructions and the rules for which invoices affect status. For event handling, see the [Subscription webhooks guide](https://docs.stripe.com/billing/subscriptions/webhooks.md). Verify webhook signatures before acting on events, as described in the [Webhook verification guide](https://docs.stripe.com/webhooks.md#verify-events).

## Require payment before applying subscription changes

For subscription changes that require payment, such as upgrades or quantity increases, we recommend pending updates. For supported updates that generate an invoice, you can set `payment_behavior` to `pending_if_incomplete` to keep the change pending if payment fails. For changes that create prorations, Stripe invoices those prorations and attempts payment immediately when you set `proration_behavior` to `always_invoice`.

Waiting until the update is applied before applying changes helps prevent customers from receiving upgraded access without paying.

Before integrating, read the [Pending updates guide](https://docs.stripe.com/billing/subscriptions/pending-updates.md) for configuration instructions, supported changes and payment methods, and expiration behavior.

## Avoid crediting unpaid service

Consider enabling credit proration deferral to prevent credits associated with unpaid debits from being applied to other invoices. When enabled, Stripe holds credit proration invoice items in a pending state until the original debit invoice is paid. After it’s paid, the credit becomes eligible and is included on the customer’s next invoice.

This account-level setting complements pending updates by addressing credits generated against unpaid invoices, including renewal invoices. Before enabling it, read the [Defer credit prorations guide](https://docs.stripe.com/billing/subscriptions/credit-proration-deferral.md) for configuration instructions, limitations, and customer impact.

When canceling a delinquent subscription, we recommend setting `prorate` to `false`. See the [Cancel a subscription API reference](https://docs.stripe.com/api/subscriptions/cancel.md) for parameter details and cancellation behavior.

## Limit exposure after payment failures

We recommend reviewing your retry schedule, the action taken after retries end, and your application’s access policy together. A longer retry window gives customers more time to resolve payment issues, but can also extend unpaid usage if you continue providing access throughout that window.

A final action such as canceling the subscription or marking it `unpaid` can help define when your application stops providing access. If you leave subscriptions `past_due`, consider how your application limits continued unpaid usage. Read the [Automate payment retries guide](https://docs.stripe.com/billing/revenue-recovery/smart-retries.md) to review retry options, final actions, and payment-method restrictions. You can configure this in your [Dashboard failed payment settings](https://dashboard.stripe.com/settings/billing/subscriptions#manage-failed-payments).

You can also pause eligible flexible-mode subscriptions after the first renewal payment failure or after retries finish. Your application can then suspend access when the subscription becomes `paused`. See the [Pause subscriptions after payment failure guide](https://docs.stripe.com/billing/revenue-recovery/smart-retries/pause-on-payment-failure.md) for eligibility, billing effects, and resumption behavior.

## Act earlier on high-risk usage

For services billed after use, including usage-based subscriptions, see [Radar pay-as-you-go abuse evaluations](https://docs.stripe.com/radar/pay-as-you-go-abuse.md) to assess nonpayment risk as customers use your service and learn about integration requirements. Evaluating the expected invoice amount before the billing cycle ends can help you act before payment fails. Possible responses include reviewing the account, issuing an early invoice, requiring prepayment, or limiting usage.

To automate action after a failed invoice payment, consider Workflows with a [custom action](https://docs.stripe.com/workflows/custom-actions.md) that evaluates Radar’s `non_payment_abuse` signal and applies your chosen response before the retry window ends. For example, a high-risk signal can trigger subscription cancellation. Your application then restricts access according to your policy.

See the [Workflows guide](https://docs.stripe.com/workflows.md) to learn how triggers and actions fit together.

If you offer free trials, see the [Free trial abuse prevention guide](https://docs.stripe.com/radar/free-trial-abuse.md) for controls that apply at signup, before usage has accrued and an invoice amount is available.