A growing SaaS (software as a service) company was managing subscriptions and billing through a patchwork of spreadsheets and a basic payment gateway, causing billing errors and a steady stream of support tickets. DXDasia built a custom billing platform that cut billing support tickets 40%.
40% Reduction in Billing-Related Support Tickets
Subscription billing was handled through the payment gateway’s basic tools plus manual spreadsheet tracking for plan changes, upgrades, and cancellations — a process that didn’t scale as the customer base grew.
We built a dedicated billing and subscription platform designed around the company’s actual pricing model, replacing manual processes with automated, auditable workflows.
Replacing manual billing processes with automated workflows changed both the customer experience and the internal workload:
Billing is one of the few product experiences that touches every single customer, every single cycle — so errors and friction there compound faster than almost anywhere else in a SaaS product. Automating the parts that were previously manual removed both the errors they were causing and the support burden those errors created.
The platform integrates directly with the existing payment gateway rather than replacing it, adding the subscription logic, proration calculations, and dunning automation the gateway didn’t provide out of the box. Usage-based billing pulls consumption data directly from the product’s own event logs rather than a separate manually-maintained tracking sheet, so the numbers billed always match actual usage. The dunning sequence was tuned specifically to the company’s customer base — timing and messaging for retry attempts were adjusted based on when payments were actually recovering, not a generic best-practice default.
Tech Stack: React, Node.js, PostgreSQL, Stripe Billing API (application programming interface), webhook-driven event architecture for real-time usage syncing.
Most subscription businesses start on their payment gateway's built-in tools, and many never need more. This section uses the gateway's own documentation to show what those tools cover, where the gaps tend to appear, and what to weigh before building. It describes the problem domain, not any one company's results.
Stripe's documentation is a useful reference because it is explicit. Its Smart Retries default to 8 tries within 2 weeks, configurable from 1 week to 2 months, but Stripe does not retry hard declines or India-issued cards. Its revenue recovery tools also include customer emails and automatic card updates. For usage-based pricing, Stripe now says new integrations should start with Metronome rather than basic Meters, while existing Meters setups remain supported.
Proration is the first. Stripe calls it the most complex aspect of changing subscriptions: a mid-period upgrade from a 10 to a 20 plan bills an extra 5, calculated to the second by default, and negative prorations are not automatically refunded. In Stripe's own example, the same sequence of plan changes gives a net credit of 3.34 under its classic billing mode and a zero-total invoice under flexible mode, so the rules you pick change what customers see.
Events are the second. Stripe warns that webhook endpoints may receive the same event more than once, events can arrive out of order, and delivery is retried for up to three days. It recommends logging processed event IDs and handling events through an asynchronous queue, since renewal days create spikes.
Regulation is the third. For India, the RBI's e-mandate rules, as documented by Stripe, require a pre-debit notification at least 24 hours before charging and additional authentication each time for recurring amounts over INR 15,000, and without a mandate an off-session payment is declined.
A custom layer is worth considering when pricing rules are unusual, billing errors are driving support contacts, or finance spends each cycle on manual calculation. It sits on top of the gateway rather than replacing it, which keeps card handling with the processor. A custom web application for subscription logic, invoices and a customer portal then carries your rules. If a standard plan model fits, configure the gateway instead.
| Billing task | What the gateway documents | Gap to plan for |
|---|---|---|
| Failed payments | Smart Retries; no retry on hard declines | Dunning messages and a route to a new payment method |
| Plan changes | Proration to the second; preview available | Choosing and testing rules for downgrades and unpaid invoices |
| Usage billing | Meters; Metronome for new builds | A trusted usage source and reconciliation |
| Indian cards | E-mandate, 24-hour notice, extra authentication | Customer messaging and delayed collection |
| Events | Duplicates and disorder possible | Idempotent, queued handlers |
Gateway behaviour per Stripe documentation, and the work that usually remains. Other gateways differ.
Build only what your gateway cannot do. These steps help you find that line before committing to a custom platform.
With billing now running reliably in the background, the company is exploring additional pricing models (usage tiers, add-ons) that would have been difficult to support under the old manual process but are now a configuration change rather than a rebuild. The self-service portal is also reducing time-to-resolution for the billing questions that do still reach support, since customers arrive with account context already visible instead of starting from scratch.
For many businesses, yes. Smart Retries need no code and default to 8 tries within 2 weeks. They do not retry hard declines or India-issued cards, so you still need customer emails or a self-service route to update a payment method. Build custom dunning only if recovery data shows a gap.
The customer is credited for unused time on the old plan and charged for remaining time on the new one. Stripe's example: moving from a 10 to a 20 monthly plan halfway through bills an extra 5. Stripe calculates to the second by default and lets you preview the invoice first.
RBI rules require customers to register an e-mandate with additional authentication and to receive a pre-debit notification at least 24 hours before each charge. Recurring payments above INR 15,000 need authentication every time. Stripe documents that card charges are therefore delayed by 26 hours and are declined without a mandate.
They are reliable if you design for their limits. Stripe says events can be delivered more than once and not in order, and retries run for up to three days. Log event IDs, process asynchronously, and fetch the current object from the API when order matters.
