SaaS subscription billing is a continuing relationship between a purchasing account, a billing provider and the access rules inside your product. A successful checkout begins that relationship. The application must keep it coherent as plans change, payments fail, subscriptions renew and customers cancel.
Design billing from the customer lifecycle before building a payment button. For a hypothetical scheduling product, a team should understand what it purchased, what it can use now and what will happen at the next billing change.
Separate the records that answer different questions
A transaction records a financial operation. A subscription describes the continuing billing arrangement. An entitlement describes what your application allows the workspace to use.
Keep these concepts connected without treating them as interchangeable. A subscription may include several items. A transaction may represent an adjustment or one-time purchase. A billing contact may be a person, while paid access belongs to their team's workspace.
Store explicit associations between your workspace and the relevant provider records. Use identifiers established through trusted application flows. Email similarity alone should not decide which company receives access.
Also separate the provider's status from your customer-facing explanation. A useful billing page translates the current state into practical information: available features, next charge, pending change and any action the account owner needs to take.
Map subscription states to an application policy
Paddle's subscription reference documents states including trialing, active, past_due, paused and canceled. Those states provide facts your application uses when deciding access.
Create an explicit product policy for each state:
| State | Product decision to define | Customer explanation |
|---|---|---|
| trialing | Define the trial capabilities, duration, and end-of-trial behavior | Show what is available and when the trial ends |
| active | Apply the purchased capabilities and any scheduled plan change | Show the current plan and relevant renewal details |
| past_due | Define whether a grace period or restricted access applies | Explain the payment issue, available access, and recovery action |
| paused | Define permitted reads and operations while billing is paused | Explain the pause and how authorized users may resume |
| canceled | Define the effective access end, data retention, and any read-only policy | Explain what has ended and which recovery or export options remain |