A SaaS billing system is ready when it can do more than charge a card. It must create the right subscription, handle renewals, distinguish a temporary payment failure from a cancellation, and give a customer a clear way to recover access.
This checklist is for SaaS founders and product teams choosing a billing workflow before they add more customers. It focuses on the revenue path most likely to create expensive support work: trial to paid activation, recurring renewal, failed payment, customer action and access state.
The SaaS Billing Path to Test
| Stage | Customer event | System decision | Evidence to keep |
|---|---|---|---|
| Trial or checkout | Customer chooses a plan | Create the correct price, currency and term | Plan, price and consent |
| Activation | First payment succeeds | Grant the promised access | Payment event and provisioned plan |
| Renewal | Billing date arrives | Create and collect the next invoice | Invoice, attempt and status |
| Failure | Payment is declined or needs action | Keep the customer informed and retry safely | Failure reason and next attempt |
| Recovery | Customer updates payment details | Retry the open amount and restore service | New payment and access change |
| Exit | Customer cancels or remains unpaid | Stop future billing and apply the agreed access rule | Cancellation or suspension record |
The important design choice is to make billing status and product access related, but not identical. A single failed attempt should not necessarily erase a paying customer's work. An unpaid subscription that has exhausted its recovery path should not silently keep premium access forever.
12-Point Subscription Billing Checklist
- Name plans by the buyer's outcome. “Team reporting” is easier to understand than an internal SKU.
- Define the billing interval. State monthly, annual, trial and renewal dates in the checkout and terms.
- Store the customer and subscription reference. Your support team should find the billing record without searching by a screenshot.
- Test first-payment failure. A failed activation is different from a later renewal failure; do not provision access on an unconfirmed payment.
- Test a successful renewal. Confirm the new invoice, receipt, entitlement period and internal revenue record agree.
- Test an expired card. The customer needs an actionable update path, not a generic “payment failed” message.
- Test a bank decline or authentication request. Some failures need a customer action; others may be recoverable by retry.
- Set a retry policy. Choose the number and spacing of attempts before a subscription is paused, cancelled or marked unpaid.
- Write the customer messages. Explain the amount, affected service, deadline and secure action in every reminder.
- Add a grace-period rule. Decide what remains available while recovery is in progress and communicate it before enforcement.
- Make cancellation and downgrade explicit. Confirm the effective date, last paid period and what happens to data or seats.
- Reconcile billing to access. Review exceptions where payment says paid but access is missing, or access remains after final suspension.
A Worked Recovery Example
Assume a €49 monthly plan renews on 8 August. The first attempt fails because the card is expired. A useful recovery sequence is:
| Day | Action | Access decision |
|---|---|---|
| 8 Aug | Record the failed attempt and notify the customer | Keep access during the initial grace period |
| 9 Aug | Send a secure payment-method update path | Keep access; do not create a duplicate subscription |
| 11 Aug | Retry or request customer authentication | Keep access if the account is still within policy |
| 15 Aug | Send a final reminder with the suspension date | Limit new usage only if terms say so |
| 18 Aug | Mark unpaid or suspend according to policy | Preserve data and explain reactivation |
This is a model, not a universal schedule. Your payment provider, customer contract, region and product risk may require different timing. Stripe documents subscription states, payment-failure events and retry settings in its subscription documentation; use the same discipline with any provider.
What to Measure Each Week
Track activation payment success, renewal success, recovery rate, involuntary churn, voluntary cancellations, time to update a payment method, and subscriptions that need manual intervention. Separate “customer chose to leave” from “billing could not collect,” otherwise product and finance teams will fix the wrong problem.
Do not promise a recovery percentage without a defined cohort and period. A simple internal report with counts is more useful than an impressive but unexplained headline number.
A Practical PayRequest Workflow
PayRequest gives SaaS teams a hosted path for subscription automation, recurring invoices, customer payment updates and payment recovery. Use the subscription plan for recurring access, connect an eligible provider, configure reminders and review the payment status before changing entitlements. If you are migrating from WHMCS, see the managed WHMCS migration option before moving live customers.
Start with one plan and one complete test customer. Record the expected state after activation, renewal, failure, recovery and cancellation. Then create a free PayRequest account and expand only after the full path is understandable. Every standard feature is included on Free; PayRequest charges 2% per successful payment, capped at €25 per transaction, plus connected-provider fees.