When you build a SaaS project, it seems that the main focus is on the product, interface, and users. But in reality, the foundation of the business is not buttons and design, but cash flow: how you accept payments, renew subscriptions, handle errors and refunds. The correct billing architecture affects everything from the MRR graph to legal stability. In this text, we will explore what the subscription lifecycle should look like, which scenarios are automated, how retries, taxes, and refunds are structured. This is not dry documentation, but a practical map for building a working system from scratch.
Subscription Lifecycle
Modern billing is not just an automatic charge once a month. It is a system of states, events, and rules that make payment seamless for the user and predictable for the business. It all starts with the trial period.
Auto-renewal after Trial
The trial period is a marketing tool, but for the system, it is a special subscription state. When a client completes the trial, the platform must automatically switch them to a paid plan if they have not canceled the subscription. This is a standard established by all major payment providers - from Robokassa to Stripe. The key point is transparency: the client should know that their card is saved and will be charged.
It is good practice to send a reminder 2–3 days before the end of the trial period. This not only reduces the number of disputes and chargebacks but also builds trust: the user feels that they are being treated honestly. If they do not renew, the subscription is automatically closed without any extra actions.
Auto-payments and Notifications
When the trial period ends, auto-payment comes into play. The system generates an invoice, sends it to the acquiring bank, and upon successful charge, saves the transaction data. It is important that payment notifications are not just a "bank letter" but part of your communication.
Good SaaS services duplicate notifications through multiple channels - email, Telegram, WhatsApp, or push. This reduces the number of "lost" clients who were unaware that the charge went through and later request a refund.
Plan Change and Proration
Many users start with a minimal plan and later upgrade. At this point, an important task arises - correctly calculate proportional payment. Suppose a client paid $10 for a month but decided to switch to a $20 plan after two weeks. Logically, the system should only charge $5 for the unused part of the period.
Stripe and Paddle can make such recalculations automatically. This is not just accounting accuracy - it is client trust, seeing that they are charged a fair amount.
Pause and Grace Period
Not every client wants to cancel their subscription - sometimes they just need time. Therefore, many platforms implement a grace period - a grace period when the subscription is temporarily frozen without charging. You can conditionally give the user 5–7 days of "breathing room."
If they update their card or top up their balance, the subscription continues without losing history and data. If not, the system automatically terminates the subscription. The main thing is not to leave the client forever in a "free" state. This creates an illusion of activity and distorts MRR metrics.
Access Management and Payment Logs
After a successful charge, the system restores access to the service, updates the status, and the date of the next payment. If the payment fails, a chain of actions is triggered: retries, notifications, access suspension, and in extreme cases - disconnection.
Serious companies like Tinkoff or Robokassa build logic at the billing service level, not the frontend. This allows them not to depend on interface errors and ensures idempotency: each event - one action, one result.
Retries, Reminders, and Dunning
About 20–30% of subscriptions miss at least one payment due to card errors. But this money can be recovered - not manually, but automatically. This is where the dunning process comes into play - a system that recovers "lost" payments without annoying the client.
Intelligent Retries
The most common mistake is trying to charge immediately after a decline. For example, if a bank declined the transaction due to a temporary limit, retrying in 10 minutes will also fail. Delayed attempts are much more effective: after 3, 7, and 14 days, analyzing the type of error.
- Soft decline - temporary failures (insufficient funds, daily limit). Such payments should be retried several times.
- Hard decline - final (card invalid, blocked). Here a different approach is needed — request to update details.
According to PayProGlobal and other payment systems, smart retries can recover up to 30% of failed charges.
Communications and Reminders
When a payment fails, it is important not just to silently retry, but to notify the user. The best systems send short, respectful notifications:
"Payment failed. The card may have expired or exceeded the limit. Update your details — and the subscription will continue automatically."
Channels - any: email, push, Telegram, WhatsApp. The main thing is to be unobtrusive. Clients do not like feeling pressured, but they respond calmly if it is about maintaining access to the service.
Timing and Flexibility
Not all hours and days are the same. Do not try to charge payments at night or on the last day of the month when clients have a zero balance. Intelligent billing engines analyze decline statistics and choose optimal intervals and gateways (e.g., another BIN).
The grace period helps find a balance between loyalty and discipline: you give the user time to pay, but do not keep access indefinitely. After 2–3 failed attempts, it is worth temporarily limiting functionality and then completely blocking the account.
Invoices, Taxes, and Compliance
When it comes to money, the system must be not only convenient but also legally compliant. Billing in SaaS is not just API payments, but a whole chain of obligations to the client, the state, and payment providers.
Invoicing and Documents
Every successful payment should be accompanied by an invoice or receipt. Ideally - in PDF format with a unique number and details. The client should be able to download it from their account or receive it by email. In Stripe and Paddle, this logic is built-in, but you can also implement your own system.
Storing such documents is not "for show." It is your accounting trail and legal protection. During an audit, inspection, or dispute, the invoice is the first thing requested. For investors and analysts, it becomes the basis for calculating MRR, ARR, and customer cohorts.
Taxes and MoR Model
The biggest headache in international SaaS is taxes. If you work directly through Stripe, you are the seller (merchant of record). This means you are obliged to account for and pay VAT, GST, or sales tax depending on the client's country.
Stripe offers a Stripe Tax module that calculates the necessary rate, but the responsibility for payment and reporting lies with you. This is critical for Europe, Canada, Australia, and other regions where online sales laws are strictly enforced.
Paddle goes further: it becomes the Merchant of Record itself. That is, you sell your SaaS, but Paddle legally acts as the seller on your behalf, withholds taxes, issues receipts, and even handles chargebacks. This relieves you of 90% of the headache, but at the cost of a commission (usually 5–10%).
If you are targeting the US and Europe, the MoR model is the ideal start. If you are building a local business (e.g., in Kazakhstan or the CIS), you can go the route of a direct Stripe integrator or Robokassa with internal VAT accounting.
Legal Documents and Transparency
The payment system requires the client to agree to the subscription terms: Terms of Service, Privacy Policy, Refund Policy. These are not just formalities - they are your protection in disputes.
For example, Stripe and Paddle require that:
- there is a cancel subscription button;
- the client consciously activates auto-renewal (with a checkbox);
- there are clear refund and renewal terms on the site.
If you work with clients from the EU, a DPA (Data Processing Agreement) and GDPR compliance are mandatory. For Russia - consent to data processing (Federal Law-152) and issuance of electronic receipts under Federal Law-54.
Compliance is not bureaucracy, but insurance. One lost dispute or complaint to the payment provider can result in account blockage.
Refunds, Chargebacks, and Analytics
Mistakes happen to everyone. But what matters is how you handle them. A refund and payment dispute are not a catastrophe, but a process that can be automated and turned into part of the brand's trust.
Refunds
Good services allow the client to request a refund without correspondence with support. One click - and the API provider initiates the transaction. The refund can be full or partial, depending on the rules.
The main thing is transparency:
- refund status (“processing”, “sent”, “credited”),
- timelines,
- email notification.
All movements should be reflected in accounting: MRR/ARR is recalculated, and the refund is reflected in reports. Stripe and Paddle do this automatically.
Chargebacks and Evidence
The most painful topic. A client disputes a charge with the bank - and the money is blocked. The winner is the one with evidence.
Minimum set for protection:
- client activity logs (IP, logins, actions, dates),
- email and support ticket history,
- copy of subscription terms and refund policy,
- proof that the user subscribed themselves.
Stripe, Justt, and Paddle require a documented response: dates, amounts, statements, screenshots. If the response is clear and concise, the chance of winning the dispute is up to 80%.
Accounting and Analytics
Without analytics, billing is a black box. Automation should collect SaaS metrics:
- MRR/ARR - monthly and annual recurring revenue,
- Churn Rate - attrition,
- LTV - lifetime value of the client,
- ARPA - average revenue per account,
- NRR - net revenue retention.
These indicators provide not only numbers but also meaning: you see whether the business is growing or stalling. Data can be collected through your databases or BI tools like Metabase, Grafana, or Superset.
It is important not just to count money, but to reconcile actual receipts from Stripe/Paddle with invoices. The difference can reveal errors or losses.
Audit and Security
Every action on payments and refunds should be logged: who, when, for what amount. This saves during disputes, errors, and audits. Add idempotency at the webhook level so that repeated events do not cause duplication.
Ideally, billing is not just a service, but a separate module with queues, workers, and protection. It should handle webhooks, retries, notifications, and update analytics without affecting the rest of the system.
Conclusion
Modern billing in SaaS is an ecosystem where finance, logic, and law are intertwined. An error at one stage can cost trust, money, and access to acquiring. But if you build the system according to the principles of Stripe and Paddle - with a clear lifecycle, automatic retries, correct tax model, and transparent documents - you will get not just stable income, but a machine of predictable growth.
Good billing is not only money in the account but also the confidence that they will come again tomorrow.
Leave a comment
Comment