The subscription lifecycle

Paddle handles all aspects of subscription management throughout a subscription's lifetime - notifying your platform (via webhooks) about key events so you can ensure that access to your product or service is always synchronized with the customer's subscription status:

lifecycle with trial - customer  b.png

In this guide, we aim to help you understand how Paddle manages the different phases in the lifecycle of a subscription.

customer buys subscription flow.png

A new subscription is created when a customer goes through your integrated Paddle checkout and completes one of the following actions:

  • Pays for a new subscription successfully.
  • Provides payment details for a trial, which are verified successfully.

When a successful payment is made for a new subscription (or payment details for a trial are verified), Paddle fires two alerts to your configured webhook:

  • subscription_payment_succeeded. Includes an initial_payment property. For new subscriptions, this is always set to 1.
  • subscription_created. Includes a subscription_id property - a unique ID for this customer's subscription. Also includes links to hosted Paddle pages (cancel_url and update_url) which the customer can use to update their payment details or cancel the subscription if you choose to make these links available.
  • Your backend system should permit the appropriate level of access to the purchased product/service for the customer (triggered by information received from Paddle via webhooks).

  • The customer's subscription is set to a status of active or trialing, where:

Active Status SubscriptionsTrialing Status Subscriptions
Rebilled by Paddle, automatically.Can be canceled by either the customer or the seller at any time before the trial period ends.
Can be updated by either the customer or the seller.Moved to an active status automatically when the trial period ends.

When a customer's next billing date is reached, Paddle attempts to take payment from the customer and notifies your backend system with the success or fail outcome.

This outcome determines the customer's subscription status and - in turn - it should determine the customer's level of access to your product/service.

rebilling success.png

If rebilling is successful, Paddle fires a subscription-payment-succeeded alert to your configured webhook.

For existing subscriptions, the payload for this alert includes an initial_payment property which is always set to 0.

  • Your backend system should synchronize its records with required details from the webhook payload and continue to allow the appropriate level of customer access to the product/service.
payment failed flow.png

If rebilling fails, Paddle fires a subscription-payment-failed alert to your configured webhook.

  • Your backend system should synchronize its records with required details from the webhook payload and, if appropriate, adjust the level of customer access to the product/service.

  • What happens after this depends on how Recover settings are configured in your Vendor Dashboard. You can define:

ItemNotes
Payment retriesUp to three payment retries can be defined for different intervals.
Failed payment actionChoose whether to pause, set to past_due or cancel subscriptions if all payment retries fail.
Failed payment notificationsChoose whether to send an email notification to customers for each failed payment attempt.
Canceled subscription notificationsChoose whether to send an email notification to customers if all payment retries fail and their subscription is canceled.

An active subscription might be updated at any time. Updates can be initiated by the customer, the seller, or the Paddle rebilling process:

ActionCustomerSellerRebilling
Upgrade/downgrade subscriptionYesYesNo
Change subscription planYesYesNo
Update payment detailsYesNoNo
Change billing dateNoYesNo
Adjust subscription priceNoYesNo
Pause subscriptionNoYesYes

When any update occurs, Paddle fires a subscription_updated alert to your configured webhook.

Paddle handles any prorated costs if an update prompts a change in the amount to be charged. For further information see our Upgrade & downgrade subscriptions guide.

  • Depending on the type of update made, the customer's subscription status and details may change.
  • Your backend system should synchronize its records with required details from the webhook payload and, if appropriate, adjust the level of customer access to the product/service.

An active subscription might be canceled by the customer, the seller, or the Paddle rebilling process:

ActionCustomerSellerRebilling
Cancel subscriptionNoYesYes

When a new subscription is created for a customer, Paddle generates a hosted web page for that subscription and provides the URL for this page in the subscription_created alert. We recommend making this link available to your customers, so subscriptions can be canceled on a self-serve basis.

Otherwise, subscriptions can be canceled by the seller via the Paddle Dashboard, or the Paddle API.

When a subscription is canceled, Paddle fires a subscription_cancelled alert to your configured webhook.

  • Your backend system should synchronize its records with required details from the webhook payload and revoke customer access to the product/service.