# Issuing lifecycle controls

Learn how to use Issuing to control automatic usage-based cancellation of cards.

You can use lifecycle controls to automatically cancel a virtual card after a specified number of payments. This provides support for single-use or *n*-use cards. To enable this functionality, set the `lifecycle_controls` parameter when [creating a virtual card](https://docs.stripe.com/api/issuing/cards/create.md#create_issuing_card-lifecycle_controls).

## How it works

Set `lifecycle_controls.cancel_after.payment_count` to specify the number of payments after which you want the virtual card automatically canceled. After the card reaches this payment count, its [status](https://docs.stripe.com/api/issuing/cards/object.md#issuing_card_object-status) automatically updates to `canceled`, and all future authorizations are declined.

### What counts as a payment

The following events count towards the `payment_count`:

1. **Approved authorizations >1 USD**: Standard card transactions that are approved
1. **Captured authorizations ≤1 USD**: Small transactions (≤1 USD) that are actually captured and result in a [transaction](https://docs.stripe.com/api/issuing/transactions.md)
1. **Force posts**: When a business captures funds without an authorization

### Special handling for ≤1 USD authorizations

Many businesses use ≤1 USD authorizations to test if a card is valid, but don’t capture these authorizations to transfer funds. To prevent premature card cancellation:

- *Uncaptured* ≤1 USD authorizations don’t count towards `payment_count`
- Only up to `payment_count` uncaptured ≤1 USD authorizations are allowed

## Examples

The following scenarios demonstrate how lifecycle controls work for a single-use card (`payment_count: 1`):

Create the single-use card:

```curl
curl https://api.stripe.com/v1/issuing/cards \
  -u "<<YOUR_SECRET_KEY>>:" \
  -d currency=usd \
  -d type=virtual \
  -d "cardholder={{ISSUINGCARDHOLDER_ID}}" \
  -d "lifecycle_controls[cancel_after][payment_count]=1"
```

### Scenario 1: Standard transaction

1. A 25 USD authorization request comes in and is `declined` due to insufficient funds
1. A 10 USD authorization request comes in and is `approved`
1. The card’s status is updated to `canceled`


> The {> 
> `declined`> 
> authorization doesn’t count toward the card’s > 
> `payment_count`> 
> , because no funds can be transferred from a denied authorization.

### Scenario 2: With uncaptured ≤1 USD test authorization

1. A 1 USD authorization request comes in to verify the card’s validity and is `approved`.
1. A second 1 USD authorization request comes in but is `declined`.
1. A 15 USD authorization request comes in and is `approved`.
1. The card’s status updates to `canceled`.


> The second 1 USD authorization request is > 
> `declined`> 
> because only up to > 
> `payment_count`> 
> ≤1  USD uncaptured authorizations are allowed. 

### Scenario 3: Captured ≤1 USD authorization

1. A 1 USD authorization request comes in for an actual purchase and is `approved`.
1. The authorization is captured and clears into a transaction (the funds are transferred).
1. The card’s status updates to `canceled`.


> The 1 USD authorization only counts towards > 
> `payment_count`> 
> after it’s captured and funds are transferred, which confirms this wasn’t to a test payment.

### Scenario 4: Force post

1. A force post transaction for 5 USD comes in (no prior authorization).
1. The card’s status updates to `canceled`.

### Scenario 5: Force post after cancellation

1. A 15 USD authorization request comes in and is `approved`.
1. The card’s status updates to `canceled` because there’s now one approved authorization >1 USD.
1. A force post transaction for 5 USD comes in. According to network rules, force posts must be processed, so the 5 USD is transferred. You might need to file a dispute as two payments occurred on your single-use card.