Subscription billing for SaaS in India: Razorpay, GST and USD

SaaS billing in India is a two-rail problem. Domestic customers pay in rupees, expect UPI and cards, and need GST-compliant invoices with the right tax treatment for their state. International customers pay in dollars, expect a card on file and a receipt, and are outside Indian GST as an export of services. Indian SaaS therefore needs Razorpay or a similar domestic gateway for INR with GST invoices, Stripe or an equivalent for USD, and a metering layer that feeds both. The architectural decision that keeps this manageable is a single internal ledger of plans, entitlements and usage, with gateways and tax rules as adapters around it.

This article covers the two payment rails, GST invoicing, recurring-payment rules in India, usage metering, and the internal model that ties them together. It is written for founders and engineering leads building billing into a product, though the conversation with your accountant needs to happen alongside.

Why SaaS billing in India is different

Three things separate Indian SaaS billing from the Stripe-and-done setup a US startup can use. Recurring card payments in India are governed by Reserve Bank of India rules on e-mandates, which require customer authentication at setup and notification before each debit, so "card on file, charge monthly" does not work the way it does elsewhere. GST invoicing has structural requirements: the customer's GSTIN, place of supply, and a tax split that depends on whether buyer and seller are in the same state. And exports of services to customers abroad are typically zero-rated under a letter of undertaking, a compliance process rather than a code change, but one that shapes the invoice.

Razorpay subscriptions for the INR rail

Razorpay's subscription product handles plans, mandates and retries for domestic customers, and its documentation covers UPI Autopay and card e-mandates under the RBI framework. The integration points that matter for a SaaS product are the webhook events: subscription activated, charged, halted, cancelled, and payment failed. Your product should react to those events, not to the API response of the initial call, because a mandate can be authorised and then fail on first debit.

Two design points from experience. First, treat the gateway's subscription as the payment schedule, not as the source of truth for entitlements; those live in your ledger, and the gateway tells you whether money arrived. Second, model the notification window: a debit can be declined for reasons unrelated to the customer's intent, so grace periods and a clear in-product "payment pending" state are essential to avoid cutting off paying customers.

UPI Autopay changes the default

For Indian SMB customers, UPI Autopay has become the natural recurring method, with cards second. Design checkout around it, and expect mandate amount limits to affect higher-tier plans; the gateway documentation states current limits, and they change.

GST invoicing for SaaS

A GST invoice for a software subscription needs the supplier's and customer's GSTIN, an invoice number in a continuous series, the SAC code for the service, the place of supply, the taxable value and the tax split. Whether the split is CGST plus SGST or IGST depends on whether the customer is in the same state as your registered entity. If the customer has no GSTIN, they are treated as an unregistered recipient and the invoice looks different again.

Build the invoice from your own ledger, not from the gateway's receipt. Gateways do not know your entity's registration, the customer's place of supply or your invoice series. Store the customer's GSTIN and billing state at signup, validate the format, and generate the invoice when the charge succeeds. Keep invoices immutable and numbered; corrections go through credit notes. Above the e-invoicing thresholds, invoices must also be registered with the government portal, a further integration covered in GST and e-invoicing integration.

The USD rail and exports of services

International customers are usually billed in USD through Stripe or a comparable processor, either via a foreign entity or an Indian entity with international card acceptance. That choice is a tax and treasury question to settle with an adviser before the billing system is designed, because it changes which entity appears on the invoice and where the money lands.

From the product's point of view, the USD rail is simpler: card on file, monthly charge, dunning on failure. The complexity is reconciliation: every USD payment should map to an invoice that identifies the customer as an export recipient, with the bank's inward remittance documentation linked to it. That link is easy to build on day one and painful to reconstruct later.

Metering that feeds both rails

AI features in particular tend to be priced on usage because inference has a real marginal cost. The metering layer records usage events with a customer, a metric, a quantity and a timestamp, aggregates them per billing period, and produces a rated amount either rail can invoice. Metering must be idempotent, auditable by the customer and independent of the gateway. Usage metering and AI billing for SaaS covers the event design in detail, and how to price an AI feature covers the commercial side.

The internal model: one ledger, many adapters

The design that survives growth has four parts. A catalogue of plans and prices per currency. A ledger of customers, subscriptions, entitlements, usage and invoices that is the single source of truth. Gateway adapters that create mandates or charges and translate webhooks into ledger events. And a tax module that, given a customer and an invoice, applies the right treatment, whether GST split, zero-rated export or something new when you expand to another country.

• Entitlements are computed from the ledger, never from the gateway status
• Every money movement is an immutable ledger entry with an idempotency key
• Invoices are generated by your system and numbered per entity and series
• Gateway webhooks are queued and processed with retries; a missed webhook is a reconciliation job, not a lost customer
• A nightly reconciliation compares gateway settlements to ledger entries and flags gaps

This is more work than calling a gateway's checkout, and it is the difference between a billing system that handles a second currency or a tax change with a new adapter and one that needs a rewrite. The same principle underlies the multi-tenant SaaS architecture decisions that avoid a rewrite.

A worked example

A B2B SaaS company selling to field-service businesses in India and the Gulf had started with a single gateway integration and invoices generated from gateway receipts. When they added USD pricing they duplicated the flow, and within a year had two customer records per international customer, invoice numbers that jumped, and a GST return that took a week to reconcile. During the in-app copilot build they asked us to fix billing alongside it, because the copilot was to be priced on usage. The rebuild introduced the ledger and adapters above, moved invoice generation into the product, and added metering that rated copilot actions into both currencies. For finance, month-end reconciliation became a report rather than a project.

Team and timeline

Billing is a module within a SaaS development engagement, which starts at $31,500 or ₹20.8L, or a standalone piece of API and integrations work from $7,000 or ₹4.4L when the product already exists. A two-rail billing system with GST invoicing and metering is typically four to six weeks for a lead engineer and one backend engineer, with your finance lead involved a few hours a week and a tax adviser consulted at the start. Later gateway and tax-rule changes are handled under a care plan. Full figures are on the pricing page; to discuss your billing setup, contact us.

Before you start: a checklist

• Decide which entity bills which customers, with your tax adviser, before designing anything
• Capture GSTIN and billing state at signup and validate them
• Choose the domestic gateway and read its current e-mandate and UPI Autopay documentation
• Define the usage metrics you will bill on and how customers will see them
• Design the ledger first: plans, subscriptions, entitlements, usage, invoices
• Plan invoice numbering per entity and per series, and how credit notes work
• Set up webhook queues, retries and a nightly reconciliation from day one
• Check whether e-invoicing thresholds apply to you now or soon

Glossary

• E-mandate: a customer's standing authorisation for recurring debits under the RBI framework
• UPI Autopay: recurring payments over UPI, authorised once and debited on schedule
• GSTIN: the GST identification number of a registered business
• Place of supply: the location that determines whether CGST/SGST or IGST applies
• Zero-rated export: a supply of services to a customer abroad on which GST is not charged, subject to compliance
• Entitlement: what a customer is allowed to use, computed from the ledger
• Reconciliation: matching gateway settlements to ledger entries to find gaps

Related reading

See SaaS development cost: a realistic budget breakdown, multi-tenant LLM architecture for SaaS and our SaaS industry page. For the primary sources, Razorpay's documentation covers subscriptions and mandates, Stripe's documentation covers the USD rail, and the GST portal is the authority on invoicing rules.

Build one ledger, treat every gateway and tax rule as an adapter, and billing stops being the reason you cannot change your pricing.