Subscriptions and Recurring Billing: Payment Architecture for SaaS

Recurring payments are the heart of any SaaS model. Customer churn, cash flow, and the speed of rolling out new pricing tiers all depend on how well the billing architecture is designed. ESK Solutions studio, which specializes in SaaS application development, regularly designs recurring payment systems for B2B and B2C products. In this article, we break down the key components—from managing pricing plans to handling past-due payments and integration via webhooks.

Key Components of Recurring Payment Architecture

A SaaS billing subsystem is not limited to scheduling recurring charges. It is a complex pipeline that includes:

• a catalog of pricing plans and add-ons;
• processing recurring charges with awareness of time zones and grace periods;
• handling failed payments (past due) and dunning scenarios;
• receiving events from payment gateways via webhooks;
• synchronizing subscription statuses with the product's internal logic.

Properly designing this part saves dozens of support hours and directly impacts trial subscription conversion. If you are ordering web development from scratch, the billing module should be designed before active coding begins—refactoring the architecture later is costly.

Managing Subscriptions and Pricing Plans

A pricing grid is more than just a list of prices. In modern SaaS, it includes several dimensions of flexibility:

• base plans (monthly/annual) with included resource quotas;
• consumption-based metrics (pay-as-you-go);
• add-ons—additional modules charged separately;
• promotional periods, coupons, and discount programs.

Architecturally, each subscription should store:

• the pricing plan ID and its version (snapshot taken at signup);
• start date, end date, and next billing date;
• status (active, past_due, canceled, trialing);
• change history—plan transitions, pauses, and resumptions.

Use an intermediate business logic layer (billing engine) on top of the payment gateway. This allows you to switch processing providers (Stripe, Braintree, CloudPayments) without changing the product core. When developing a cloud-based B2B service, it makes sense to combine recurring billing with consumption metrics—such solutions are built into our cloud services development offerings. Special attention goes to localization: VAT, tax accounting, and invoice generation. The payment module must be able to generate invoices compliant with the client's country legislation.

Handling Past Due and Failed Payments

Past due payments are an inevitable part of SaaS life. Failed charges can be caused by insufficient funds, expired cards, bank fraud monitoring, or technical glitches. Without a well-designed dunning process, you risk losing paying customers due to temporary issues.

Typical Dunning Strategy

1. First failure: notify the user in-product, retry after 3–5 days.
2. Second failure: email asking to update the payment method, retry after 7 days.
3. Third failure: temporary suspension of access (data preserved), final warning.
4. Fourth failure: cancel subscription, export or archive data.

The key principle is gradual escalation. It's important to give the customer time to react but not indefinitely. Webhooks from the payment gateway for events like invoice.payment_failed and invoice.payment_succeeded must immediately update the subscription state in your system and trigger the appropriate scenarios.

Smart Retry Logic

Simply "trying again" is not enough. The success rate of retries improves when you consider:

• time of day and day of the week (payday periods);
• card-issuer behavior (banks may block multiple attempts);
• automatic card update mechanisms via services like Account Updater (Stripe).

The system must distinguish between "soft" (declined but not fraudulent) and "hard" declines to avoid accumulating accounts receivable. Overdue subscriptions create operational overhead: support, retention, reactivation. Properly designed billing during CRM system development can automatically route such customers to the customer care team.

Integration via Webhooks and Events

Webhook infrastructure is the nervous system of billing. Payment gateways send dozens of event types to your endpoint: invoice creation, successful payment, failure, refund, chargeback. Your task is to reliably receive, validate, and respond to them in a timely manner.

Webhook Endpoint Requirements

• Idempotency: reprocessing the same event should not lead to duplicate operations (use the event ID as an idempotency key).
• Signatures and security: verification of webhook signature authenticity (Stripe Webhook Secret, HMAC).
• Asynchronous processing: event reception and handling should be separated (message queues).
• Dead Letter Queue: events that failed to process should be saved for manual review and reprocessing.

Try not to execute heavy business logic synchronously in the webhook handler. The optimal scheme: the endpoint receives the event, verifies the signature, places it in a queue, and immediately returns 200 OK. A separate worker reads the queue and performs real actions—extending access, sending emails, updating analytics. This ensures fault tolerance under peak loads.

Status Synchronization

Never trust a status stored only on the gateway side. Your own database should be the source of truth for business logic. Regular reconciliation between your records and the payment provider's data reveals discrepancies—stale invoices, desynchronization after failures. This is especially critical when scaling, when the number of subscriptions exceeds thousands.

When doing custom integration with non-standard payment methods or billing engines, it's useful to design a universal event layer independent of any specific gateway. This pays off when you decide to add a second provider or switch to another one. ESK Solutions uses a similar approach in projects involving SaaS application development and integration of third-party services. Such a layer can be extracted into a separate microservice, which will positively impact the stability of the main product.

Frequently Asked Questions

Should you build your own billing system from the start?

At the start, it's much more efficient to use ready-made platforms (Stripe, Chargebee, Recurly) and customize them via API. In-house development is justified if you have a unique pricing model, strict data sovereignty requirements, or the need for deep integration with an internal accounting system.

How to protect against accidental double charging?

Idempotency mechanisms at the gateway API level and in your own code are mandatory. Always pass an idempotency key when creating a payment. On your backend side, check for an already processed operation with the same key.

What to do with customers whose subscription has been overdue for more than 30 days?

Automatic cancellation of the subscription with prior notice is standard practice. It's best to retain customer data for the period specified in the retention policy to simplify reactivation. Manual handling of such cases via a CRM system helps win back some customers.

Which billing metrics need to be tracked?

Key metrics: MRR (Monthly Recurring Revenue), ARPU, Churn Rate, Expansion Revenue, average successful billing rate (Billing success rate). Without this data, it's impossible to manage unit economics.

A well-designed recurring billing system is the foundation of the entire SaaS financial model. Spend time on architecture before launch, build flexibility into plan management, automate overdue handling, and construct a reliable webhook pipeline. These investments pay off with payment stability and reduced churn.