Subscriptions
Subscriptions turn one-off payments into recurring billing: you define what should be billed and how often, and the platform takes care of scheduling, collecting the money, retrying failed charges and communicating with your subscribers.
Your own system only has to react to state changes — activate the service when a subscription becomes active, suspend it when it is paused, stop it when it is terminated.
How the pieces fit together
Product (what you sell, and how it is priced)
└─ Product version — the pricing and billing cycle that is currently valid
Subscriber (your customer)
└─ Subscription — links one subscriber to one product version
└─ Charges — the recurring payments generated from the subscription
| Page | What you will find |
|---|---|
| Quick start | The four steps to your first recurring payment, and when to use subscriptions instead of charge flows. |
| Products | Defining what you bill: product versions, components, component groups and pricing. |
| Subscribers | Creating and managing the customer objects that subscriptions are attached to. |
| Subscriptions | The subscription object itself, plus billing, charging and the subscription lifecycle. |
| Coupons & Discounts | Granting discounts on subscriptions. |
Before you start
Subscriptions are built on top of charge flows. Before you can use them, activate the charge flow feature and configure at least one charge flow in your space — see Charge Flows.
Subscription payments also require a connector that supports tokenization, because the subscriber's payment details are stored once and charged again later. See Tokenization.
Staying in sync with your system
Most subscription activity happens asynchronously in the background, so your integration should not poll for changes. Subscribe to webhooks instead and react to the subscription states — see Webhook for the subscription-specific states worth handling.