How subscriptions work
Manage recurring payments and subscription lifecycles.
With Subscriptions, customers make recurring payments for access to a product. Subscriptions require you to retain more information about your customers than one-time purchases because you need to charge them in the future.
Stripe offers many features that help you manage subscription billing:
- Support for different pricing models
- Subscription discount management
- Trial management
- Prorations for modified subscriptions
- Customer self-service management
- Invoicing to collect payments
- Automated revenue recovery
- Reporting and analytics
The subscription lifecycle 
This is what the recommended subscription flow looks like:
Create the subscription. The
status
of the subscription isincomplete
if you follow these steps. If you create a subscription without specifying thepayment_
, the defaultbehavior status
isactive
.Stripe automatically creates an invoice with the
open
status for the subscription.The customer pays the first invoice.
When the payment succeeds:
- The subscription
status
moves toactive
- The invoice
status
is set topaid
- Stripe sends an
invoice.
event to your configured webhook endpointspaid
- The subscription
You provision access to your product. To confirm whether the invoice has been paid:
- Set up a webhook endpoint or another type of event destination and listen for the
invoice.
event.paid - Manually check the subscription object and look for
subscription.
. Thestatus=active status
becomesactive
when the invoice has been paid either through an automatic charge or having the customer pay manually.
- Set up a webhook endpoint or another type of event destination and listen for the
The status
changes to trialing
if you offer trials that don’t require payments. When the trial is over, the subscription moves to active
and the subscribed customer starts to be charged.
Subscription payment behavior 
To simplify handling failed payments, create subscriptions with payment_
set to default_incomplete. This creates subscriptions with status incomplete
, which allows you to collect and confirm payment information in a single user interface. When using allow_
or error_
, Stripe immediately attempts to pay the invoice. If the payment fails, the subscription’s status changes to incomplete
or the creation fails.
Note
Asynchronous payment methods, such as ACH Direct Debit, handle subscription status transitions differently than immediate payment methods. When you use asynchronous methods, subscriptions transition directly to an active
state upon creation, bypassing the incomplete
state typically associated with other payment types. If an asynchronous payment fails later, it voids the associated invoice; however, the subscription remains in the active
state. This behavior contrasts with immediate payment methods, where failed payments often lead to incomplete
or past_
states. Be aware of this distinction and implement appropriate logic to manage subscription status, access control, and payment retry mechanisms.
Successful payments 
When your customer successfully pays the invoice, the subscription updates to active
, and the invoice updates to paid
. At this point, you can provision access to your product.
Payment window 
Customers have about 23 hours to make a successful payment. The subscription remains in the incomplete
status and the invoice is open
during this time. If your customer pays the invoice, the subscription updates to active
and the invoice updates to paid
. If they don’t make a payment, the subscription updates to incomplete_
and the invoice becomes void
.
This timeframe exists because your customer usually makes the first payment for a subscription while on-session. If the customer returns to your application after 23 hours, create a new subscription for them.
Failed payments 
The subscription’s status remains active
as long as automatic payments succeed. If automatic payment fails, the subscription updates to past_
and Stripe attempts to recover payment based on your retry rules. If payment recovery fails, you can set the subscription status to canceled
, unpaid
, or leave it past_
.
Unpaid subscriptions 
For subscriptions with unpaid invoices, the unpaid invoices remain open but further payment attempts are paused. The subscription continues to generate invoices each billing cycle, which remain in the draft
state. To reactivate the subscription:
Collect new payment information if necessary.
Enable automatic collection by setting auto_advance to
true
on draft invoices.Finalize and pay the open invoices. Paying the most recent non-voided invoice before its due date updates the subscription status to
active
.
Invoices marked as uncollectable are treated as paid
when determining subscription status, even though their paid property remains false
. Stripe ignores voided invoices when determining subscription status; the most recent non-voided invoice is used instead.
The status
of an unpaid subscription is based on your failed payment settings in the Dashboard.
Cancel subscriptions 
If you cancel a subscription, it disables creating new invoices and stops automatic collection of all invoices from the subscription because it sets auto_
to false
. It also deletes the subscription and you can no longer update the subscription or its metadata. If your customer wants to resubscribe, you need to collect new payment information from them and create a new subscription.
Change subscriptions 
Stripe supports modifying existing subscriptions without having to cancel and recreate them. Some of the most significant changes you might make are upgrading or downgrading the subscription price, or canceling or pausing payment collection for an active subscription. Learn more about how to change existing subscriptions.
Manage Checkout Sessions 
For Stripe Checkout integrations, you can’t update the subscription or its invoice if the session’s subscription is incomplete
. You can listen to the checkout.session.completed event to make the update after the session has completed.
You can also expire the session instead if you want to cancel the session’s subscription, void the subscription invoice, or mark the invoice as uncollectible.
Integration example 
This section describes our sample integration on GitHub, which illustrates how to build a subscriptions integration. If you’re ready to build your own integration, see the Billing quickstart or integration guide.
Landing page 
On your frontend, the landing page collects the email address first. Your application might have other customer-specific information you want to collect like a username or address. Clicking the signup button sends the information collected on the landing page to your backend. This process creates a customer and displays the pricing page on your frontend.
Pricing page 
The pricing page displays your subscription options based on the products and prices you create when you first set up your integration, meaning you don’t need to create new ones every time customers sign up. Your pricing page displays the prices you created, and your customers choose the option they want. The example on GitHub displays a payment form when a customer selects an option. Learn more about products and prices.
Payment 
The payment form collects a name and card information. Stripe hosts this form if you use Checkout. It’s one of the key features that allows you to collect payments and remain PCI compliant. Clicking Subscribe:
- Creates a new subscription with your customer and price IDs.
- Generates an invoice for your initial subscription cycle.
- Collects payment details and pays your invoice.
- Sets the payment method as the default payment method for the subscription-a requirement for subsequent payments.
Make sure to confirm payment before provisioning access for your customer.
To implement this:
- Accept payments without code: If you don’t want to write any code, learn how to create a Payment Link and share it with your customers.
- Build a checkout page: Use the Checkout Sessions API to accept payments through a hosted page, an embedded form on your site, or a customized checkout page built with embedded components.
- Advanced integration: Use Stripe Elements to collect payment details and activate the subscription with the Payment Element.
Provisioning 
Use Entitlements to determine when you can grant or revoke product feature access to your customers. Alternatively, after a successful payment, you can safely provision the product for the customer. This generally means:
- Verifying the status of the subscription is
active
. - Granting the customer access to the products and features they subscribed to.
Learn how to use event destinations to:
How payments work with subscriptions 
To simplify the handling of failed payments and to create subscriptions before attempting payment:
Pass payment_behavior=default_incomplete when creating a subscription. If your subscription requires payment, it’s created with an
incomplete
status, otherwise your subscription immediately becomesactive
.Activate an incomplete subscription by paying the first invoice.
Pass the payment intent identifier from the invoice to your user interface to collect payment information and confirm the payment intent. You can use Elements, the Android SDK, or the iOS SDK.
Note
Subscriptions created in the Dashboard default to payment_
if you don’t use the Oxxo, Konbini, or Boleto payment methods. If the initial payment fails due to 3D Secure Authentication, you can create the subscription with payment_
instead.
Recurring charges 
Stripe handles recurring charges for you automatically. This includes:
- Automatically invoicing customers and attempting payments when new billing cycles start.
- When payments fail, Stripe retries them using the Smart Retries feature or your custom retry schedule. This automatically re-attempts payment according to your Dashboard settings when cards are declined. If a failure returns a hard decline code, the scheduled retries continue but the payment executes only if you obtain a new payment method.
You can send a dunning email to customers for overdue payments to increase recovery chances. For payments that require 3D Secure, you can configure your billing settings to send a hosted link to customers so they can complete the flow.
Payment status 
The payment process differs across payment methods and geographical locations. Payments can also fail initially (for example, a customer might enter the wrong card number or have insufficient funds), so various payment outcomes are possible.
A PaymentIntent tracks the lifecycle of every payment. Whenever a payment is due for a subscription, Stripe generates an invoice and a PaymentIntent. The PaymentIntent ID attaches to the invoice and you can access it from the Invoice and Subscription objects. The state of the PaymentIntent affects the state of the invoice and the subscription. Here’s how the different outcomes of a payment map to the different statuses:
Payment outcome | PaymentIntent status | Invoice status | Subscription status |
---|---|---|---|
Success | succeeded | paid | active |
Fails because of a card error | requires_ | open | incomplete |
Fails because of authentication | requires_ | open | incomplete |
The following sections explain these statuses and the actions to take for each.
Payment succeeded 
When your payment succeeds, the status of the PaymentIntent is succeeded
, and the subscription becomes active
. For payment methods with longer processing periods, subscriptions are immediately activated. In these cases, the status of the PaymentIntent may be processing
for an active
subscription until the payment succeeds.
With your subscription now activated, provision access to your product. Read the guide to learn more about the subscription lifecycle and best practices for provisioning.
Response | Subscription | PaymentIntent |
---|---|---|
| active | succeeded |
Requires payment method 
If payment fails because of a card error, such as a decline, the status of the PaymentIntent is requires_
and the subscription is incomplete
.
Response | Subscription | PaymentIntent |
---|---|---|
| incomplete | requires_payment_method |
To resolve these scenarios:
- Notify the customer.
- Collect new payment information and confirm the payment intent.
- Update the default payment method on the subscription.
Learn how to handle payment failures for subscriptions.
Requires action 
Some payment methods require customer authentication with 3D Secure (3DS) to complete the payment process. If you use the Payment Intents API, the status
value of the PaymentIntent is requires_
when a customer needs to authenticate a payment. You can get the PaymentIntent on the Invoice Payment resource either by expanding latest_
or by specifying the invoice parameter with Invoice Payment list. 3DS completes the authentication process. Whether a payment method requires authentication depends on your Radar rules and the issuing bank for the card.
Regulations in Europe often require 3D Secure. See Strong Customer Authentication to determine whether handling this status is important for your business. If you have an existing billing integration and want to add support for this flow, also see the Billing SCA Migration guide.
Response | Subscription | PaymentIntent |
---|---|---|
| incomplete | requires_action |
To handle these scenarios:
- Monitor for the
invoice.
event notification with webhook endpoints. This indicates that authentication is required.payment_ action_ required - Notify your customer that they must authenticate.
- Retrieve the client secret for the payment intent and pass it in a call to stripe.ConfirmCardPayment. This displays an authentication modal to your customers, attempts payment, then closes the modal and returns context to your application.
- Monitor the
invoice.
event on your event destination to verify that the payment succeeded. Users can leave your application beforepaid confirmCardPayment()
finishes. Verifying whether the payment succeeded allows you to correctly provision your product.
Subscription statuses 
Status | Description |
---|---|
trialing | The subscription is currently in a trial period and you can safely provision your product for your customer. The subscription transitions automatically to active when a customer makes the first payment. |
active | The subscription is in good standing. For past_ subscriptions, paying the latest associated invoice or marking it uncollectible transitions the subscription to active . Note that active doesn’t indicate that all outstanding invoices associated with the subscription have been paid. You can leave other outstanding invoices open for payment, mark them as uncollectible, or void them as you see fit. |
incomplete | The customer must make a successful payment within 23 hours to activate the subscription. Or the payment requires action, such as customer authentication. Subscriptions can also be incomplete if there’s a pending payment and the PaymentIntent status is processing . |
incomplete_ | The initial payment on the subscription failed and the customer didn’t make a successful payment within 23 hours of subscription creation. These subscriptions don’t bill customers. This status exists so you can track customers that failed to activate their subscriptions. |
past_ | Payment on the latest finalized invoice either failed or wasn’t attempted. The subscription continues to create invoices. Your subscription settings determine the subscription’s next state. If the invoice is still unpaid after all attempted smart retries, you can configure the subscription to move to canceled , unpaid , or leave it as past_ . To reactivate the subscription, have your customer pay the most recent invoice. The subscription status becomes active regardless of whether the payment is done before or after the latest invoice due date. |
canceled | The subscription was canceled. During cancellation, automatic collection for all unpaid invoices is disabled (auto_ ). This is a terminal state that can’t be updated. |
unpaid | The latest invoice hasn’t been paid but the subscription remains in place. The latest invoice remains open and invoices continue to generate, but payments aren’t attempted. Revoke access to your product when the subscription is unpaid because payments were already attempted and retried while past_ . To move the subscription to active , pay the most recent invoice before its due date. |
paused | The subscription has ended its trial period without a default payment method and the trial_settings.end_behavior.missing_payment_method is set to pause . Invoices are no longer created for the subscription. After attaching a default payment method to the customer, you can resume the subscription. |
Subscription settings and recovery 
Your subscription settings determine how Stripe responds when payments fail or when subscriptions become past due.
Smart Retries 
After you create a subscription, payment failure is the most important event that can happen. Failures can occur for many reasons:
- Lack of a payment method on the customer.
- The payment method is expired.
- The payment is declined.
You can configure Stripe to retry failed payments for up to two months in Manage failed payments for subscriptions in the Dashboard. Smart Retries uses AI to pick the optimal time for retries over the configured period.
You can also modify the retry schedule with custom rules. You can configure up to three retries, each with a specific number of days after the previous attempt.
You can use the invoice.payment_failed event to monitor subscription payment failure events and retry attempt updates. After a payment attempt on an invoice, its next_payment_attempt value is set using the current subscription settings in your Dashboard.
Warning
When using automations, the next_payment_attempt is no longer set in invoice.
webhooks but is set in invoice.
webhooks.
If recovery fails, the subscription transitions according to your settings. The options are:
Setting | Description |
---|---|
Cancel the subscription | The subscription changes to a canceled state after the maximum number of days defined in the retry schedule. |
Mark the subscription as unpaid | The subscription changes to an unpaid state after the maximum number of days defined in the retry schedule. Invoices continue to be generated and stay in a draft state. |
Leave the subscription past-due | The subscription remains in a past_ state after the maximum number of days defined in the retry schedule. Invoices continue to be generated and charge customer based on retry settings. |
After the final payment attempt, we make no further payment attempts. Changing your subscription settings only affects future retries.
Emails 
Stripe can optionally send different emails to customers, using the email addresses associated with the Customer object:
- An upcoming renewal reminder at the same time that we send the
invoice.
event for subscriptions set up to collect payment automatically.upcoming - A failed payment notification prompting customers to update their payment information. Learn how to turn on failed payment notifications.
- An expiring card notification when a customer’s
default_
card is due to expire.source
You can customize the logos and colors your customers see in emails, and our Hosted Invoice Payment page by changing the branding settings in the Dashboard.
Trials 
Card networks require you to inform your customers about their trials. Stripe can manage this communication for you. In the Dashboard, you can configure the cancellation URL that’s included on both the reminder emails and on the receipt for the first invoice after a trial ends. You can also configure the statement descriptor for the first charge after a trial. Learn more about these requirements and settings on the trials page.
Subscription objects 
Use the following core API resources to build and manage subscriptions:
Resource | Definition |
---|---|
Customer | Represents a customer who purchases a subscription. Use the Customer object associated with a subscription to make and track recurring charges and to manage the products that they subscribe to. |
Entitlement | Represents a customer’s access to a feature included in a service product that they subscribe to. When you create a subscription for a customer’s recurring purchase of a product, an active entitlement is automatically created for each feature associated with that product. When a customer accesses your services, use their active entitlements to enable the features included in their subscription. |
Feature | Represents a function or ability that your customers can access when they subscribe to a service product. You can include features in a product by creating ProductFeatures. |
Invoice | A statement of amounts a customer owes that tracks payment statuses from draft through paid or otherwise finalized. Subscriptions automatically generate invoices. |
PaymentIntent | A way to build dynamic payment flows. A PaymentIntent tracks the lifecycle of a customer checkout flow and triggers additional authentication steps when required by regulatory mandates, custom Radar fraud rules, or redirect-based payment methods. Invoices automatically create PaymentIntents. |
PaymentMethod | A customer’s payment methods that they use to pay for your products. For example, you can store a credit card on a Customer object and use it to make recurring payments for that customer. Typically used with the Payment Intents or Setup Intents APIs. |
Price | Defines the unit price, currency, and billing cycle for a product. |
Product | A good or service that your business sells. A service product can include one or more features. |
ProductFeature | Represents a single feature’s inclusion in a single product. Each product is associated with a ProductFeature for each feature that it includes, and each feature is associated with a ProductFeature for each product that includes it. |
Subscription | Represents a customer’s scheduled recurring purchase of a product. Use a subscription to collect payments and provide repeated delivery of or continuous access to a product. |
Here’s an example of how products, features, and entitlements work together. Imagine that you want to set up a subscription service that offers two tiers: a standard product with basic functionality, and an advanced product that adds extended functionality.
- You create two features:
basic_
andfeatures extended_
.features - You create two products:
standard_
andproduct advanced_
.product - For the standard product, you create one ProductFeature that associates
basic_
withfeatures standard_
.product - For the advanced product, you create two ProductFeatures: one that associates
basic_
withfeatures advanced_
and one that associatesproduct extended_
withfeatures advanced_
.product
A customer, first_
, subscribes to the standard product. When you create the subscription, Stripe automatically creates an Entitlement that associates first_
with basic_
.
Another customer, second_
, subscribes to the advanced product. When you create the Subscription, Stripe automatically creates two Entitlements: one that associates second_
with basic_
, and one that associates second_
with extended_
.
You can determine which features to provision for a customer by retrieving their active entitlements or listening to the Active Entitlement Summary event. You don’t have to retrieve their subscriptions, products, and features.
Subscription events 
Events are triggered every time a subscription is created or changed. We send some events immediately when a subscription is created, while others recur on regular billing intervals. We recommend listening for events with webhook endpoints.
Make sure that your integration properly handles the events. For example, you might want to email a customer if a payment fails or revoke a customer’s access when a subscription is canceled.
See Subscription events for a list of the most common subscription-related events and, where applicable, suggested actions for handling the events.