DEV Community: Ravi Rai

The website that kept Meera's oven warm

Ravi Rai — Tue, 21 Jul 2026 06:56:47 +0000

There is a particular quiet that settles into a kitchen when the orders stop coming. Meera noticed it first in the flour tin. She used to go through a ten kilo bag most weeks. That month, one bag lasted almost three. The oven that used to run from early morning sat cold through the afternoons. She would wipe a counter that was already clean, pick up her phone, look at nothing, and put it back down. Then wipe the counter again. Meera is not her real name, and the town does not matter for this. She runs a small bakery out of her own kitchen in a tier-2 city. Cakes for birthdays, boxes of cookies for Rakhi, the occasional wedding order that kept her up for two nights straight and made her proud for a week. What she earns from that oven is not pocket money. It feeds her family. Her husband's work is the kind that pays well one month and almost nothing the next, so the bakery is the floor the whole house stands on. And that year, after the festive rush ended, the floor started to give.

The site that said she was closed

When she first messaged us, I did the thing I always do before a call. I looked her up on my phone, the way a hungry stranger would at nine at night. The page took a long time to load. Long enough that in real life the person would have tapped back and gone to the next bakery in the list. When it finally opened, the text was crammed into a thin column shoved to one side of the screen, the photos were stretched out of shape, and there was a phone number sitting in bold near the top. That number had not been hers for two years. Someone had built the page for free a long time ago, taken whatever they were paid, and vanished. There was no menu you could read. No prices. No button to place an order, no chat, nothing. Just one photo of a cake and a dead phone number. Here is the part that stayed with me. To a stranger, that page did not look like a bakery having a hard month. It looked like a bakery that had shut down and forgotten to take its sign off the wall. Every single person who found her online was quietly being told she was closed.

The week she almost gave up

The festive months had been kind. Diwali orders, a couple of weddings, boxes going out the door every day, the oven barely cooling between batches. Then the season ended, the way it always does, and the slump rolled in behind it. That much she was used to. Every year has a lean stretch, and she had learned to ride it out. What she could not ride was the hospital bill that arrived the same month the orders thinned. I am not going to put the figure here. It was the kind of number that does not leave room for anything else in the house. So there she was. Orders already down to a trickle, and now every rupee spoken for. She started running the math a lot of small owners run at two in the morning. What a loan would cost her. The interest on top. Whether she could ever really pay it back, or whether she would just be trading one fear for a bigger one. Whether it was time to switch the oven off for good, find a job somewhere, and stop calling the bakery a business. She had, quietly, mostly decided to stop. She just had not said the words out loud yet, because saying them would make it real.

I almost did not message you. I kept thinking, why would anyone build a website for a woman selling cakes out of her kitchen.

— Meera

What we actually changed

When she finally wrote to us, she apologised twice in the first three lines. She was certain she could not afford it. I think part of her expected me to be polite and then quietly disappear, the way the last person had. So we did not talk about websites at first. We talked about the bakery. What she made, who bought it, what a good week used to look like. She sent me a long voice note that day, talking fast, listing everything she baked, apologising again for taking up my time. I still think about that voice note. Then we got to work, and none of it was fancy. That is honestly the point. We built the things a small business actually needs to take an order, and we left out everything it does not. This is the whole of what our small business web work is really about.

A fast, mobile-first website. It opens in a second or two on a cheap phone with a weak signal, because that is exactly what her customers are holding when a craving hits.
WhatsApp ordering. One tap from the site drops the customer into a chat with her, since that is where she was already comfortable talking to people and writing down orders.
UPI and card payments. So an order gets paid for right then, on the spot, instead of an "I will send the money later" that somehow never arrives.
A proper Google Business Profile. Real photos of her actual cakes, the correct phone number, her hours, her spot pinned on the map, so she finally showed up when someone nearby went looking.
Local SEO. The slow, unglamorous work of making sure a hungry person two kilometres away lands on her instead of scrolling straight past to a big chain.

The first order from a stranger

The first online order came in on a Tuesday afternoon. I remember it was a Tuesday because Tuesdays are slow for everybody. It was not a relative. It was not an old classmate doing her a favour. It was a stranger who had searched for a cake in her area, found her on the map, scrolled through the real photos we had put up, and ordered straight through the site. Paid up front on UPI, before Meera had even opened the message. She called me a few minutes later, and she was crying. Not the sad kind of crying. She kept asking how a person she had never met, who did not know her name or her family or her street, had found her. I did not really have a clever answer for her. That is just what a website does when it is built right. It does not perform miracles. It quietly removes every reason a ready customer had to give up and go somewhere else. The cake was there. The customer was there. For years the only thing standing between them was a slow page and a wrong phone number.

A stranger found me. I have been baking for six years and a stranger found me and paid before I even replied.

— Meera

Why we build the way we do

Within a few weeks the oven was running full days again. She pulled in a neighbour to help with deliveries because she could not keep up with both the baking and the running around. I am not going to hand you a percentage or a revenue figure. I did not audit her books, and I am not going to invent a clean number just to make this story sound tidy. Plenty of people in my line of work would. What I can tell you honestly is this. The oven stayed warm. The loan she was terrified of never had to be taken. The lights stayed on. For a business like Meera's, that is not a small win. That is the whole thing. This is why I get a little impatient when people call a website a line item, something you buy once and forget. A website is not pixels on a screen. For the right business, built the right way, it is the difference between an oven that runs and one that goes cold and stays cold. That is the reason we build the way we do. Fast, so it opens on the oldest, cheapest phone in the market. Easy to find, so someone nearby actually lands on it. Dead simple to order from, so nothing sits between a ready customer and the thing they came for. We do the same for a tailor, a clinic, a tiffin service, a repair shop. You can see the plain version of how we work with small businesses whenever you like.

Questions we get from small business owners

Do I really need a website if I get orders on WhatsApp and Instagram?

WhatsApp and Instagram are wonderful for the people who already know you exist. A website is for the ones who do not. When a stranger searches for what you sell, your Instagram rarely comes up, and your WhatsApp number is not something Google can show them. A simple site is the thing that catches that person and then hands them straight into a WhatsApp chat with you. You are not throwing away what already works. You are adding a front door so new people can walk in.

How much does a small business website cost?

Less than most people are afraid it will be, and we tell you the range before you commit to anything. The real answer depends on what you actually need, and for a lot of small businesses that is not much at all. We would far rather build you the right small thing than sell you a big expensive one you will never fully use. Tell us your honest budget and we will tell you honestly what it can and cannot do.

How long before people find me on Google?

Not overnight, and anyone who promises overnight is selling you something. A Google Business Profile can start putting you on the map within a few weeks, sometimes sooner. Ranking in normal search results takes longer, usually a few months, and it depends on your area and how many others are doing the same thing. We set everything up properly from the first day so that time starts working for you instead of against you. Slow and real beats fast and fake.

If your business is quieter than it should be, tell us about it. No pitch, just a real conversation about what would actually help. → Tell us about your business

How to Build a Subscription Billing System in India (2026): Mandates, Proration, Dunning, GST Invoices, and Build vs Buy

Ravi Rai — Mon, 20 Jul 2026 06:01:47 +0000

A payment gateway moves rupees once. It authorizes a card or a UPI request, settles the money, and fires a success webhook. That is where most integration guides stop, and that is exactly where the real work of a subscription business begins. Recurring revenue is not one payment repeated. It is a relationship you have to manage on a schedule, forever, and no gateway sells you that layer.

In India the gap is wider than the Stripe-world tutorials admit. You cannot just save a card and re-charge it whenever you like. You register a mandate the customer's bank approves, you live inside RBI's e-mandate rules, you respect the UPI Autopay per-debit cap, and you stamp a GST-correct tax invoice on every renewal. Get any one of those wrong and the debit fails or the invoice does not match the money in your account.

This guide is the full build, in the order we actually build it: what a billing system is versus a gateway, the India mandate problem, the data model, the subscription state machine, proration maths, dunning, GST-compliant recurring invoices, the self-serve portal, revenue analytics, and an honest build-vs-buy call. We write it from production, not a vendor deck. Where a number depends on the current rulebook or your own pricing, we say so in the text, and you should verify it against your own setup before you ship.

What a subscription billing system actually is (and what a payment gateway is not)

A payment gateway collects money once. It authorizes a card, a UPI request, or a mandate, moves the rupees, and hands you a success webhook. That is the rail, and we covered how to pick it in our accept payments in India post, so we will not repeat it here.

A billing system manages the relationship after the money moves, on repeat, forever. It is the layer no gateway sells you. Seven jobs live here:

Plans and pricing: tiers, trials, coupons, metered usage
Subscription lifecycle: activate, upgrade, pause, cancel
Mandates: UPI Autopay, e-mandate, card-on-file recurring
Proration: mid-cycle plan changes, credits, refunds
Dunning: retry failed charges, notify, then suspend
Recurring GST invoices: correct place of supply, HSN/SAC, IRN
MRR and churn reporting: what is actually recurring, and what is leaking

Who has outgrown a raw gateway integration: Indian SaaS billing monthly, OTT and streaming, edtech, gym and coworking memberships, and D2C subscription boxes. The morning one card fails and nobody retries it, you have outgrown the gateway.

We write this from production, not a vendor doc. We run recurring billing inside PlugEV (metered EV session billing), CloudNX (INR hosting renewals), and MultiVendor CRM (per-tenant plans).

The thesis is simple: you will build this layer whether you design it on purpose or it grows by accident. The accidental version still runs. It just leaks money quietly.

The India mandate problem: UPI Autopay, e-NACH, and RBI e-mandate rules

In India, a recurring charge is not a saved card you re-charge whenever you like. You first register a mandate, a standing instruction the customer's bank approves, and every future debit runs against that mandate's limits and rules. Get the mandate wrong and the debit simply fails, no matter how clean your billing logic is.

UPI Autopay is the easiest to onboard, but it carries an AFA-free threshold of Rs 15,000 per debit. A debit at or below Rs 15,000 auto-debits hands-free; a debit above Rs 15,000 is allowed, but it triggers additional factor authentication (an OTP) on every single debit, which defeats the point of hands-free billing. That single number shapes your architecture. A Rs 24,000 annual plan cannot ride UPI Autopay hands-free, because a single debit above Rs 15,000 triggers an OTP every cycle. You either route high-value plans to another mandate type or split the amount into smaller debits that stay under the threshold. An enhanced Rs 1,00,000 AFA-free limit does exist, but only for specific categories (insurance premiums, mutual funds, and credit-card bills), not general SaaS.

e-NACH / e-mandate covers higher-value collections and bank-account debits, with per-mandate limits you set at registration. These are not capped at Rs 1,00,000: that figure is the enhanced AFA-free category limit, not a universal e-NACH ceiling. General e-NACH per-mandate limits can run much higher, and banks support well above Rs 1,00,000 (the exact ceiling varies by sponsor bank and gateway). Card e-mandates are the third rail for card-first customers. Your system should pick the mandate type per plan, not force one rail on everyone.

RBI e-mandate rules that become code. Two things you must build in: a pre-debit notification sent to the customer at least 24 hours before each charge, and additional factor of authentication on the first registration (and on debits above the AFA threshold). You also cannot store the raw card number. You work with network tokens only, the same tokenisation flow we cover in our accept-payments guide.

Model the mandate as a first-class object. Give it its own row and lifecycle: created, active, paused, revoked, expired. Do not bury the mandate as a hidden field on the subscription, because a paused or revoked mandate can outlive or precede a plan change, and you need that history when a debit bounces.

Every debit and every mandate event flows back through webhooks. Apply the same idempotent, callback-driven discipline we detail in our Razorpay webhooks post: one handler, keyed on event ID, safe to replay.

The data model that makes or breaks it

Get the schema wrong and every feature you bolt on later fights you. We have rebuilt billing tables for clients who baked prices into plans, and the migration is never a weekend job. Here is the shape that holds up.

Split product, plan, and price into three tables. A product is the thing you sell (your Pro tier). A plan is a billing shape (monthly, annual). A price is the actual amount. One plan carries many prices: monthly INR, annual INR, USD for overseas users, a Diwali promo. Never store the amount on the plan row. The day you launch annual billing, you will thank yourself.

Model subscriptions with subscription_items. A subscription links a customer to a plan, but the real charges live in subscription_items. That is how one customer holds a base seat, three extra seats, and an SMS add-on without you inventing a flat combined charge. Proration later reads from these items.

Invoices are append-only. Keep invoices, invoice_line_items, and credit_notes as separate records. Once an invoice is finalized you never edit it. To correct it you issue a credit note. This is not a preference, it is a GST requirement: a finalized tax invoice is an immutable document, and adjustments happen through credit notes with their own numbering series.

Mandates and payment_attempts get their own tables. An e-mandate (UPI Autopay, card, or eNACH under the RBI framework) has a lifecycle. Every debit, retry, and failure needs a row in payment_attempts so dunning has a real audit trail, not a status field you overwrite.

Money and immutability. Store amounts as integer paise, never floating point. Never hard-delete a billing row; soft-delete or void.

Tenant isolation from day one. In a multi-tenant SaaS, scope every billing table by tenant_id. See our per-tenant billing section for the isolation model.

The subscription lifecycle as a state machine

Every billing bug we have cleaned up traces back to a subscription being in a state nobody named. So name them first.

The six states worth modeling: trialing, active, past_due, paused, canceled, and expired. Fix the legal transitions and forbid the rest. trialing goes to active or canceled, never straight to expired. active slips to past_due when a debit fails, then either recovers to active or ends in canceled after dunning gives up. paused only comes from active and only returns to active.

Drive transitions from events, not a cron job guessing. A mandate debit succeeded, a debit failed, a cancel was requested: each is an event that moves the machine. Razorpay tells you this through webhooks (subscription.charged, subscription.halted), so handle them idempotently. Store the event ID, check it before you act, and a retried webhook never double-advances a subscription. See our Razorpay webhooks guide for the dedupe pattern.

Trials and coupons touch the invoice, not the mandate. A 14-day trial or a first-cycle 30% off changes what the first invoice charges. The e-mandate you registered still authorizes the full recurring amount (though on UPI Autopay any debit above ₹15,000 needs an OTP each time, so it is not truly hands-free above that threshold). Discount the line item, keep the mandate intact.

Pause and resume is a real Indian retention lever. Gym, OTT, and coworking members freeze for a month instead of canceling. A paused state that stops billing but keeps the mandate alive saves the relationship. Cancel does not.

The renewal engine is a scheduled job that finds due subscriptions, raises the GST invoice, and triggers the debit. Make it re-runnable: guard on invoice_already_raised_for_period so a re-run never bills twice.

Cancellation: cancel_at_period_end lets access run out the paid cycle; immediate cancel revokes now. Either way, cancel the mandate at the gateway so no orphan debit fires later.

Proration: the maths of mid-cycle upgrades and downgrades

Proration in one line: when a customer changes plans mid-cycle, charge them fairly for the part of the cycle they actually used.

Upgrade path. Credit the unused time on the old plan, charge the new plan immediately, and net the difference. The customer pays the gap now and their renewal date usually stays the same.

Downgrade path. Do not refund cash. Bank a credit and apply it against the next invoice. Refunds trigger reconciliation, RBI mandate mess, and support tickets you do not want.

Compute it without bugs. Derive a per-second or per-day rate from the full cycle, not a rounded monthly figure. Work in integer paise end to end and round once, at the very end. Example: a customer on the ₹999 plan upgrades to ₹2,499 on day 20 of a 30-day cycle. Unused credit is 999 × (10/30) = ₹333. New plan charge for the remaining 10 days is 2,499 × (10/30) = ₹833. They pay ₹500 today.

Proration is invoicing, not just arithmetic. A downgrade credit becomes a GST credit note against the original invoice. An upgrade charge is a new taxable line at 18% GST. Get the document type wrong and your GSTR filing breaks.

The harder cousin: metered billing. On PlugEV the charge depends on kWh consumed, not a flat plan, so we rate usage events into paise continuously and invoice the total at cycle close. Same integer discipline, more moving parts.

We test the proration engine like a payments path. An off-by-one-day error looks tiny in a unit test and bleeds real money at scale, so we run fixed-clock cases across every upgrade, downgrade, and trial-conversion boundary.

Dunning: how to stop involuntary churn eating your MRR

Not all churn is a customer walking away. Voluntary churn is someone who cancels on purpose. Involuntary churn is someone who wanted to stay but whose auto-debit failed. Industry estimates put involuntary churn (failed payments and expired mandates) at roughly 20 to 40 percent of total subscription churn, and that slice is recoverable if you build for it.

The retry ladder. Don't hammer a failed mandate the same day. Space retries out, for example day 1, 3, 5, and 7, and tune the schedule to the actual failure reason. In India the common ones are insufficient balance, a paused mandate, and bank downtime. Insufficient balance clears near salary dates, so a day-5 or day-7 retry often lands when day-1 won't. Razorpay Subscriptions runs a retry schedule but gives you limited control over its timing and messaging; a rules-based cadence like this, with your own retry days and pre-debit copy, needs a dedicated tool like Chargebee or a custom dunning layer.

Pre-debit notifications feed dunning. The RBI-mandated pre-debit heads-up (24 hours before the debit) is also your best churn-reducer, because customers top up their account when they see it coming. Treat it as the first rung of dunning, not a compliance checkbox.

Multi-channel, but respect the rules. Send reminders in-app, over email, and via WhatsApp or SMS. SMS and promotional WhatsApp go through DLT-registered templates, so wire your dunning copy into the same DLT-compliant notification pipeline you already use for transactional messages, or they won't deliver.

Grace period and the cancel path. Decide how long a subscription stays past_due before it expires. A 7 to 14 day grace window is common. Keep the customer's access live during grace so a recovered payment restores service without a break, then downgrade or expire once retries are exhausted.

Measure it. Track recovery rate (failed payments recovered divided by total failed) per cohort and per retry day. Without that number, dunning is hope. With it, you can move retry days and reminder channels and see the MRR you saved.

GST-compliant recurring invoices

Invoice on the settled amount, not the attempt. When Razorpay or a NACH mandate fires a renewal, wait for the webhook that confirms the debit cleared, then generate the invoice against that captured payment. If you invoice on the gross plan price at the attempt stage, a failed or partial debit leaves you with an invoice that never matches the money in your account. Tie every invoice to a real payment_id, not a scheduled charge.

Keep the number series audit-clean. Invoice numbers must run sequentially per financial year and per GSTIN. Reset the counter on 1 April, prefix by GSTIN if you bill from more than one state, and never reuse or skip. For downgrades, mid-cycle proration credits, and refunds, issue a GST credit note linked to the original invoice rather than editing it. That keeps the sequence intact when an auditor pulls it.

Get place of supply right. For SaaS the customer's registered state decides the tax split. Same state as your GSTIN gets CGST + SGST, a different state gets IGST, both at 18%. Your billing engine has to store and read the customer state before it stamps the line, so capture GSTIN and state at signup. Use SAC 9983 / 998314 for software services on every recurring line.

Know the boundary. This is the billing engine cutting the invoice. IRP submission and IRN generation are a separate step once you cross the e-invoicing turnover threshold (see our GST e-invoicing post), and booking these into the ledger belongs in Zoho Books or Tally (see those posts).

Send it automatically. On every successful renewal, auto-email the PDF invoice and expose the full history in the customer self-serve portal so nobody raises a ticket asking for it.

The customer self-serve billing portal

The portal exists so your inbox stops filling with billing tickets. A customer should log in and, without emailing anyone, view past invoices, download the GST invoice (with your GSTIN, HSN/SAC, and tax split), see the next debit date and amount, and upgrade, downgrade, pause, or cancel. If they can't do these six things themselves, support does it for them.

Mandate re-registration is the one to get right. When a card expires or a customer revokes a mandate at their bank, the debit silently fails and that is churn nobody noticed. Detect the dead mandate, email/WhatsApp the customer, and drop them into a one-click re-registration flow before the next cycle.

Make cancel a save flow, not a button. Before the final confirm, offer pause (reuse your lifecycle pause state) or a downgrade to a cheaper tier. Many "cancels" are really "too expensive this month."

Let them change payment method and switch rail: a customer moving to an annual plan whose per-debit amount clears the UPI Autopay AFA-free threshold (INR 15,000) would face an OTP on every debit, so it makes sense to shift them from UPI Autopay to e-NACH, and you should surface that automatically.

Isolation is non-negotiable. Every route is authenticated and tenant-scoped; customer A can never load customer B's invoice by guessing an ID.

Each self-serve action is a support ticket that never gets raised. That is how it pays for itself.

Revenue analytics: MRR, churn, and revenue recognition

The number your investors ask for first is MRR (monthly recurring revenue), and ARR is just MRR times 12. But the headline figure hides the story. Break it into new MRR (fresh signups), expansion MRR (upgrades and add-ons), contraction MRR (downgrades), and churned MRR (cancellations). That breakdown is what tells you whether growth is healthy or you are just outrunning a leak.

Watch gross vs net revenue churn. Gross churn counts only what you lost. Net churn subtracts expansion, so a few big upgrades can mask a base that is quietly bleeding. If net churn looks fine but gross churn is climbing, your base is leaky and the wins are covering for it.

Here is the trap your payment dashboard sets: cash collected is not revenue recognized. An annual plan paid upfront in January is INR 12,000 in the bank but only INR 1,000 of recognized revenue that month. The rest is deferred revenue, released month by month.

Razorpay cannot give you any of this. The gateway sees transactions, not subscription state, so MRR, churn, and deferred schedules only exist if your billing layer computes and stores them.

Then feed the accountant. Reconcile recognized revenue to the books by posting into Zoho Books or Tally (invoices, deferred entries, GST), so finance and product agree on one number.

Finally, run cohort retention: group customers by signup month and track how many still pay at month 3, 6, 12. That single report tells you if the product is actually sticky.

Build vs buy: custom vs Razorpay Subscriptions vs Chargebee vs Zoho

Razorpay Subscriptions sits on the rail you already use. It handles the hard part: creating e-mandates (UPI AutoPay, card, eNACH), charging on schedule, and running the RBI-mandated pre-debit notification flow. Plans and basic trials work out of the box. The ceiling shows up fast. Proration is thin, so mid-cycle upgrades and metered usage need your own math. Dunning runs a retry schedule, but you get limited control over its timing and messaging, not the rules-based cadence you would design yourself. And GST invoices are still yours to shape: Razorpay gives the charge event, you build the compliant tax invoice.

Chargebee and Zoho Subscriptions are mature. You get full lifecycle (pause, resume, downgrade), a hosted customer portal, coupons, and MRR/churn analytics without building any of it. The tradeoff is the cost model and where your data lives. Chargebee moves to percentage-of-revenue or per-tier billing that grows as you grow; Zoho is per-tier by customer/user count. Either way your subscription data now lives outside your app, and every report or automation crosses an API boundary.

Custom genuinely wins when proration is complex or metered, when your pricing is product-specific, when billing is tightly coupled to your app, and when a revenue-share bill would hurt at scale. Our PlugEV metered EV-charging billing is exactly the case bought tools handle badly: per-kWh usage, session-level rating, no clean plan fit.

The hybrid most teams should pick: keep Razorpay as the rail and mandate engine, and build the domain layer yourself (lifecycle, proration, dunning rules, GST invoicing, analytics). You own the data without rebuilding payments.

Honest INR ranges: a full custom billing layer (plans, proration, dunning, recurring GST invoicing, a self-serve portal, and MRR/churn analytics) is roughly Rs 6,00,000 to Rs 18,00,000 to build, then low maintenance. A more focused build, scoped to your specific plan and mandate mix rather than the whole platform, is roughly Rs 3,50,000 to Rs 9,00,000 and usually a 4 to 10 week build. A bought tool typically runs about 0.5 to 0.75 percent of billed revenue, or roughly Rs 15,000 to Rs 60,000 and up per month depending on tier and volume (vendor pricing changes, so check the current pricing page). Compare over three years, not month one. At scale, revenue-share overtakes a one-time build.

Decision checklist:

Plan complexity: flat tiers or metered/usage-based?
Mandate mix: UPI AutoPay, cards, eNACH?
GST needs: simple or multi-state, e-invoicing?
Analytics depth: dashboard cards or cohort-level?
Is billing core to your product, or a side feature?

How we build subscription billing, and when we tell you not to

Our default shape is a Node.js backend where the lifecycle (plan changes, proration, dunning retries, reconciliation) is covered by tests, because these are money paths and deserve to be treated like it. That is the core of our Node.js development work.

We ship this from lived work, not theory. The same engine runs metered per-session billing, INR renewals with GST invoices, and per-tenant plans across the products we operate, so the edge cases we describe here are ones we have actually hit and fixed.

The honest part: if you run a single flat plan and a few hundred subscribers, Razorpay Subscriptions is enough, and we will say so. Custom earns its cost once metering, mid-cycle proration, or data ownership make it pay: a focused build scoped to your specific plan and mandate mix (not the whole platform) is usually a 4 to 10 week build at roughly INR 3.5 to 9 lakh.

Frequently asked questions

Should I build a custom subscription billing system or just use Razorpay Subscriptions, Chargebee, or Zoho Subscriptions?

If you run a single flat plan with a few hundred subscribers, Razorpay Subscriptions is genuinely enough and we would tell you not to build. Custom starts to earn its cost when you have metered or usage-based pricing, complex mid-cycle proration, or a reason to keep your subscription data inside your own app instead of a vendor's. The middle path most teams should take is hybrid: keep Razorpay as the rail and mandate engine, and build the lifecycle, proration, dunning, and GST invoicing yourself.

What is the UPI Autopay limit for subscriptions in India, and how do I bill high-value annual plans above it?

UPI Autopay carries an AFA-free threshold of Rs 15,000 per debit: a charge at or below that auto-debits hands-free, while a charge above it is allowed but triggers additional factor authentication (an OTP) on every debit, which defeats hands-free billing. For a high-value annual plan you have two clean options: route it to an e-NACH or card e-mandate, whose per-mandate limits are set at registration and can run well above Rs 1,00,000 (that Rs 1,00,000 figure is the enhanced AFA-free category limit, not a universal e-NACH ceiling), or split the amount into smaller scheduled debits that each stay under the threshold. Your system should pick the mandate type per plan rather than forcing every customer onto one rail.

How do recurring GST invoices work when a customer upgrades or downgrades mid-cycle?

An upgrade adds a new taxable line for the prorated difference, invoiced at 18% GST like any normal charge. A downgrade does not edit the original invoice, because a finalized tax invoice is immutable; instead you issue a GST credit note linked to it, banking the credit against the next cycle rather than refunding cash. In both cases the place of supply (the customer's registered state) decides whether the split is CGST plus SGST or IGST, so capture GSTIN and state at signup.

What does it cost to build a custom subscription billing system in India in 2026?

A full custom billing layer, meaning plans, proration, dunning, recurring GST invoicing, a self-serve portal, and MRR/churn analytics, runs roughly Rs 6,00,000 to Rs 18,00,000 to build, then stays low on maintenance. A more focused build, scoped to your specific plan structure and mandate mix rather than the whole platform, is usually a 4 to 10 week engagement at around Rs 3,50,000 to Rs 9,00,000. Compare either against a bought tool, which typically runs about 0.5 to 0.75 percent of billed revenue, or roughly Rs 15,000 to Rs 60,000 and up per month depending on tier and volume (vendor pricing changes, so check the current pricing page), and do the sum over three years, because revenue-share pricing overtakes a one-time build as you scale.

How do I reduce involuntary churn from failed auto-debits and expired mandates?

Build a retry ladder that spaces attempts out (for example day 1, 3, 5, and 7) and tunes to the failure reason, since insufficient-balance failures often clear near salary dates. Treat the RBI pre-debit notification as your first dunning rung, send reminders across in-app, email, and DLT-registered WhatsApp or SMS, and keep access live through a 7 to 14 day grace window. Detect dead mandates and drop customers into a one-click re-registration flow, then track recovery rate per retry day so you can see the MRR you save.

Can I keep Razorpay for payments but build the subscription and billing logic myself?

Yes, and this is the setup we recommend for most growing teams. Razorpay stays as the rail and mandate engine, handling e-mandate creation, scheduled charges, and the pre-debit notification flow, while you build the domain layer on top: subscription lifecycle, proration, dunning rules, GST invoicing, and revenue analytics. You own your subscription data and reporting without taking on the burden of rebuilding payments or PCI-scope card handling.

The honest summary: this layer gets built either way, on purpose or by accident, and the accidental version is the one that leaks money quietly. If you want a straight build-vs-buy call for your specific plan structure, mandate mix, and GST footprint, talk to us and we will give you the real answer, even when it is "just use Razorpay Subscriptions."

DLT-Compliant Notification Service Architecture in India (2026): SMS, WhatsApp, and Email Without Silent OTP Failures

Ravi Rai — Fri, 17 Jul 2026 15:11:51 +0000

Every Indian SaaS team eventually hits the same wall. Your notification code works fine in staging, ships to production, and then one Tuesday a customer calls support because the OTP never arrived. You check the gateway dashboard. Delivered. You check your application logs. 200 OK. Nothing in your stack disagrees with anything else in your stack, and yet the message is not on the handset.

This post is about the layer that sits between your domain events and your SMS gateway, the one nobody sells you and everybody ends up building by accident. It covers the template registry that makes DLT drift a build failure instead of a 2am incident, the idempotency discipline that stops failover from double-sending OTPs, the channel ladder that crosses from Meta's approval regime into TRAI's without anybody noticing, and the reconciliation job that finally answers whether the message landed.

We are writing this from production, not from a vendor doc. We run these flows on MultiVendor CRM (lead and order alerts) and PlugEV (session start/stop, payment receipts). The architecture below is the one we maintain, including the parts where we tell you not to build it.

Delivered in Our Logs, Never on the Handset

The project always starts with the same ticket. A customer swears the OTP never came. Your gateway dashboard shows DELIVERED. Your application logs show 200 OK from the send call. Three systems agree, and all three are wrong. Nobody is lying, they are each reporting on a different hop, and none of them can see the handset.

In our experience, the failure is almost always one of three things. Template drift: someone edited the marketing copy in the DLT portal, the variable count changed, and the operator now silently rejects a message your gateway still acks. Header category mismatch: a transactional OTP going out on a promotional header, then getting swallowed by DND filters for exactly the users who complain loudest. A fallback rung that never fired: your code has a WhatsApp retry, but the SMS provider returned a soft success, so the retry never triggered. Each of these has a design answer, not a checklist item.

There is a fourth failure mode, and this one is written into the regulation itself. Clause 8(e) of the 18 November 2025 TRAI Direction mandates a "logger mode" for the first sixty days from the start of variable-tag scrubbing: during that window, messages that fail variable-tag validation (the pre-tagging checks we cover below) are still delivered, after the operator generates a fault message, and only after the sixty days are failing messages rejected outright. Read that again. The regulator required a period where broken templates keep landing on handsets while quietly generating faults you never see, and clause 8(f) puts the duty to identify and notify the affected Principal Entity on the Access Provider, not on you. That is the green-dashboard, broken-system pathology this whole post is about, except mandated by law, which means your gateway may have been sitting on fault messages about your templates that you were never shown. When scrubbing crosses its sixty-day mark, those same messages stop being delivered. If you did not fix them during logger mode, they fail hard on the day the grace ends.

Scope, plainly. This assumes you already have an entity ID, a registered header, and a gateway account. Registration is your vendor's blog post, not ours.

The thesis: your SMS vendor cannot sell you the queue, the template registry, the idempotency layer, or the reconciliation job. You own that layer whether you designed it or it grew by accident.

DLT Is a Schema Constraint, Not Paperwork

Treat DLT like a database migration, not a GST filing. A filing is something you do once and forget. A migration is something your code knows about, your CI enforces, and your deploy fails on when it drifts. DLT decides the shape of your message payload: which header sends it, which template ID it must match, how many variables it carries, and where they sit in the string. That is schema. It belongs in your codebase, not in a spreadsheet somebody's ops lead maintains.

Six layers own six different things, and most broken systems have collapsed all six into one controller. The domain event says OrderShipped and nothing more. The notification intent decides this event deserves a message and who receives it. The channel policy picks SMS, WhatsApp, or email based on regime (transactional OTP versus service-explicit promo) and consent state. Template resolution maps intent plus channel plus locale to a registered DLT template and its variable slots. The provider adapter speaks one gateway's HTTP dialect. DLR reconciliation closes the loop and tells you it actually landed.

Your domain code should never know a Template ID exists. The moment checkout_controller.py contains "1707161234567890123", you have lost. We see this in almost every audit: bare string literals pasted across controllers, no registry, no single call site. When an operator rejects a template, nobody can grep their way to every usage, so the fix ships partial and OTPs keep failing for the one path someone missed.

The PE to telemarketer binding chain is deploy-time configuration, not application logic, and it helps to know why. On every message the operator's scrubber validates five things: your PE ID, the header, the content template ID, the PE-to-telemarketer binding chain, and the recipient's DND status. Four of those five are static config for a given deploy, which is exactly why they belong in typed config that fails loudly on boot, not env-var soup that fails silently at 2am. Entity ID, header, and template IDs go in that config. And if you are building multi-tenant, each tenant may carry its own entity ID and header, so make the registry tenant-aware on day one rather than retrofitting it under load.

The Template Registry: Your Approved Body, in Version Control, Checked by CI

Check the operator-approved body, character for character, into version control next to the code that renders it. This is the single highest-leverage move in this post.

The shape to copy is a registry object keyed by domain name, not by template ID. otp.login, order.shipped, payment.failed. Each entry holds the templateId the operator issued, the registered body string exactly as approved, the declared variables with their types, the category (transactional, service-implicit, promotional), and the registered header. One file. Greppable. When a backend dev asks "which sender ID does the OTP go out on," the answer is a single search, not a Slack thread with your gateway account manager.

The CI test that earns its keep renders each template with fixture values, then asserts the static text matches the approved body exactly. Not fuzzy, not trimmed, not normalized. A stray double space between "OTP" and "is" fails the build. A PM changing Rs. to INR in a "harmless copy tweak" fails the build. A smart quote pasted out of a Google Doc, the one that renders identically in every editor you own, fails the build. All of these otherwise fail at the operator's scrubber instead, at 2am, silently, on your live login flow.

This is why the registry beats the checklist posts already ranking for this. "Fix your template mismatch" is reactive advice you apply after production breaks. A CI assertion makes drift structurally impossible to merge. Same problem, one level up.

Registry-level validation also catches the variable ceilings at build time. Under the pre-tagging regime this post is about, limits are per tag, not a single global 30-character ceiling. The Direction's Annexure-I caps #alphanumeric# at 40 characters in scrubbing ("Not more than 40 Characters will be allowed in scrubbing"), while #cbn# runs 3 to 14 and #url# allows 120 (TRAI Direction, 18 Nov 2025, Annexure-I). That is exactly why the type belongs in the registry entry: one ceiling per slot type, asserted in CI. And length is not even the sharp edge. #alphanumeric# is specified as letters and numbers only, so a customer named "Venkataraman Subramanian", well under any length limit, still fails type validation on the space in the middle, and a hyphenated order ID fails on the hyphen. Those become failing tests instead of an incident and a refund.

The registry also has to assert two rules that predate pre-tagging and that most checklist posts miss entirely. First, variable count: the number of variable portions in a content template is capped at two, a third allowed only for reasons recorded as an exigency, and more than that only on written requisition with justification from the Principal Entity. Second, adjacency: variables must be non-contiguous, never placed back to back and never separated only by a space, comma, or other special character. Both come from TRAI's 16 February 2023 Direction, recounted in the 18 November 2025 Direction. Put a variable-count assertion and an adjacency check in the same CI test that matches the body, and a template that quietly grows a third variable in a copy edit fails the build instead of the scrubber.

Version the registry deliberately. When an operator approves a new body, it lands as a PR with a reviewable diff, which means you can revert a bad template as fast as you shipped it.

Typed Variables: TRAI's 2026 Pre-Tagging Is a Type System Now

Pre-tagging is not new, and getting its history right matters for how you plan around it. TRAI directed variable pre-tagging back in its 12 May 2023 Direction, and the principle is already written into item 4(3) of Schedule-I of the TCCCPR 2018: each variable in a message template should be pre-tagged for the purpose it is proposed to be used. The reason the 18 November 2025 Direction exists at all is that, in TRAI's own words at para 7(a), the earlier directions "have not been implemented till date" (see also TRAI Press Release 133/2025). The 2025 Direction universalises tagging to every variable field and attaches a hard rejection date. So the industry got roughly two and a half years of grace, and what expired in 2026 was the grace, not the rule. Most coverage treated this as a registration chore. It is not. It is a schema change to your application.

The dates are widely misreported, so pin them to the Direction. Clause 8(c) requires all new content templates registered after ten days from the date of issue, that is from 18 November 2025, to be pre-tagged. Clause 8(d) gives the remaining, older templates sixty days to comply, and the clock starts from when your operator begins variable-tag scrubbing, not from any template's registration date and not from a fixed calendar deadline. Gateways reported scrubbing commencing around mid-January 2026, which put the practical migration deadline near mid-March 2026. The "14 January 2026" date circulating in vendor posts is at best the day operators started scrubbing, not a TRAI deadline, so confirm your operator's actual scrubbing start date with your gateway.

The six tags are types, and your template abstraction has to carry them. #numeric#, #alphanumeric#, #url#, #urlott#, #cbn#, #email#. One nuance worth reading the Direction for rather than a vendor summary: Annexure-I writes the first as "#number# / #numeric#", so check which spelling your operator's portal actually accepts (TRAI Direction, 18 Nov 2025, Annexure-I). Before pre-tagging, a variable was a hole you dropped a string into and the operator's scrubber sorted it out. Now every slot has a declared type that lives on the operator's side, and your code has no idea about it unless you put it there.

Declare the type in your template registry and validate at the boundary. If your registry entry for ORDER_CONFIRM says slot 2 is #numeric#, that fact belongs in the entry, enforced with Zod or whatever you already use. Then a bad send throws inside your process, with a stack trace, at the call site. The alternative is finding out from a delivery report the next morning, or worse, from a customer.

Here is the bug this catches. You register a slot as #numeric# because your fixtures are 4471. Production order IDs are ORD-4471. Staging is green, production OTPs and confirmations quietly die at the scrubber, and nothing in your logs says "type rejection" because the rejection happened at someone else's shop.

URLs are the sharp edge. #url# and #urlott# are not interchangeable, shortened links and UTM parameters interact badly with whitelisted-domain rules, and the failure is invisible from your side. When marketing swaps the shortener next quarter, your template breaks and nobody connects the two events.

Pre-tagging is a code-layer change. That is exactly why the gateways who sent migration notices could tell you it was coming, but not what to refactor.

Header and Category Routing: The Choice That Silently Kills DND Delivery

The failure mode here looks like nothing at all. Register a header under the wrong category and your OTP is legally a promotional message. Every subscriber with DND active never sees it. The gateway still returns a message ID, your service still logs sent, your dashboards stay green, and your error rate is zero. Nothing in your stack ever says blocked. You find out from support tickets about users who cannot log in, weeks late. Hundreds of millions of Indian numbers carry a DND preference (NCPR registrations past 230 million), so even at a conservative share this is a large, silent slice of your delivery, not an edge case.

Category belongs in the registry as a routing decision, never in a vendor dashboard. Every template row declares its category and resolves to exactly one header. The router reads that at lookup time and refuses to put an OTP on a promotional header. A toggle somebody flipped in a gateway console six months ago is not a system, it is a rumour.

Untangle the three names before mapping anything. Service Implicit, Service Explicit, and Transactional are not what most backend teams assume. In developer speech "transactional" just means "not marketing". Under DLT rules, Transactional is a narrow category restricted to banks sending OTPs and account alerts, open to national, scheduled, private, government, and MNC banks and nobody else. Most order updates and shipment alerts, and every OTP from a non-bank product, are Service Implicit, not Transactional. We have seen teams register everything as Transactional and then wonder why traffic gets filtered.

Consent is data, not a checkbox. Service Explicit means producing the record on demand, so store principal, timestamp, source (which form, which screen, which IVR flow), scope, and revocation state. Those records and the message bodies are personal data under a second regime, which we cover in our DPDP compliance guide.

Our build rule: one header per category, wired into the registry, resolved at lookup. If a template has no header for its category, the build fails instead of production.

The Channel Ladder, and the Regime Boundary Nobody Designs For

When your OTP falls from WhatsApp to SMS, it does not just change transport, it changes jurisdiction. The WhatsApp rung lives under Meta's utility template rules, approved by Meta. The rung directly below it lives under TRAI's DLT regime, approved through your operator's DLT portal via your gateway. Two templates, two approval bodies, two sets of failure modes, aimed at the same user in the same second. Most notification code we inherit treats that boundary as a config flag.

The design consequence: your fallback rung needs its own registered DLT template and header, approved before you ever need it. Teams learn this mid-incident. WhatsApp goes flaky at 9pm, someone reroutes OTPs to SMS, and the gateway rejects every send because there is no approved template ID and no registered Service Implicit header for that content. A new content template is typically one to three working days to approve, and a header you do not already have adds one to two more, so the full path from nothing to a live fallback runs closer to three to seven working days. Your incident does not wait that long.

The ladder we actually build: WhatsApp utility template, then SMS on a Service Implicit header, then email. Transactional if you are a bank, Service Implicit for everyone else, which is most readers, and neither MultiVendor CRM nor PlugEV is a bank. Each rung owns its own entry in the template registry, its own timeout, and its own delivery contract. The registry is what makes the regime boundary explicit in code instead of leaving it in one engineer's head.

Do not ladder on optimism. WhatsApp "sent" is not "read", and silence is not failure. Define the promotion signal explicitly: a failed status callback, or no delivery confirmation inside N seconds. Then cap total attempts, or a flapping provider fans out four messages to one user, who now holds four OTPs and trusts none of them.

Cost asymmetry is real and it changes the design. Since 1 July 2025, WhatsApp bills per delivered template message, not per conversation, and the old "utility conversation" billing unit is gone (Meta pricing updates). Utility templates sent inside an open customer-service window are free, while authentication templates are billed even inside that window, which is the opposite of the asymmetry most teams assume. Your OTP rung is precisely the category that never rides the free window. We will not quote rates we cannot defend, but the model is a fact: authentication is metered, so model the ladder at your real volume before you tune timeouts down.

For the platform layer underneath the architecture, see our WhatsApp Business API guide and the WhatsApp CRM setup post.

The Queue: Mint the Idempotency Key Before the Provider Call

Mint the idempotency key before the provider call, not after the response. Everyone gets this backwards. If you wait for the provider to hand you a message ID and then store it, the window where you have already sent but recorded nothing is exactly the window where the timeout happens. Key on (event_id, channel, recipient) with a unique constraint in Postgres, insert first, send second. The insert is your permission slip to call the provider.

A duplicate OTP is worse than a missing one, which is why this matters more here than in most systems. The second SMS invalidates the first, so the user is now typing a code your backend has already retired, and they blame your app, not your gateway. Provider timeouts and cross-provider failover are precisely the conditions that produce double sends, so failover without a claimed key is a bug generator. Same discipline we wrote up in Razorpay webhooks, idempotency and reconciliation, and the same one we use for OCPP transaction dedupe on PlugEV: OCPP 2.0.1 security and transaction reconciliation.

Retries need a policy, not a for-loop. Exponential backoff with jitter, capped attempts, and a dead letter queue a human actually opens on Monday. Split retryable failures (5xx, connection timeout, gateway 429) from terminal ones (template rejected, invalid number, scrubber block). Retrying a scrubber rejection just burns INR credits at machine speed and teaches you nothing.

OTP gets its own rules. Rate limit per recipient and per IP. Treat a resend inside the validity window as an idempotent read of the existing OTP, not a fresh mint. The user pressing "Resend" three times should cost you one SMS.

BullMQ on Redis is an honest default at Indian SMB volume. In our own load tests on these builds it stops being enough somewhere past sustained five-figure messages per minute, or when you need replayable event history across teams, or when Redis memory becomes your ceiling. Most startups reaching for Kafka on day one are buying ops load, not throughput.

Provider Adapters: Making MSG91, Kaleyra, and Exotel Swappable Rungs

Your gateway will never write this section. Their docs are built to make their SDK the center of your notification stack, because a vendor whose API is one rung in a ladder you own is a vendor you can replace. That is exactly what we build for clients, and it is the part of the architecture that has the clearest commercial payoff.

The adapter interface is deliberately small: send(templateKey, vars, recipient) returns a providerMessageId. Everything DLT-specific resolves in your layer before the adapter is called. Entity ID, template ID, registered header, and category come out of your template registry, not out of vendor config. The adapter translates your normalized payload into the vendor's request shape and does nothing else. No retries, no logging decisions, no template lookups. In our builds, if an adapter file is longer than roughly 150 lines, DLT logic has leaked into it.

What actually differs between vendors is narrower than it looks. MSG91, Kaleyra, Exotel, and 2Factor diverge on four things: auth scheme (header key vs bearer vs query param), parameter naming (template_id vs dlt_template_id vs tid), DLR webhook payload shape, and error taxonomy. The first three are mechanical. The fourth is where teams bleed. Normalize every vendor error into your own enum at the adapter edge, something like INVALID_TEMPLATE, DND_BLOCKED, RATE_LIMITED, TRANSIENT, AUTH_FAILED. Your retry policy then gets written once, against your enum, instead of five times against five vendors' string codes.

Failover works because the idempotency key spans providers, not attempts. When provider A times out at the socket, the retry through provider B carries the identical key. Your outbox already knows a send is in flight for that key, so the second attempt is a continuation, not a new message. Without this, every failover is a double-OTP and an angry support ticket.

The honest caveat: swapping providers still means re-binding templates through the new telemarketer chain. A pure re-bind of already-approved templates through the delivery telemarketer's regulatory team is typically thirty to sixty minutes to a few hours, not seconds. A template that has to be re-registered rather than re-bound is one to three days on top. Either way it is not the config-flag switch vendors imply. Anyone selling you instant provider migration is selling a fantasy. Build the adapter layer anyway. Two things make it worth it. You get real leverage in rate negotiations, because a vendor who knows you can leave prices differently than one who knows you cannot. And you get an exit that exists, which matters the week your provider has an outage during a sale.

DLRs Are an Accounting System, Not a Dashboard

Treat delivery receipts like a ledger, not a webhook you eyeball. The handler does three things: verify the signature or shared secret, write the raw payload to a receipts table, return 200. Everything else happens in a worker. A DLR handler that takes 4 seconds because it updates six rows and pings Slack will make the provider retry, and now the data you built the whole system to trust is polluted with duplicates you caused yourself.

Dedupe on the provider's message ID and never trust ordering. DLRs come out of order, arrive twice, and occasionally show up for a message you sent last Tuesday. A DELIVERED landing after a FAILED for the same ID is normal, not a bug. Store the receipts append-only, then fold them into a current status with an explicit precedence rule, so replaying the table always yields the same answer.

The reconciliation job is where the delivered-but-never-received bugs finally die. Run a daily sweep across three columns: what we sent, what the provider says was delivered, and what the user actually did (OTP verified, link clicked, order page opened). Column one versus column two is the vendor's story. Column two versus column three is the truth, and no gateway dashboard will ever show you that gap, because the gateway cannot see your verify events.

Alert on OTP verify-rate sliced by template and by operator, not raw send counts. Sends stay flat while a rejected template quietly drops everything on one operator. Verify-rate cliffs hours before your first support ticket, usually overnight when nobody is watching sends anyway.

Set retention deliberately, and do not run one clock for everything. Split the table by what the data is. Message bodies and the phone numbers you sent to are personal data under purpose limitation, so erase them once the purpose they were collected for is served. Your processing logs, the send logs and DLR receipts themselves, are a different animal: under the DPDP Rules 2025 they carry a one-year minimum retention for forensic and investigative purposes before you may erase them. So a naive 90-day purge on the receipts table is not a privacy win, it is a compliance bug that can put you under the statutory floor. Do not reach for a single fixed clock. Enforce the two rules separately in the job, and keep the reasoning next to our DPDP compliance guide.

Email: The Channel With No DLT, and the Trap That Creates

Email has no DLT registry, and that is exactly why teams get burned by it. No approval queue means no forcing function, so the discipline you built for SMS quietly gets skipped. Then your OTP lands in Promotions, or a receiving MTA rejects it on DMARC policy, and you have the same silent failure as a template mismatch with a different root cause and no gateway dashboard to blame it on.

Treat email as a peer channel, not an escape hatch. Same template registry with versioned bodies, same idempotency key so a retry does not double-send, and the DLR equivalent is your bounce and complaint webhooks. Nobody approves your body first, so your registry is the only place drift gets caught.

The deliverability floor is not optional. SPF, DKIM, and DMARC alignment on the sending domain, plus Gmail's bulk-sender rules, which bind any sender of 5,000 or more messages a day to Gmail addresses: SPF and DKIM both, DMARC on the sending domain, a one-click unsubscribe on marketing mail, and a user-reported spam rate kept under 0.1 percent (Gmail sender guidelines). The honest caveat for an Indian OTP sender is that you may sit under 5,000 a day to Gmail specifically, so the bulk tier may not bind you, but SPF and DKIM are expected of every sender regardless of volume.

Email is the right last rung and the wrong first one. Cheap, no approval regime, slowest to arrive, least reliable for auth. Never put it above SMS in an OTP ladder.

What to Build First, and When to Just Use the Vendor SDK

Stage this honestly, because the order decides whether you waste a month. Build the template registry and the CI character-match first. It was about a week of work for us on PlugEV, including the fixture set, and it kills the most expensive bug on the list: template drift silently dropping OTPs while your dashboard says everything is green. Second, the idempotent queue, so a retry never double-charges a customer's patience with two OTPs. Third, provider adapters and the reconciliation job. Reconciliation last is deliberate. You cannot reconcile deliveries you are not yet sending correctly.

Now the part that argues against our own invoice. If you send low volume on one channel through one vendor, use their SDK and go. Seriously. The queue, the registry, the idempotency layer, none of it earns its cost at that size. This architecture starts paying when you have two channels, or two vendors, or real revenue sitting behind a single OTP that has to land in eight seconds.

Where you are decides what you need. OTPs cratering right now, that is a delivery-failure audit. Already patching and want it to stop recurring, that is an OTP hardening sprint. Pre-launch and scoping, that is a notification service build.

Frequently asked questions

Our gateway dashboard says the SMS was delivered, but the customer never received it. What is actually going on?

The dashboard is reporting on the hop it can see, which is usually the handoff to the operator, not the handset. The three usual culprits are template drift (an edited body no longer matches the registered template, so the operator's scrubber drops it), a category mismatch (a transactional OTP riding a promotional header, filtered for every DND subscriber), or a fallback rung that never fired because the provider returned a soft success. The only way to know which one is to compare what you sent against what the user actually did, which means a reconciliation job, not a dashboard.

Do we need a separate DLT template and header for the SMS fallback when a WhatsApp message fails?

Yes, and you need it approved before the incident, not during it. The WhatsApp rung is approved by Meta under its utility template rules; the SMS rung below it is approved through the DLT portal under TRAI's regime. They are two different templates governed by two different bodies, and a new content template is typically one to three working days to approve, with a header you do not already have adding one to two more. If you build the ladder without a registered fallback template and a registered Service Implicit header, your gateway will reject every send at exactly the moment you need it. Unless you are a bank, that fallback rides Service Implicit, not Transactional.

Can we switch SMS providers (say MSG91 to Kaleyra) without redoing our DLT registration and templates?

Your entity ID, header, and approved template bodies stay yours. A pure re-bind of those templates through the new telemarketer chain is typically thirty to sixty minutes to a few hours, and any template that has to be re-registered rather than re-bound is one to three days on top. Anyone promising instant provider migration is selling a fantasy. What the adapter layer buys you is that the switch is a config change plus a binding wait, not a rewrite of every controller that sends a message. That is worth building for the rate leverage alone.

What changed with DLT variable pre-tagging in 2026, and do our older templates still work?

Pre-tagging itself is not new: TRAI directed it in May 2023 and it is written into Schedule-I of the TCCCPR 2018. The 18 November 2025 Direction exists because TRAI recorded that the earlier directions had not been implemented, so it universalised tagging to every variable field and attached a hard rejection date. Clause 8(c) requires new content templates registered after ten days from the 18 November 2025 issue to be pre-tagged, and clause 8(d) gives older templates sixty days from the start of your operator's variable-tag scrubbing, not from any fixed calendar date. Gateways reported scrubbing beginning around mid-January 2026, which put the migration deadline near mid-March 2026, so confirm your operator's actual scrubbing start date. In practice every variable slot now carries a declared type on the operator's side (#numeric#, #alphanumeric#, #url#, #urlott#, #cbn#, #email#, with Annexure-I writing the first as "#number# / #numeric#"). If your older templates were migrated, they work; if they were not, they fail at the scrubber with nothing useful in your logs. Note that clause 8(e) mandates a sixty-day logger mode from the start of scrubbing, during which failing messages are still delivered after generating fault messages, so a template can look fine right up to the day the grace ends and it starts being rejected outright. Put the types in your template registry and validate at the boundary so the failure happens in your process instead.

Is it worth building our own notification layer, or should we just use our gateway's SDK directly?

If you send low volume on one channel through one vendor, use the SDK and go. The registry, the queue, and the idempotency layer do not earn their cost at that size, and we will tell a client that before quoting them. This architecture starts paying once you have two channels, or two vendors, or real revenue sitting behind an OTP that has to land in eight seconds. The one piece we would build early regardless is the template registry with a CI character-match, because it was about a week of work for us on PlugEV and it kills the most expensive bug on the list.

How do we stop retries and provider failover from sending the same OTP to a customer twice?

Mint the idempotency key before the provider call, not after the response, and key it on (event_id, channel, recipient) with a unique constraint in Postgres. Insert first, send second, so the row is your permission slip to call the provider. When provider A times out at the socket and you fail over to provider B, the retry carries the identical key, so your outbox recognises it as a continuation rather than a new message. Also treat a user pressing "Resend" inside the validity window as a read of the existing OTP, not a fresh mint.

The honest summary

None of this is clever. It is a registry, a queue, a thin adapter, and a job that checks whether the thing you sent actually landed. The reason it is rare is not difficulty, it is that no vendor has a reason to sell it to you, so it gets built in fragments during incidents and never gets a name.

If your OTPs are failing right now, start with the reconciliation query, not the refactor. Find the gap between what your provider says it delivered and what your users actually verified. That number tells you which of the three failure modes you have, and it usually takes an afternoon.

If you would rather have someone who has done this a few times look at it with you, we do delivery-failure audits, OTP hardening sprints, and full notification service builds. Flat INR quotes, GST invoice, no fear-selling. Get in touch, or run the cost calculator if you want a build estimate first.

Zoho Books Integration in India (2026): Connect Your Website, Store, or CRM to Your Books, What It Costs, and Build vs Buy

Ravi Rai — Tue, 14 Jul 2026 09:23:37 +0000

Most Indian SMBs do not have a Zoho Books problem. They have a gap between the system that takes orders and the system that keeps the accounts, and a person stuck filling that gap by hand. The store sells all day. Zoho Books holds the real books, the GST returns, the invoices the CA signs off. Between them sits someone with two browser tabs, copying order details from one into the other.

That copy-paste job is cheap at ten orders a day and expensive at eighty. It is where wrong GSTINs creep in, where invoices go missing, and where the month-end numbers stop tying out. "Zoho Books integration" is just the fix: wire the two systems so an order becomes an invoice, a payment gets recorded against it, contacts stay in sync, and IRN details land back in the record, with nobody re-keying any of it.

This guide covers how Zoho Books actually connects (its cloud REST API and webhooks), what you can realistically sync, the three ways to build it, honest 2026 rupee costs, a real order-to-invoice build we shipped, and how to scope the work before you pay anyone. We integrate both Zoho Books and Tally, so the advice here is about fit, not brand loyalty.

Why this comes up: your store sells, Zoho Books keeps the books, nobody connects the two

Your storefront takes orders all day. Zoho Books holds the actual accounts, the GST returns, the invoices your CA signs off on. Between them sits a person with two browser tabs.

The re-keying tax. Someone opens the store or CRM, reads an order, then retypes it into Zoho Books as an invoice. Customer name, GSTIN, line items, HSN codes, tax split. It works fine at ten orders a day. At eighty it breaks: wrong GSTINs, missed invoices, numbers that do not match at month end.

Who feels it worst. D2C and e-commerce stores pushing volume off Shopify or WooCommerce. B2B distributors raising large invoices with strict GSTIN requirements. Subscription SaaS billing on renewal. Service firms running a CRM (Zoho CRM, HubSpot, Pipedrive) right next to Zoho Books.

What people actually mean by "Zoho Books integration" is usually five flows: an order becomes an invoice, payments received get marked against it, contacts sync both ways, inventory counts down, and e-invoice/IRN details land back in the record. Nobody re-keying any of it.

Two things this is not.

One, this is not accepting payments. Collecting the money is a separate job (see our accept payments in India and Razorpay integration posts). Integration here means booking the record into the books after the money has already moved.

Two, this is not rebuilding the e-invoice portal. Zoho is a registered GSP and files IRNs for you (we cover that in our GST e-invoicing post). You are wiring your systems to Zoho, not to the IRP.

The audience is large because Zoho Books is one of the most widely adopted GST accounting tools for Indian SMBs.

How Zoho Books actually connects: OAuth 2.0 REST API and webhooks, in plain words

Zoho Books is cloud SaaS, so you connect to it the same way you connect to any web service: over HTTPS, sending and receiving JSON through a REST API. There is no local server to install and nothing that has to stay open on an office desktop. This is the clean break from Tally, where the machine running it usually has to be switched on and reachable. With Zoho Books, your website or app just makes an API call from wherever it is hosted.

Watch the data center. An Indian Zoho org lives on the .in domain. That means you authenticate against accounts.zoho.in and hit the India API domain (www.zohoapis.in), not the .com ones. Using .com credentials against an .in org is the single most common first-day mistake we see, and it fails in confusing ways because the login looks fine but the tokens do not work.

OAuth 2.0, minus the jargon. In the Zoho API console you register either a self client (for a single backend) or a server-based app. You exchange that for an access token (short lived) and a refresh token (long lived, used to silently mint new access tokens). Ask only for the scopes you actually need, for example ZohoBooks.invoices.CREATE, not blanket full access.

organization_id is mandatory. Nearly every call needs the organization_id of the specific Zoho Books org you are writing to. Your middleware has to store and pass this, especially if one client runs multiple GST entities.

Webhooks keep things in sync. Instead of hammering the API to ask "any new invoices yet?", you register a webhook so Zoho Books pushes events to you when something happens (invoice created, payment recorded). That is how two systems stay current in near real time.

Respect the limits. API calls draw on daily credits and rate limits that are capped per plan. A naive "sync everything on a loop" job will burn through them fast, so design for incremental sync and webhooks from day one.

What you can actually sync (the real integration jobs)

Contacts and customers. Every integration starts here. When your site or CRM creates a customer, push them into Zoho Books with the GSTIN, billing state, and place of supply set correctly. Get the place of supply wrong and the tax computes wrong: intra-state throws CGST plus SGST, inter-state throws IGST. We map the shipping state to place of supply and validate the GSTIN format before the call, so bad data never hits your books.

Sales orders and invoices. This is the core of connecting a website to Zoho Books. A paid order on Shopify, WooCommerce, or a custom app becomes a Zoho Books invoice automatically, with the right line items, HSN codes, and tax rates. Trigger on payment success, not cart creation, so you never invoice an abandoned order.

Payments received and reconciliation. Recording the invoice is half the job. We then log the payment received against that invoice and match it to the gateway settlement (Razorpay, Cashfree, PayU) so your Zoho Books balance ties out to what actually landed in your bank after fees.

Items and inventory. Pushing stock levels and prices one way is straightforward. Two-way inventory sync is where most projects get messy: two systems both claiming to be the source of truth, race conditions, oversells. Pick one master and treat the other as read-only.

E-invoicing and IRN. You do not build IRP integration from scratch. Zoho Books is a registered GSP, so you push a clean invoice and it generates the IRN and signed QR code for you (contrast our from-scratch e-invoicing post, which is far more work). Your job is sending correct data, not talking to the IRP.

The extras teams forget. Budget for credit notes (returns and refunds), e-way bills, recurring invoices for subscriptions, and TDS/TCS fields. A typical connector build runs roughly Rs 40,000 to Rs 90,000 for a simple one-way build, and Rs 1.5L to Rs 4L+ for a full two-way build, depending on how many of these you need.

The three ways to connect: prebuilt app, iPaaS, or custom API middleware

There are really only three ways to get your website, store, or CRM talking to Zoho Books. Pick by how standard your setup is, not by what looks cheapest on day one.

1. Prebuilt marketplace connectors. Zoho and third parties publish ready apps for Shopify, WooCommerce, and similar platforms. This is the fastest path when your store is standard and your fields map cleanly: order comes in, invoice gets created, contact syncs. Setup can be a same-day job. But a prebuilt connector is just someone else's middleware. You inherit their field mapping, their sync rules, and their roadmap. If they do not support your GST edge case, you wait.

2. iPaaS and low-code. Zoho Flow (bundled with some Zoho One plans), Zapier, and Make let you wire a website to Zoho Books with clicks. Pricing is per task or per operation, so a low-volume flow can run for a few thousand rupees a month. Good for simple, one-directional flows: form submission to contact, order to draft invoice. It gets expensive and fragile once you need branching logic, retries, or high order volume.

3. Custom middleware on Node or Laravel. This is our default when the flow is non-standard. You get full control over field mapping, retry and idempotency logic, and the GST handling that actually matters here: place-of-supply, CGST/SGST vs IGST split, HSN codes, and IRN/e-invoice sync.

Honest fit test: standard store plus standard fields leans prebuilt or iPaaS. Custom logic, high volume, or multiple systems leans custom.

We usually reach for custom on Indian SMB jobs for three reasons: odd GST cases the connectors do not model, multiple stores feeding one Zoho org, and pipelines where CRM plus store plus books all need to stay in sync. When any of those are true, the "buy" option quietly turns into a build anyway, just on someone else's terms.

Build vs buy: the honest economics

There are three real paths, and the right one depends on how weird your process is.

Buy a connector. A ready-made app from the Zoho Marketplace or a third party runs roughly Rs 1,000 to Rs 4,000 per month and you can be live in a day or two. The catch: it books orders the way the vendor assumes you work. If your GST logic, SKU mapping, or invoice numbering does not match their template, you are stuck editing entries by hand every day.

Use an iPaaS. Tools like Zapier, Make, or Pabbly connect your store to Zoho Books on a subscription plus a task or operation limit. Cheap to start (Rs 1,500 to Rs 6,000 per month), but the bill climbs with volume, and every edge case (partial refunds, credit notes, place-of-supply changes) turns into a fragile multi-step flow that breaks quietly.

Build custom. A direct integration against the Zoho Books API is a one-time cost, usually Rs 40,000 to Rs 90,000 for a simple one-way build, and Rs 1.5L to Rs 4L+ for a full two-way build, depending on scope, plus a small maintenance line for when Zoho or your store updates their API. You own the code and, more importantly, the field mapping.

The decision rule we use with clients: buy for a standard store with standard fields and simple GST. Build when you have custom logic, two or more systems talking to each other (store plus CRM plus books), or unusual GST handling like SEZ, reverse charge, or mixed HSN rates.

Judge total cost of ownership, not the sticker price. A cheap connector that mis-books GST, wrong place of supply or a tax head split incorrectly, costs you far more at GSTR-1 and GSTR-3B filing time than a build that gets it right the first pass. Fixing a month of bad entries is not free.

We walk through this same logic for Tally integration and for how to vet an integration agency before you sign anything.

What Zoho Books integration costs in India, 2026 (INR, honest ranges)

Start with the base subscription. You are integrating into a Zoho Books plan, so that cost comes first. As of 2026, Zoho Books India plans run roughly Rs 749 (Standard), Rs 1,499 (Professional), and Rs 2,999 (Premium) per month when billed annually, all exclusive of 18% GST. Prices change, so check Zoho's official India pricing page. The API is the same across paid tiers, but webhook limits and user seats differ, so pick the plan for the feature, not for the integration.

Prebuilt marketplace connector. For common jobs like WooCommerce or Shopify to Zoho Books order-to-invoice, a ready connector from Zoho Marketplace or a third party typically costs Rs 1,000 to Rs 4,000 per month. That buys order sync, contact creation, and basic tax mapping. It does not buy custom GST logic or e-invoice edge cases.

iPaaS (Zoho Flow, Make, Zapier). Budget Rs 1,500 to Rs 6,000 per month, and watch the task math. Every order that fires 3 to 5 steps (create contact, create invoice, record payment) burns 3 to 5 tasks. At 500 orders a month that is 2,500 tasks, which pushes you off the cheap tier fast. Do the multiplication before you commit.

Custom API integration (one-time). A simple one-way order-to-invoice build runs roughly Rs 40,000 to Rs 90,000. A full two-way build with inventory sync, payment reconciliation, and e-invoice/IRN generation is closer to Rs 1.5L to Rs 4L+, depending on entity count and edge cases.

Ongoing maintenance and AMC. Our typical AMC is about 12 to 18 percent of build cost per year, or a Rs 5,000 to Rs 15,000 per month retainer. Zoho ships API changes and rotates OAuth tokens, so someone has to watch it.

Hidden costs buyers miss. Refresh-token failures silently stop sync until someone re-authorizes. Rate-limit backoff needs retry queues. Reconciliation reports (what synced versus what did not) are real dev hours. And you need a staging org separate from production, which is a second subscription most people forget to budget.

A real build: order-to-invoice plus payment sync for a D2C store

Here is a build we shipped for a Shopify store on Razorpay. The pattern holds for WooCommerce or a custom checkout too.

The flow. The store fires an order/paid webhook. Your middleware (a small Node or Laravel service) does not talk to Zoho Books right then. It validates the signature, drops the event on a queue (Redis or SQS), and returns 200 fast. A worker picks it up and writes to Zoho Books. Keep the webhook handler dumb and the worker smart.

Idempotency first. Store the Razorpay payment_id (or Shopify order id) with a unique constraint before you process. A retried webhook then hits the same key and exits early instead of raising a second invoice. We wrote up the webhook and reconciliation details in our Razorpay webhooks post, and the same discipline applies here.

Contact mapping. Before the invoice, find-or-create the customer in Zoho Books. Match on email or phone, then set GSTIN and place of supply on the contact. Place of supply decides CGST+SGST vs IGST, so a blank value here quietly produces wrong tax.

Invoice and payment. Create the invoice, then record a payment against it (customer payment linked to that invoice), and write the returned Zoho invoice_id back onto your order row. That id is your audit trail when finance asks why numbers differ.

Reliability plumbing. Retries with exponential backoff, a dead-letter queue for events that fail after a set number of attempts (5 in this build), structured JSON logs with the order id on every line, and a daily reconciliation job that counts store orders against Zoho invoices.

Where it breaks in production. The OAuth access token expires every hour, so refresh it. You will hit Zoho API credit limits on big sale days. Blank place of supply gives wrong GST. And a webhook is delivered at least once, never exactly once, so idempotency is not optional.

Zoho Books vs Tally: which one to integrate with

The two systems are wired in opposite ways, and that shapes everything about the integration. Zoho Books is cloud-native: you talk to it over a REST API with OAuth tokens, and it can push events back to you through webhooks. Tally is a desktop XML gateway: you POST XML requests to a local machine on port 9000 and read XML back. If you want the full picture on the Tally side, we wrote it up here: Tally integration with your website or custom software.

That difference drives availability. Cloud Zoho Books answers 24x7 from anywhere. On-prem Tally is only reachable while that specific PC is switched on, TallyPrime is open, and it sits on the same network or a tunnel. Miss any of those and the sync silently stalls.

Ecosystem pull favours Zoho if you already live there. Zoho Books snaps into Zoho CRM, Zoho Inventory, and Zoho Flow with almost no glue code, which is why Zoho Books CRM integration is a common ask from Indian SMBs running the Zoho One suite.

But be honest about the install base. Tally remains very widely used for Indian accounting, and your CA probably files GST from it. The right answer is usually whichever system your accountant already trusts, because that is where the real books live.

This is not a religious war. We integrate both. The decision is about where your data of record sits today, not brand loyalty. One more thing: when a team migrates Tally to Zoho Books, the integration surface gets simpler (one cloud API, no local machine to babysit). We flag that when the migration effort is worth it and when it is not.

Common mistakes and GST edge cases we see

Wrong data center domain. Indian Zoho accounts live on .in, not .com. If your token endpoint says accounts.zoho.com but your org is on www.zohoapis.in, every call 401s and you burn an afternoon blaming the scopes. Match the domain to where the account was created, and store it as config so staging and prod can differ.

Token handling. The access token expires in about 1 hour. We still inherit projects where someone pasted a live token into code. It works in the demo, then dies overnight. Store the refresh token securely, refresh on 401, and never commit either to git.

No idempotency. Zoho retries webhooks, and your queue will replay too. Without an idempotency key (map your order ID to the Zoho invoice ID before you create it), one order becomes three invoices in the books. Check-then-create, or use the reference number field as a guard.

Place of supply. This is the one that quietly corrupts GST returns. If place of supply is derived wrong, Zoho stamps IGST where it should be CGST/SGST (or the reverse). The invoice looks fine; GSTR-1 does not. Set place of supply from the shipping state, not the billing state, and test an intra-state and inter-state order.

API credits and rate limits. A bulk backfill of a year's orders hits the daily API credit cap and stops halfway, leaving books half-synced. Throttle to a few calls per second, batch, and run backfills off-peak with a resume cursor.

The hard cases a generic connector never asks about. Reverse charge, TCS on marketplace sales, rupee rounding on line totals, and HSN codes that do not match your Zoho item master. Map these explicitly. A ready connector will silently skip them, and you find out at filing time. In our experience, budget Rs 15,000 to Rs 45,000 of dev time for these edge cases.

How to scope and hire this before you pay anyone

Answer four questions first. Which systems are you connecting (website, WooCommerce or Shopify store, custom app, Zoho CRM)? Which direction does data flow, one-way (orders push into Zoho Books) or two-way (invoice and payment status flow back)? What is your real volume, say 20 or 2,000 orders a day? And which fields must map: SKU, HSN code, GST rate, place of supply, customer GSTIN? Get these on one page before anyone quotes.

What to hand a developer. Five to ten real sample orders (not dummy data), your Zoho org ID and edition, your GST setup (registered states, composition or regular), and the ugly edge cases: partial refunds, COD, cancelled orders, multi-state shipping, e-invoice/IRN generation above the turnover threshold.

Red flags in a quote. No mention of idempotency (so a webhook retry does not create duplicate invoices), no talk of the .in data center (Zoho India accounts live on zohoapis.in, not .com), no reconciliation plan for payments, or a flat price with zero discovery. Any of those means they will learn on your money.

How we do it. Discovery call, a written field-mapping doc, build against a Zoho staging org, then production with logging and alerts so failed syncs are visible, not silent. The custom middleware sits between your store and Zoho as its own service, built on Node or Laravel, following our REST API design best practices. Typical build runs roughly Rs 40,000 to Rs 90,000 for a simple one-way build, and Rs 1.5L to Rs 4L+ for a full two-way build, depending on scope.

Send us your store and Zoho setup. We will tell you honestly whether to buy a connector or build one.

Frequently asked questions

How much does it cost to integrate Zoho Books with my website or app in India?

It depends on the path. A prebuilt marketplace connector runs about Rs 1,000 to Rs 4,000 per month, an iPaaS flow (Zapier, Make, Zoho Flow) about Rs 1,500 to Rs 6,000 per month with the bill rising as order volume climbs, and a one-time custom build runs roughly Rs 40,000 to Rs 90,000 for a simple one-way order-to-invoice job and Rs 1.5L to Rs 4L+ for a full two-way build with inventory and e-invoice sync. On a custom build, also plan for AMC of about 12 to 18 percent of build cost per year. Judge total cost of ownership, because a cheap connector that mis-books GST costs more at filing time than a build that gets it right.

Can I automatically sync my e-commerce store orders to Zoho Books as invoices?

Yes, and it is the most common job we build. A paid order on Shopify, WooCommerce, or a custom checkout becomes a Zoho Books invoice with the correct line items, HSN codes, and tax rates. The key rule is to trigger on payment success, not on cart creation, so abandoned carts never raise an invoice. Set GSTIN and place of supply on the contact first, or the tax split (CGST/SGST vs IGST) comes out wrong.

Should I buy a ready-made Zoho Books connector or build a custom API integration?

Buy when your store is standard, your fields map cleanly, and your GST is simple. Build when you have custom logic, two or more systems that must stay in sync (store plus CRM plus books), or unusual GST handling like SEZ, reverse charge, or mixed HSN rates. A prebuilt connector is just someone else's middleware, so you inherit their field mapping and their roadmap. If any of the "build" conditions are true, the buy option often turns into a build anyway, just on the vendor's terms.

Does Zoho Books handle GST e-invoicing and IRN generation, or do I need a separate integration for that?

Zoho Books is a registered GSP, so it generates the IRN and signed QR code for you. You do not build integration to the government IRP from scratch. Your job is to push a clean, correct invoice (right GSTIN, place of supply, HSN codes) and let Zoho handle the IRN. That is far less work than the from-scratch e-invoicing route we cover in our separate GST e-invoicing post.

Zoho Books vs Tally: which one is easier to connect to my custom software?

Zoho Books is easier to connect in pure technical terms. It is cloud-native, so you talk to a REST API with OAuth tokens and receive webhooks, and it answers 24x7 from anywhere. Tally is a desktop XML gateway on port 9000, reachable only while that specific PC is on, TallyPrime is open, and the network or tunnel is up. That said, integrate whichever system holds your real books, because your CA probably files GST from it, and we build for both.

How long does a custom Zoho Books API integration take to build and go live?

Typically, in our experience, a simple one-way order-to-invoice build is 1 to 2 weeks including testing against a staging org. A full two-way build with inventory sync, payment reconciliation, and e-invoice/IRN generation is closer to 4 to 8 weeks, depending on entity count and edge cases. Timelines stretch when GST edge cases (reverse charge, TCS, multi-state shipping) or multiple source systems are in scope. Most of the delay is discovery and edge-case mapping, not the core code.

The honest bottom line

There is no single right answer here, only the right fit for how your business actually works. If your store is standard and your GST is simple, buy a connector and move on. If your process has real edge cases, or your books, store, and CRM all need to agree, a custom build usually pays for itself the first filing season it saves you. The expensive mistake is picking on sticker price and finding out at GSTR-1 time that the numbers do not tie out.

If you are not sure which side of that line you fall on, tell us your store, your Zoho setup, and your volume. We will give you a straight read on whether to buy or build. Start at /contact/.

OCPP 2.0.1 Security for Indian EV Charging Operators (2026): TLS/mTLS, OCSP Revocation, Offline Authorization, and Transaction Reconciliation

Ravi Rai — Tue, 14 Jul 2026 08:07:27 +0000

Securing an OCPP 2.0.1 network in India is less about the spec PDF and more about what your chargers do at 11pm when the 4G link drops and a stranger plugs in. Get the transport layer right and you have encrypted, authenticated sessions that bill correctly. Get it wrong and an unsigned firmware channel or a never-revoked charger certificate becomes a quiet backdoor into your CSMS, your payment flow, and every station you run.

This is a working operator's guide to the four things that actually decide whether a 2.0.1 network is both secure and paid: TLS and mTLS on the WebSocket, OCSP revocation, offline authorization when connectivity dies, and reconciling those offline sessions into Razorpay without double-charging. We wrote it from running PlugEV, a production OCPP 1.6-J and 2.0.1 CSMS with a Go WebSocket gateway, a Laravel admin, and Razorpay billing behind it.

None of this comes from the spec alone. All of it comes from chargers that dropped, certs that expired, and sessions that tried to bill twice.

The 60-second security answer for a live Indian fleet

Run Profile 2 as your floor, Profile 3 where the contract demands it. OCPP 2.0.1 defines three security profiles. Profile 1 is HTTP Basic over unsecured transport, so skip it. Profile 2 is TLS server authentication plus HTTP Basic Auth, and for a public network in India it is the honest default: real transport encryption without the per-charger certificate provisioning headache. Profile 3 is mutual TLS (mTLS), where the charger presents its own client certificate. Move to it when a B2B fleet contract or CEA compliance actually requires it, not before.

Two more problems this post owns. Offline authorization keeps a charger usable when 4G drops, using the cached LocalAuthorizationList and the AuthCacheCtrlr component (AuthCacheCtrlr.Enabled) so a session can start without the CSMS. Reconciliation then replays the queued TransactionEvent messages so an offline plug-in bills exactly once in Razorpay, no double-charge, no revenue leak.

Scope: this is how to secure 2.0.1 once you are on it. For whether to migrate at all, see the migration playbook; for general build notes, the CSMS build guide. Every claim here comes from running this on 40+ chargers across 2 cities on a Go WebSocket gateway, not the spec PDF.

The three OCPP 2.0.1 security profiles, and which one you should actually run

We just called them a floor and a contract demand. Here is what each profile actually trusts, because they are not "levels of good," they are different trust models.

Profile 1 is HTTP Basic auth (username plus password) sent over plain ws://. There is no transport encryption. The charger's password crosses the network in the clear, so anyone on the path can read it and impersonate the station. This should never touch a public charger. We still see it left on in the field more than operators admit, usually because a commissioning engineer got the WebSocket connected on ws:// and nobody went back to harden it.

Profile 2 is TLS with a server-side certificate (the CSMS proves who it is) plus Basic auth for the charger. Traffic is encrypted, the charger trusts the CSMS, but the charger still authenticates with a password.

Profile 3 is mutual TLS. Both sides present X.509 certificates, and there is no password. The charger's identity is its client cert, provisioned via SignCertificate / CertificateSigned against your PKI.

Our honest India default: Profile 2 is the floor for any public AC or DC charger. Move to Profile 3 when a fleet client, an aggregator, or a CEA/BIS posture wants cryptographic client-cert identity per station.

The downgrade trap: if your CSMS accepts plain ws:// on the same endpoint as wss://, a charger can silently connect on Profile 1 and you will not notice. Terminate ws:// at the load balancer. One endpoint, one profile floor.

Firmware reality check: not every installed model does Profile 3 in 2026. Audit it. Send GetVariables for the SecurityProfile variable (component OCPPCommCtrlr) and read what each station reports.

Profile 1: no transport encryption, charger identity by password, no CSMS identity, near-zero operational cost. Never on a public charger.
Profile 2: TLS transport encryption, charger identity by password, CSMS identity by a server cert, low operational cost (one server cert to run).
Profile 3: mutual TLS transport encryption, charger identity by its own client cert, CSMS identity by server cert, higher operational cost (PKI, rotation, and OCSP to run).

Running your own PKI adds real ops load, so budget for it. In our experience, all in (tooling plus the loaded engineering time to run rotation, revocation, and audits) a self-operated PKI costs roughly INR 3 to 6 lakh per year. Managed tiers cost less in tooling and shift the tradeoff, and we break the tiers down below. Pricing here is indicative for 2026 and reflects our own estimates; confirm current quotes before you budget.

Inside the wss:// handshake: TLS and mTLS on the WebSocket gateway

Those profiles are abstractions until you watch a charger actually connect. When a charger boots, it dials wss://csms.example.in/ocpp/CP-2201 and starts a normal TLS handshake: ClientHello, then our gateway returns its server certificate chain, and only after the TLS session is up does the HTTP Upgrade happen. The subprotocol is negotiated right there in the headers, Sec-WebSocket-Protocol: ocpp2.0.1. If the charger sends ocpp1.6 and we only speak 2.0.1, the Upgrade fails before a single BootNotification is sent. Watch that header first when a "working" charger will not connect.

Security Profile 2 is server-auth TLS. The charger validates our leaf against a trusted root, checks the SAN matches the host, and reads SNI so we can serve the right cert on a shared IP. Chain order matters: leaf, then intermediate, or older embedded clients fail path building. The classic field failure is a charger that trusts any cert because validation is stubbed in firmware. We have seen units happily connect to a self-signed test cert. Test that deliberately before you sign a fleet contract.

Security Profile 3 is mutual TLS. The charger presents its own client certificate, our gateway validates it against the CPO sub-CA, and we map the cert's CN or SAN to a chargePointId. That identity replaces the Basic-auth password entirely, no shared secret to leak. Running mTLS means running PKI, and an entry managed tier starts around INR 40,000 to 1,20,000 per year in tooling. More on the cost tiers in the next section.

TLS terminates at the Go gateway. It holds the WebSocket and speaks OCPP over an internal channel to the Laravel admin, which never touches a raw socket. This is why a dumb L4 load balancer breaks you: if it passes TLS straight through, nothing extracts the client-cert identity, so mTLS becomes decoration. Terminate where you can read the cert.

Posture: enforce TLS 1.2 minimum (1.3 where firmware allows), disable renegotiation on the TLS 1.2 path (TLS 1.3 has no renegotiation to disable), and pin an allowed cipher list because embedded charger stacks are often years old.

Keepalive uses WebSocket ping/pong. Aggressive idle timeouts on Indian 4G/NB-IoT links drop sessions, and every drop redoes the full TLS handshake, so tune timeouts generously to avoid reconnect storms.

PKI you actually have to run: certificate provisioning, rotation, and the ISO 15118 problem

Once you turn on Security Profile 2 or 3, you stop being a charging company and start being a small certificate authority. Plan for it.

The hierarchy you end up owning. A CPO root (offline, or an intermediate under a managed CA), then two sub-CAs: one that issues charger client certs, one that anchors the CSMS server cert. Do not sign the server cert directly off your root. If that root key leaks or the server cert has to be reissued in a hurry, you want to revoke an intermediate, not rebuild trust on every charger in the field.

Provisioning the first cert. Either the factory installs a client cert, or you field-provision. In practice the charger boots with a bootstrap cert, sends SignCertificate with a CSR, and the CSMS replies CertificateSigned with the issued chain. To seed or replace CA certs you use InstallCertificate, and GetInstalledCertificateIds / DeleteCertificate to audit what is actually on the box. All of it rides the live OCPP WebSocket, so no truck roll.

Rotation without site visits. An expired cert on a remote charger is a self-inflicted outage. We schedule reissue well before expiry and alarm any charger whose cert is inside 30 days of lapsing. That is our operator choice, not a spec rule: we alarm at 30 days and you tune it to your own reissue lead time, driven off GetInstalledCertificateIds sweeps, not hope.

Keep the three families separate. 2.0.1 distinguishes CSMS/server, charger/client, and V2G/ISO 15118 certs. Conflating them is the most common InstallCertificate failure we see: right cert, wrong certificateType.

ISO 15118 Plug and Charge in India. The V2G root and contract-certificate ecosystem here is still thin, with no established Indian V2G Root CA or contract-certificate operator ecosystem to build against. PnC is design-for-later, not a reason to stand up a full V2G PKI in 2026. Build the hooks, skip the CA. (See our migration playbook.)

Tooling. Use step-ca or a managed PKI over hand-rolled OpenSSL scripts. The cost tiers we see, indicative for 2026: an entry managed tier that handles issuance and OCSP runs roughly INR 40,000 to 1,20,000 per year in tooling; a fuller managed CA tier with HSM-backed key storage, more certificate families, and higher assurance runs roughly INR 1.5 to 4 lakh per year; and running the whole thing yourself, all in with the loaded engineering time to operate it, lands around INR 3 to 6 lakh per year. Once B2B fleet contracts start auditing you, key storage matters: an HSM, or at minimum sealed secrets, never keys sitting in plaintext on disk.

OCSP and certificate revocation: proving a cert is still valid

Issuing certs is the easy half. Killing one you no longer trust is the half everyone skips. A charger cert stays cryptographically valid until its expiry date, even if the unit was stolen off a wall or decommissioned last month. If you cannot revoke a cert and then actually check revocation on connect, a lifted charger can keep opening a TLS session to your CSMS for the full cert lifetime. That is the gap.

You have three tools. CRLs are full revocation lists. A full CRL can be large, and on a charger sitting on a metered mobile SIM, pulling it on every check is painful and eats data you pay for. OCSP asks a responder about one cert only, which is lighter. OCSP stapling is lighter still.

OCPP 2.0.1 helps here. The charger does not need its own route to a public OCSP responder. It sends GetCertificateStatus with the OCSP request data, and the CSMS relays it to the responder and returns the signed answer. Your CSMS becomes the OCSP proxy, which matters for chargers behind NAT or on a locked-down APN.

On our gateway we staple the responder answer straight into the TLS handshake. The charger gets a fresh, signed status with no second round trip on a flaky link. We cache staples and refresh before they go stale.

Then the offline dilemma. If nothing can reach a responder, do you soft-fail (allow) or hard-fail (reject)? On unattended public sites we soft-fail with a short grace window, because hard-fail bricks a whole site when the responder blips.

Operational must-haves: put revoke-on-decommission in the charger offboarding checklist so a pulled unit is dead the same day, and alert when OCSP responses go stale past your refresh threshold. A stale-staple alarm has caught silent responder outages for us more than once.

Signed firmware updates: why unsigned OTA is a backdoor

Revocation stops a bad cert. Signed firmware stops a bad image, and it is the higher-stakes control, because firmware is root on the charger. If your OTA channel accepts an unsigned or unverified image, anyone who can reach that channel gets remote code execution on every charger you operate. That is not a bug, it is a backdoor into the whole fleet, and it reaches your CSMS, your OCPP WebSocket, and the payment flows behind them.

OCPP 2.0.1 fixes the transport with UpdateFirmware. Its firmware object carries the firmware location plus a signingCertificate and a signature. The charger verifies that signature against a trusted manufacturer or CPO key before it flashes anything. No valid chain, no flash.

What the CSMS must enforce. Reject unsigned images at the source. Verify the signing chain yourself before you ever send the request. Then log every FirmwareStatusNotification transition (Downloading, SignatureVerified, InvalidSignature, Installing, InstallRebooting, Installed) so a stuck, failed, or downgraded update is visible instead of silent.

Rollout, not blast. A bad flash on about 40 chargers at once is a field-visit disaster and lost revenue while sites sit dark. We push to one canary charger, watch it complete a full session, then move in rings. In our experience, recovery visits in tier-2 cities cost real money, roughly INR 1,500 to 4,000 per site.

India field reality. Vendor firmware maturity is mixed. Some models advertise signing but do not actually reject a bad signature. We test rejection per model before we trust the mechanism on that hardware.

Offline authorization: what the charger decides when 4G drops

Everything so far assumes the charger can reach you. Most of our public sites cannot, reliably. They run on a single 4G SIM for backhaul, and in practice that link drops several times a day, sometimes for a few seconds during a tower handover, sometimes for twenty minutes when it rains. A charger that can only authorize online is a charger that stops earning during every one of those windows. So the real question is not "does it support OCPP 2.0.1," it is "what does the charger decide on its own when the CSMS is unreachable."

2.0.1 gives you two local mechanisms. The Local Authorization List is an operator-pushed allow-list you sync with SendLocalList and check with GetLocalListVersion. The Authorization Cache is the charger auto-remembering idTokens it has already seen the CSMS approve.

The decision flow. Online, the charger sends Authorize and waits for the CSMS authorizationStatus. Offline, behaviour is governed by config. LocalAuthorizeOffline lets it fall back to the local list, then the cache. LocalPreAuthorize lets it start energy immediately on a local hit without round-tripping. OfflineTxForUnknownIdEnabled is the dangerous one: set true, it will start a session for a token it has never seen.

This is a policy call, not a default. A fleet depot with 30 known drivers runs a tight local list and turns unknown-token offline start off. An open public charger that authorizes unknown tokens offline is choosing revenue continuity over fraud risk. Choose it deliberately, per site, and write it down.

Keep the list fresh or it breaks quietly. SendLocalList supports Full and Differential updates against a version number. Push differentials on membership changes, full only on drift. A stale list rejects a valid driver; large local lists can overflow the flash on cheaper AC units.

What happens to the meter. On an offline start the charger opens the transaction, stamps transactionId, and stores its sampledValue meter readings inside each queued TransactionEventRequest (eventType Started, Updated, Ended) locally. When the link returns it replays the queue. That replay is the handoff into reconciliation, and where Razorpay either gets billed correctly or leaks.

Transaction reconciliation: settling offline sessions in Razorpay without double-charging

An offline session is a real transaction the CSMS never watched happen. The charger delivered kWh, logged it locally, and only when the WebSocket comes back does it flush a burst of queued TransactionEventRequest messages (eventType Started, Updated, Ended, each carrying offline: true and a seqNo). Those queued events must collapse into exactly one correct charge.

Idempotency is the whole game. We dedupe on the charger-generated transactionInfo.transactionId plus seqNo, with a unique constraint in Postgres. A charger that reconnects and retries the same Ended event (common) hits the constraint and no second billing row is born. Same discipline we use on the payment side: see Razorpay webhooks, idempotency and reconciliation.

Trust the meter, not the clock. We compute energy from the first and last sampledValue readings inside the TransactionEvent stream, never from wall-clock duration. Offline chargers drift; their RTC can be minutes or hours off, so we treat the charger timestamp as advisory and stamp our own received-at time for ordering.

The billing sequence we run: queued transaction closes -> compute kWh (last sampledValue minus first sampledValue) -> price it in INR with GST as applicable (commonly treated as 18% for charging-as-a-service) -> capture the pre-auth or raise a Razorpay invoice -> mark settled. Pre-auth vs post-paid decides whether we can actually collect: for walk-in users we hold a pre-auth of around INR 500 (our configured hold) at the Started event, so an offline session still has money to capture. Post-paid fleet accounts we invoice monthly, so offline just means late, not unpaid.

Revenue-leakage cases each get an explicit rule, never a silent skip: charger stopped mid-session offline (bill on last good meter reading, flag partial); missing Updated events (interpolate nothing, use endpoints only); duplicate TransactionEvent Started after a reboot (same transactionId wins, reboot copy is dropped); negative or rollback meter readings (reject, route to disputed).

The reconciliation ledger is a state machine per transaction in the Laravel admin: open -> offline-queued -> replayed -> priced -> settled -> disputed. Finance sees every offline session and why it was billed what it was.

Auditability for B2B and CEA: an immutable, append-only transaction log plus signed MeterValues (2.0.1 signedMeterValue in each sampledValue). When a fleet client disputes an invoice, we answer with the cryptographically signed start and stop readings, not a spreadsheet.

CEA, BIS, and the India compliance picture for secured public chargers

You now have a secure, billable network. The next question every operator asks is which of this is actually required. Be honest about what is law versus what is signal. As of mid-2026, the Ministry of Power's "Guidelines and Standards for Charging Infrastructure" (the Model EV Charging Infrastructure guidelines) and the CEA rules they sit on mostly cover electrical safety, connector standards, and network connectivity, not a hard OCPP security-profile mandate. CEA's cyber-security guidelines and the push toward BIS-tested hardware point at TLS and authenticated firmware as direction of travel, but we have not seen a notified clause that says "run OCPP 2.0.1 Security Profile 3." Treat anyone claiming a strict mandate with suspicion.

The real near-term forcing function is commercial, not regulatory. B2B and fleet contracts are where mTLS, signed firmware, and audit trails become non-negotiable. A logistics fleet buying charging as a service wants revocation handling and tamper-evident logs written into the SLA, long before a regulator asks.

Data residency and PII is the sharper edge. RFID idToken values, app identities, and TransactionEvent records are personal data under the DPDP Act. Know where that data lives, why you hold it, and how to erase it. We cover the mechanics in our DPDP compliance guide.

In the RFPs we have responded to, security posture is now a tender differentiator: government and large-CPO tenders increasingly list TLS, OCSP revocation, and signed firmware as scored line items. The honest gap: much Indian field hardware still ships with weak or default TLS config, so compliance is as much a fleet-audit exercise (charger by charger) as a backend one.

Rolling security onto a live fleet without bricking chargers

Do not flag-day this. Stand up your plain endpoint (wss:// on Security Profile 1) and your hardened endpoint side by side, and migrate chargers in rings, not all at once. Keep a rollback URL live until a given firmware build has proven itself on Profile 2/3 for a couple of weeks. A charger you cannot reach is a charger you cannot fix remotely.

The order that worked for us:

TLS server-auth first (Profile 2): CSMS presents a cert, charger validates the chain.
Push client certs via SignCertificate / CertificateSigned, confirm with GetInstalledCertificateIds.
Flip to mTLS (Profile 3) per charger.
Enable OCSP revocation checking.
Turn on signed firmware enforcement last.

Qualify per model. Certify each vendor firmware version against your exact security config in a lab or single-charger canary before it touches a ring. Vendor TLS stacks ship bugs (wrong SNI handling, broken chain validation, clock-skew cert failures) far more often than not. Assume it.

Get observability up before you touch anything: per-charger BootNotification/Heartbeat connection state, cert-expiry dashboards (Prometheus plus Grafana works), reconnect-rate alarms, and offline-transaction backlog depth from queued TransactionEvent messages. A security change that silently kills connectivity should page you in minutes, not surface as a Razorpay reconciliation gap next week.

For the CFO: in our estimate this is roughly 2 to 4 engineer-weeks of work plus existing infra, not new hardware, the kind of security and backend engineering we take on. The payoff is B2B fleet contracts that demand it, and not being the operator in the next charger-hack headline.

Failure modes we hit in production (and the fix)

We learned most of this the hard way. Here is the short list.

Cert expiry killed a live charger. Rotation was manual, someone missed a renewal, and the site dropped off during a busy evening. Now we run scheduled rotation via InstallCertificate / CertificateSigned and alert at 30 days before expiry, per charger.

Reconnect storm after a tower outage. When a Jio tower recovered, about a dozen chargers slammed the gateway with simultaneous TLS handshakes and CPU spiked. Fix: jittered reconnect backoff on the charger side plus handshake rate-limiting at the Go gateway, so BootNotification arrivals spread out.

Duplicate billing from replayed offline transactions. After reconnect, queued TransactionEvent messages replayed and some settled twice. We now key on transactionId + seqNo as an idempotency key and hold a settled-once ledger state, so Razorpay only ever charges the delta once.

A charger trusted a bad cert. Firmware cert validation was permissive and accepted the wrong CA. We only caught it by testing with a deliberately wrong cert. That test is now part of per-model qualification.

Offline meter drift produced a wrong INR amount. We had billed off the charger wall-clock timestamp. Now we bill on metered kWh delta from the first to the last sampledValue reading in the TransactionEvent stream, never on clock time.

2.0.1 security is not a feature you switch on. It is a discipline you run every day: certs, revocation, offline policy, reconciliation.

Where this leaves you

None of this is exotic. It is TLS you enforce properly, a small CA you actually run, revocation you actually check, an offline policy you decide on purpose, and a reconciliation ledger that bills each session exactly once. The hard part is not the spec, it is doing all of it every day across real hardware that ships with real bugs.

If you are securing a live OCPP 2.0.1 network or building a CSMS from scratch and want people who have run this in production rather than read about it, talk to us. → Work with buildbyRaviRai

Frequently asked questions about OCPP 2.0.1 security

Do I need OCPP Security Profile 3 (mTLS), or is Profile 2 (TLS plus Basic auth) enough for a public charging network in India in 2026?

Profile 2 is the honest floor for a public network. It gives you real transport encryption with a single server cert and no per-charger PKI to run day one. Move to Profile 3 (mTLS) when a B2B fleet contract, an aggregator, or a CEA/BIS posture actually demands cryptographic per-station identity, not before. We run Profile 2 as our default and flip specific chargers to Profile 3 when a contract requires it.

Who issues the TLS certificates for my chargers, and how do I rotate them across a remote fleet without a site visit to each charger?

You do, effectively. Once you turn on Profile 2 or 3 you run a small CA: a CPO root, a sub-CA for charger client certs, and a sub-CA anchoring the CSMS server cert. Rotation rides the live OCPP WebSocket via SignCertificate, CertificateSigned, and InstallCertificate, so there is no truck roll. We alarm any charger whose cert is inside 30 days of expiry and reissue ahead of it, because an expired cert on a remote charger is a self-inflicted outage.

How does a charger authorize a user and start a session when the 4G/mobile network drops mid-site, and is it safe on a public charger?

It falls back to two local mechanisms: the operator-pushed Local Authorization List and the Authorization Cache of previously approved idTokens. With LocalAuthorizeOffline and LocalPreAuthorize on, a known token starts energy immediately without the CSMS. Safety is a policy call: OfflineTxForUnknownIdEnabled controls whether an unknown token can start offline, and on an open public charger that is a deliberate revenue-versus-fraud trade-off you set per site and write down.

If a charging session runs entirely offline, how do I bill it through Razorpay when connectivity returns without double-charging the user or losing the revenue?

The charger stores the transaction locally and replays queued TransactionEvent messages when the link returns. We dedupe on the charger's transactionId plus seqNo with a unique constraint in Postgres, so a retried Ended event cannot create a second charge. For walk-in users we hold a pre-auth of around INR 500 at session start, so there is money to capture even if the session ran dark; fleet accounts get invoiced monthly instead.

Is ISO 15118 Plug and Charge actually usable in India yet, and do I have to stand up a full PKI to support it?

Not really, not yet. The V2G root and contract-certificate ecosystem in India is still thin, so Plug and Charge is design-for-later, not a 2026 requirement. Build the hooks in your data model and keep V2G certs as a separate certificate family so you are not conflating them later. Do not stand up a full V2G PKI now to chase a feature the market cannot use.

How does the charger check whether a certificate has been revoked (OCSP), and what should it do when it cannot reach the OCSP responder?

In 2.0.1 the charger sends GetCertificateStatus with the OCSP request and the CSMS relays it to the responder, so the charger needs no direct route out. We staple the signed answer into the TLS handshake to save a round trip on flaky links, and we cache and refresh staples before they go stale. When nothing can reach a responder we soft-fail with a short grace window on unattended public sites, because hard-fail bricks a whole site when the responder blips, and we alarm on stale staples.

What do CEA and BIS actually require for security on public EV chargers in 2026, and will regulators or fleet clients force me to mTLS first?

As of mid-2026 we have not seen a notified clause mandating a specific OCPP security profile; the Ministry of Power's "Guidelines and Standards for Charging Infrastructure" mostly cover electrical safety, connectors, and connectivity, with TLS and signed firmware reading as direction of travel. The real forcing function is commercial: B2B and fleet contracts write mTLS, revocation, and tamper-evident logs into the SLA long before a regulator does. Plan your PKI around the next fleet tender, not around a mandate that is not on paper yet.

Tally Integration With Your Website or Custom Software (India, 2026): How It Actually Works, What It Costs, and When to Build vs Buy

Ravi Rai — Sun, 12 Jul 2026 22:41:22 +0000

If you run a business in India, there is a good chance your sales happen in one system and your accounting happens in TallyPrime, and the two have never spoken to each other. Someone bridges that gap by hand, copying orders into Tally one voucher at a time. It works until volume grows. Then it quietly costs you hours and introduces errors nobody spots until GST filing.

This guide is about closing that gap properly: connecting your website, e-commerce store, or custom software to TallyPrime so orders, invoices, ledgers, and stock flow in without anyone re-typing them. We have built these integrations for D2C stores, B2B distributors, and service firms running a CRM next to Tally, so this is written from what actually breaks in production, not a vendor brochure.

By the end you will understand how Tally really connects to another app, the three integration methods and when each fits, whether to buy a connector or build custom middleware, what the whole thing costs in 2026, and how to scope the project before you hire anyone.

Why this comes up: your sales live in one app, your books live in Tally

Every Indian SMB we work with hits the same wall. The sales happen in one place, and the accounting happens in TallyPrime, and nothing connects the two.

So someone pays the tax. Usually the accountant. They open the website admin (or the store dashboard, or the CRM), read off one order, then retype it into Tally as a sales voucher. Party ledger, item, quantity, GST, done. Then the next order. Then dozens more. We call it the re-keying tax, and it costs real hours plus the typos nobody catches until reconciliation.

Who feels it worst: D2C and e-commerce stores pushing dozens of orders a day, B2B distributors booking stock and party ledgers, and service firms running a CRM next to Tally for invoices and receipts.

When people say 'Tally integration with a website', this is what they actually mean: your own app pushing its sales, invoices, ledgers, and stock straight into Tally so nobody re-keys anything.

One clear line first. This is not GST e-invoicing. E-invoicing means generating an IRN on the government IRP portal (we cover GST e-invoicing and IRN generation separately). This is booking your own vouchers into your own Tally.

So how does your app actually push data into Tally? It starts with a fact most vendors skip over.

How Tally actually connects to another app (the part nobody explains plainly)

Here is the thing most vendors gloss over: TallyPrime is its own little web server. Go to F1 (Help) > Settings > Connectivity > Client/Server Configuration, set TallyPrime to act as Server, and enable the gateway (the TallyPrime help documentation lists the exact toggle labels for your release). Tally then starts listening for HTTP requests on its gateway port, 9000 by default. Once that is on, any other program on the same machine or network can talk to it. That is the whole foundation. No magic, no API keys, just a local server sitting there waiting.

The four real doors in:

XML over HTTP, the workhorse. You send a request to http://<tally-ip>:9000 and Tally answers.
TDL (Tally Definition Language), Tally's own scripting layer for custom reports, fields, and behaviour inside Tally itself.
ODBC, read-heavy, good for pulling data into Excel or Power BI, weaker for writing.
Prebuilt connectors, tools that wrap the above so you don't write raw XML.

Import vs export, in plain words. To push data in (create sales vouchers, customer ledgers, stock items), you POST an XML request with <REQUEST> type Import Data. To pull data out (a sales register, outstanding receivables, a stock summary), you send an Export Data request and Tally streams the report back.

The request envelope. Every message is an <ENVELOPE> with two parts: a <HEADER> (what you want, e.g. Import Data) and a <BODY> that holds one or more <TALLYMESSAGE> blocks (the actual voucher or master). Inside the header you must name the company and the financial year exactly as they appear in Tally. Get the company name off by one space, or point at the wrong FY, and Tally silently rejects or misfiles the voucher. This is one of the most common causes of failed imports we see.

The constraint you never escape. Tally has to be open, unlocked, and network-reachable at the moment of every request. Close Tally, lock the screen, or lose the LAN, and the integration stops. There is no background daemon.

On-prem vs cloud Tally. If Tally runs on a desktop in the office, your integration is only alive during office hours. If you host Tally on a cloud VM (AWS, or a managed Tally-on-cloud host), it can run 24x7 and your website can reach it any time. That one decision shapes the entire architecture, and we come back to it in detail below.

The integration methods compared: XML API, TDL, and ODBC

When your website, store, or CRM has to talk to TallyPrime, you have three real native options. Not ten. Three. Prebuilt connectors are a fourth path, but they just wrap these three, and we cover them under build vs buy.

XML over HTTP API. This is the default path and the one we reach for on most jobs. Tally accepts XML requests on the port from the last section and returns XML. TallyPrime added JSON import in Release 7.0, but for the API path we default to XML, which every TallyPrime build accepts over the HTTP gateway. It is language-agnostic, so your middleware can be written in Node, PHP, or Python and it does not care. You POST a request that says 'create this sales voucher' or 'give me this ledger balance', Tally does it, you read the response. This is how app data actually gets pushed into the books.

TDL (Tally Definition Language). This customises Tally itself: new fields, new reports, extra buttons, changed voucher layouts. It is genuinely powerful, but the code lives inside Tally and runs on Tally's terms (the language is documented by Tally Solutions). You need an actual Tally/TDL developer, not a web dev. Use it when the requirement is inside Tally (a custom invoice format, a new master field), not when the requirement is 'sync my website orders'.

ODBC. Read-oriented reporting into Excel, Power BI, or Google Sheets. Good for pulling numbers out. Clunky and weak for writing data in, and the connection is fiddly to keep alive. Treat it as a reporting tap, not an integration.

Here is the same comparison in plain words:

XML over HTTP is genuinely good at pushing and pulling vouchers, ledgers, and stock from any app. Where it falls down: Tally must be open, and XML is verbose.
TDL is genuinely good at custom fields, reports, and invoice formats. Where it falls down: it needs a Tally developer and lives inside Tally.
ODBC is genuinely good at reading into Excel or BI tools. Where it falls down: writing data is unstable and slow.

The practical answer. For website, CRM, or e-commerce work, it is almost always XML over HTTP driven by a middleware service you control. The middleware queues orders, maps GST/HSN and ledgers, retries when Tally is closed, and logs every push. TDL and ODBC play supporting roles around it, never the lead.

Connect Tally to a website, e-commerce store, or CRM: the real scenarios

Every integration comes down to the same move: something happens in your app, and a voucher or ledger gets created in TallyPrime over its XML port. What changes is the source and how often you push.

Website or lead form to Tally. A quote request or a paid order hits your site. The middleware first checks whether a party ledger exists (matched on name or GSTIN), creates it under Sundry Debtors if not, then posts a Sales voucher or a Receipt voucher for a prepaid order. The per-order data entry disappears.

Shopify, WooCommerce, or a custom store to Tally. Here each order carries line items, so you map every SKU to a Tally stock item, post the order as a Sales voucher with HSN codes and split CGST/SGST/IGST by the buyer's state, and let Tally reduce stock. Get the tax ledger mapping right once and reconciliation stops being a monthly fire.

CRM to Tally (our MultiVendor CRM as the worked example). When a deal moves to Won, we push the CRM customer as a ledger and the CRM invoice as a Sales voucher, keeping the CRM invoice number as the voucher reference so both systems agree.

One-way vs two-way. One-way push (app to Tally) covers most Indian SMBs, because accounts is the system of record and nobody wants website prices editable from Tally. Two-way sync (pulling outstanding balances or payment status back) costs more to build and test, so buy it only when your sales team genuinely needs live balances.

Near-real-time vs batch. Our rule of thumb: under roughly 50 to 100 orders a day, fire on each order. Above that, or when Tally sits on one office PC that isn't always awake, we run a scheduled batch every 15 to 30 minutes. Batch is also far kinder to debug when a voucher fails.

Build vs buy: off-the-shelf connector or custom middleware

What ready-made connectors do well. If your setup is a standard store feeding a standard books file, a packaged connector is the fastest way to stop double-entering vouchers. Off-the-shelf WooCommerce-to-Tally, Shopify-to-Tally, and Zoho-to-Tally connectors handle the common path well: a paid order becomes a sales voucher, the customer becomes a ledger, stock items map to Tally stock items, and CGST/SGST/IGST post to the right ledgers. For a single store with clean product data, expect setup in days, not weeks. This is the right call more often than founders think.

Where connectors break down. The trouble starts when your flow stops being generic. Custom fields (a dispatch code, a broker name, a project tag) usually have nowhere to land. Non-standard voucher structures, like a sales voucher that also books TCS or a cost centre split, either get dropped or forced into the wrong ledger. And most connectors are one-source-to-one-Tally. The moment you have a website plus an offline POS plus your own CRM (the kind of custom CRM development that carries its own fields) all needing to hit the same company file, an off-the-shelf tool cannot arbitrate between them.

What custom middleware buys you. A middleware layer (a small service that sits between your apps and TallyPrime's XML port) gives you control that a licence screen never will: your own field mapping, idempotency keys so a retried webhook does not create a duplicate voucher, retry-with-backoff when Tally is closed, a full audit log of every payload sent, and deliberate handling of GST edge cases (reverse charge, exempt vs nil-rated, HSN mismatches). When something fails at 11pm, you can read the log instead of guessing. This is the sort of custom software development services work we take on most weeks.

An honest framework. Buy if your flow is standard and single-source. Build if it is bespoke, has custom fields, or pulls from more than one system.

The money trade-off. Most connectors run on a recurring per-year licence, roughly ₹8,000 to ₹30,000 per year. A custom build is a one-time cost you own outright, commonly ₹40,000 for a simple one-way sync and up to ₹8,00,000+ for a multi-source setup, depending on voucher complexity. Over three years, bespoke and multi-source setups usually favour building. The cost section below breaks the tiers down properly.

A JSON-to-Tally-XML middleware: how we architect it in Node or PHP

The core pattern is simple once you see it. Your website, store, or CRM does not talk to Tally directly. It emits a plain JSON event ('order paid', 'invoice raised') to a small middleware service. That service maps the JSON to a Tally XML envelope and POSTs it to http://<tally-host>:9000. Tally receives the voucher and replies with its own XML.

The service structure is the same whether we build it in Node (Express or Fastify) or PHP (Laravel), and it follows the same REST API design best practices we use on any integration layer:

Receive the event on a webhook route.
Validate it: does the ledger exist, is the GST/HSN present, is the amount sane?
Transform the JSON into the exact <TALLYMESSAGE> block the voucher type needs, with LEDGERNAME, AMOUNT, and the party details wrapped in ENVELOPE > BODY > IMPORTDATA.
Send it to port 9000.
Parse the response for <LINEERROR> or a created/altered count.

A queue and retry layer is not optional. Desktop Tally gets closed at 7pm, or someone is mid-entry and it is busy. Without a queue the POST fails and the sale vanishes from the books silently. We push every event into Redis (BullMQ) or a database-backed queue. If Tally is unreachable, the job waits and re-fires on a backoff. Nothing is lost.

Idempotency keys stop duplicate ledgers and vouchers. We tie a key to your order ID or invoice number. Before posting, the middleware checks whether that key already succeeded. So a retry, a double webhook, or a manual replay never creates two sales vouchers for the same order. This one control prevents the most common Tally-integration mess, and we come back to it below because it is the number one thing that goes wrong.

Log everything verbatim. We store the outbound XML and Tally's raw reply for every request. When the accountant asks why a voucher looks off, you open the log, not a debugger. We typically keep at least 90 days of logs, then prune older ones, since the payloads carry customer and GSTIN data you should not hoard.

Where it runs matters. For desktop Tally, the middleware sits on the same LAN, often the same machine or a small always-on PC. For cloud-hosted Tally, we run it on a small VPS (roughly ₹500 to ₹2,000 per month) that reaches Tally over a private tunnel (WireGuard or Tailscale), never an open public port.

The things that actually break (and how we handle each one)

Duplicate vouchers from retries with no idempotency. This is the number one thing that goes wrong. Your app posts a sale, Tally is slow, the request times out, your app retries, and now you have the same invoice twice in the books. The fix is the idempotency key from the last section: we store every posted voucher's key plus Tally's returned voucher ID in a small ledger table, and we check that table before any post and before any retry. No key means no duplicate.

The ledger master must exist before the voucher. Tally rejects a sales voucher if the party ledger is not already there. So our middleware checks for the party and tax ledgers first, auto-creates the ledger master (with the right group, GSTIN, and state) via XML, then posts the voucher in the same run.

GST, HSN, and tax-ledger mapping mismatches. Your app might call it 'GST 18%' while your accountant's Tally has a specific 'Output CGST 9% / SGST 9%' setup with HSN codes on the stock items. We build a mapping table, agreed with your accountant, that translates your app's tax fields to the exact ledger names and HSN codes in their company. Get this wrong and every GSTR-1 reconciliation becomes manual.

Company name or financial year mismatch. As noted earlier, Tally silently rejects the whole request if the SVCURRENTCOMPANY or the date falls outside the open financial year. We pin the exact company name and validate the voucher date against the active FY before sending.

Tally not running, machine asleep, or office internet down. On-prem Tally is offline more than you think. The durable queue in front (Redis or a simple DB table) means posts pile up safely and drain automatically when Tally is back. Nothing is lost, nothing is posted twice.

Voucher numbering clashes. If Tally auto-numbers and your app also forces a number, you get gaps or rejections. We pick one owner of the number, usually Tally, and store the returned number back against your order.

Typical build for this hardening: ₹40,000 to ₹90,000, which sits inside the simple one-way tier below.

On-prem vs cloud Tally, and reaching it safely over the internet

Desktop Tally on an office PC. This is the most common setup we see. TallyPrime is installed on one machine in the accounts room, and the XML server listens on port 9000 on that machine's local network only. Your middleware has to reach that machine. If the middleware also runs inside the office (same LAN), it just points at the PC's local IP, for example http://192.168.1.12:9000. If your website or web app lives on a hosted server, it cannot see that local IP at all. You need a secure tunnel between them.

Tally on a cloud VM or a Tally-on-cloud provider. Move Tally onto a Windows VM (AWS EC2, Azure, or a managed Tally-on-cloud host) and your hosted app can reach it reliably, because both sit on the internet. Expect roughly ₹800 to ₹2,500 per user per month for a managed Tally-on-cloud seat. This is what we recommend when uptime matters.

Connecting safely. Your options: a static IP plus firewall whitelist, a site-to-site or client VPN (WireGuard, OpenVPN), or a reverse tunnel (Cloudflare Tunnel, ngrok, Tailscale) from the Tally PC out to your middleware. VPN and reverse tunnel are safest because nothing is opened inbound on the office router.

Security rule we never break: do not port-forward or expose raw port 9000 to the public internet. The gateway has no built-in authentication. Anyone who finds it can read and post vouchers.

After go-live, keep the Tally licence activated on that exact machine, leave Gateway of Tally on port 9000, and confirm whether you are in single-user or multi-user (Gold) mode. Single-user locks the company while a report runs, which will stall your sync.

What it costs and how long it takes (India, 2026)

Pricing here is indicative for 2026 and reflects our own rate card; confirm current quotes before you budget.

Off-the-shelf connectors. If your setup is standard (WooCommerce or Shopify orders flowing into TallyPrime as sales vouchers), a ready-made connector is the cheapest start. Expect roughly ₹8,000 to ₹30,000 per year for a licensed plug-in or SaaS bridge, usually billed annually per Tally company or per site. Off-the-shelf WooCommerce-to-Tally, Shopify-to-Tally, and Zoho-to-Tally connectors sit in this band. The catch: they only map the fields the vendor decided to support.

Custom middleware. The moment your data does not fit a template, you are building. Rough ranges we quote:

Simple one-way sync (website orders into Tally, one company, standard GST): ₹40,000 to ₹1,00,000, delivered in 1 to 2 weeks.
Mapped two-way sync (stock and ledger balances flow back to the site, custom fields, HSN mapping): ₹1,25,000 to ₹3,50,000, 3 to 6 weeks.
Multi-source (website plus CRM plus marketplace into one or more Tally companies): ₹3,50,000 to ₹8,00,000+, 6 to 12 weeks.

Ongoing costs people forget. Middleware has to run somewhere. A small VPS to host the sync service is around ₹500 to ₹2,000 per month. Budget an annual maintenance retainer (we typically charge 15 to 20% of build cost) because every TallyPrime version upgrade can change XML behaviour and quietly break your import. On-prem Tally also means the machine and the sync service both have to stay awake.

What drives the price up. Custom fields, two-way writes, multiple source apps, and GST edge cases (inclusive vs exclusive tax, mixed HSN slabs, place-of-supply logic, credit notes). Each one adds mapping and testing time.

The cheapest sane path. A small store should buy a connector, live with its limits, and only build later. A growing B2B distributor with pricing tiers, multiple ledgers, and stock that must stay accurate across channels should skip the annual connector rental and commission custom middleware once, because the duplicate-ledger and reconciliation cleanup will cost more than the build.

How to scope your Tally integration before you hire anyone

The projects that go badly are the ones nobody scoped. Spend an afternoon on this and you will cut both cost and rework.

Write down exactly what data moves. One line per object: 'sales orders from Shopify create sales vouchers in Tally', 'customer master syncs both ways'. Note direction (one-way or two-way) and volume per day. This one page is what a developer actually quotes against.

Decide sync frequency and the tie-breaker. Real-time on order, or a batch every 15 minutes? More importantly, when the website says one price and Tally says another, who wins? Pick a source of truth per field before a line of code is written.

Confirm on-prem vs cloud Tally. Is TallyPrime on a shop-floor PC, a VPS, or something like Tally on AWS? The developer needs to reach port 9000, usually via a static IP, a VPN, or an agent running next to Tally. Sort this early; it blocks everything.

Get a sample voucher and ledger structure from your accountant up front. Real ledger names, GST/HSN codes, voucher types, and one exported XML voucher. Guessing the ledger tree is where duplicate ledgers get born.

Put the boring parts in the contract. Idempotency (no double-posting on retry), retry logic, a log of every push, and email alerts on failure. Ask for these by name, not 'good error handling'.

A quick website cost calculator helps you sanity-check the build budget while you scope. Off-the-shelf connectors run roughly ₹8,000 to ₹30,000 per year; custom middleware more. Do this homework and any developer you hire starts from a data map instead of a guess.

Frequently asked questions about Tally integration

Does Tally have an API, and can it connect to a website or custom software?

Yes, though not a REST API in the modern sense. TallyPrime runs a local HTTP-XML server on port 9000 once you enable Client/Server mode and set it to act as a server. Any app, in any language, can POST XML (newer builds also accept JSON) to create or read vouchers, ledgers, and stock. Your website or custom software connects through a middleware service that speaks that XML, not through a hosted cloud endpoint.

Does TallyPrime have to be open and running for the integration to work?

Yes. Tally must be open, unlocked, and network-reachable at the exact moment of every request, because there is no background service that runs when the app is closed. This is why on-prem Tally is effectively an office-hours integration. The standard fix is a durable queue in front of Tally, so events wait safely and drain automatically once Tally is back, and to host Tally on a cloud VM if you need 24x7 uptime.

Can I integrate cloud-hosted Tally with my web app, or does it only work on the office PC?

Both work, and the choice shapes the whole architecture. Desktop Tally on an office PC only listens on the local network, so a hosted web app has to reach it through a VPN or a reverse tunnel, never an exposed public port 9000. Cloud-hosted Tally on a Windows VM or a Tally-on-cloud provider sits on the internet alongside your app, so it is reachable any time and is what we recommend when uptime matters, at roughly ₹800 to ₹2,500 per user per month.

How much does Tally integration cost in India in 2026, and how long does it take?

A ready-made connector for a standard store runs about ₹8,000 to ₹30,000 per year and sets up in days. Custom middleware is a one-time build: ₹40,000 to ₹1,00,000 for a simple one-way sync in 1 to 2 weeks, rising to ₹3,50,000 to ₹8,00,000+ over 6 to 12 weeks for multi-source setups. Add a small VPS (around ₹500 to ₹2,000 per month) and a maintenance retainer, because Tally version upgrades can change XML behaviour.

Should I buy a ready-made Tally connector or get custom middleware built?

Buy if your flow is standard and single-source: one clean store feeding one company file with normal GST. Build if it is bespoke, has custom fields, non-standard vouchers (TCS, cost centres), or pulls from more than one system that all hit the same Tally company. Over three years, multi-source and bespoke setups almost always favour building, because the reconciliation cleanup a limited connector leaves behind costs more than the one-time build.

Will syncing orders into Tally create duplicate vouchers, and how is that prevented?

It can, and it is the single most common failure. A slow response, a timeout, a retried webhook, or a manual replay can post the same order twice. The prevention is idempotency keys: tie a stable key to your order ID or invoice number, store every posted voucher's key alongside Tally's returned voucher ID, and check that table before every post and every retry. No matching key, no duplicate.

The honest bottom line

Tally integration is not exotic, but it is unforgiving. The connection itself is a few lines of XML; the reason projects go sideways is everything around it, the queue, the idempotency, the exact ledger and GST mapping, and Tally simply being closed at the wrong moment. Get those right and the re-keying tax disappears for good. Get them wrong and you trade manual entry for duplicate-voucher cleanup, which is worse.

If you want a second opinion on whether to buy a connector or build, or you already know you need custom middleware done properly, that is the kind of work we do. Send us a sample voucher and a line on what data moves, and we will tell you honestly which path fits. Start at buildbyRaviRai.

If you already know you need Tally wired into your website, store, or CRM the right way, that is exactly what we build: idempotent middleware, clean GST and ledger mapping, a durable queue, and a full audit log of every push. Send us a sample voucher and one line on what data moves, and we will tell you honestly whether to buy a connector or build. → Talk to us about Tally integration

How to Actually Accept Payments in India in 2026: UPI, Cards, Autopay, and What Each One Really Costs

Ravi Rai — Sat, 11 Jul 2026 04:56:24 +0000

Sooner or later, every business that sells anything online has to answer a boring but expensive question: how do we actually take the money? In India, that question has a stranger answer than almost anywhere else. We have a national instant-payment rail that is free to accept, a regulator that rewrote the rulebook for payment companies in 2025, recurring payments that do not work the way a founder coming from Stripe expects, and card rules that forbid you from storing a card number at all. Get the setup right and payments fade into the background. Get it wrong and you leak money on fees, fail half your subscription renewals, or sit on a compliance problem you did not know you had.

This is the practical version, written for founders who want to understand what they are paying for and for developers who have to wire it up. We will cover the options and what each one really costs, the difference between a payment gateway and an aggregator, how UPI and cards and autopay actually behave, how to collect from customers abroad, and a checklist to go live. One honest caveat first: payment rules in India change often, and this is practical guidance, not legal or financial advice. Where a number is likely to move, we say so. Most of this comes from wiring payments into client products in production rather than from reading circulars, though we have read our share of those too.

The two things you are actually choosing

It helps to separate two decisions that usually get muddled together. The first is who holds and settles your money, which is your payment aggregator, the company whose account collects from your customer and then pays out to your bank. The second is which payment methods you accept: UPI, credit and debit cards, netbanking, wallets, and so on. You pick one aggregator and, through it, switch on the methods you want. Almost every business gets both by signing up with a single provider like Razorpay, Cashfree, or PayU, so in practice the real decision is which aggregator, and the methods are just toggles you turn on.

Gateway or aggregator: the distinction that trips people up

People use 'payment gateway' as a catch-all, but the RBI draws a sharp line between two things. A payment gateway is pure technology: it routes and processes a transaction without ever touching the funds. A payment aggregator actually collects your customers' money into its own account and then settles it to you, which means it handles the float. Because it holds money, an aggregator has to be authorised by the RBI. A pure gateway does not.

As of 2026 the governing rulebook is the RBI (Regulation of Payment Aggregators) Directions, 2025, notified on 15 September 2025, which replaced the older 2020 guidelines and folded online, offline, and cross-border aggregators into one framework. The part that matters to you as a merchant is simple: an authorised aggregator must keep your collected funds in a segregated escrow account at a scheduled commercial bank, and can use that account only for settling payments. That escrow rule is the safeguard that stops a payment company from quietly spending your float. The good news is you do not need your own aggregator licence. That path involves a net worth of ₹15 crore rising to ₹25 crore and a serious compliance burden. You just need to pick an aggregator that already holds one.

UPI: the rail that changed everything

If you sell to Indian consumers, UPI is not optional. It is how most people pay, and for merchants the headline is remarkable: accepting a UPI payment is free. There is no merchant discount rate on UPI person-to-merchant payments, which we get into properly below.

Mechanically, you collect over UPI in a few ways, and your aggregator handles most of the plumbing. There is the QR code, static or dynamic, that a customer scans. There is the intent flow, where tapping a button on your checkout opens the customer's UPI app with the amount already filled in. And there are UPI deep links for sharing a payable link over WhatsApp or SMS. One change worth knowing if you build your own checkout: the older payer-facing 'collect' request, where the merchant pushes a request that pops up in the customer's app, is being phased out for most cases from early 2026 in favour of the intent and QR flows, which are faster and harder to abuse.

On limits: the standard UPI cap is ₹1 lakh per transaction for most payments. Certain verified merchant categories can go higher. Payments to hospitals and educational institutions were raised to ₹5 lakh back in December 2023, and from September 2025 the NPCI allowed verified merchants in a set of specific categories, such as capital markets, insurance, and travel, to accept up to ₹5 lakh per transaction as well. The exact per-category caps vary, and your bank or aggregator may set a lower internal limit, so if you sell high-value items, confirm the current limit for your own category rather than assuming ₹5 lakh.

Cards, netbanking, and wallets: the rest of the menu

UPI covers most consumer payments, but you will still want cards for higher-value purchases, corporate buyers, and anyone paying from abroad. Credit and debit cards, netbanking, and wallets all come as toggles on your aggregator. The one rule every developer needs to internalise here is about storing card details: you cannot. Since the RBI's card-on-file tokenisation mandate took effect on 1 October 2022, neither merchants nor aggregators may store a raw card number, CVV, or expiry date. What you store instead is a token, a meaningless stand-in that is unique to that card, that customer, and your business, generated with the cardholder's consent. In practice your aggregator does the tokenisation and you just keep the token. If you were ever tempted to save a card number in your own database to make repeat checkout smoother, do not. It is both against the rules and a security liability you never want to carry.

What it actually costs

Here is the part founders actually care about. The costs split cleanly by method:

UPI and RuPay debit cards: zero. By law there is no merchant discount rate on these, so accepting them costs you nothing in transaction fees. This is the single biggest reason payments are cheaper to accept in India than almost anywhere.
Credit cards: around 2%. Credit card MDR is not capped by the RBI and typically lands near 2% for domestic cards, negotiable once your volume is large.
Debit cards other than RuPay: capped and small. The RBI caps debit card MDR at roughly 0.4% to 0.9% depending on merchant size, with a per-transaction rupee ceiling.
Standard aggregator pricing: about 2% plus GST. Most aggregators quote a flat rate near 2% per successful transaction on domestic cards, netbanking, and wallets, with no setup fee and no annual maintenance on the standard plan. Add 18% GST on the fee itself, so an advertised 2% is closer to 2.36% all-in.
International cards: up to 3%. Collecting from foreign cards costs more, commonly up to 3% plus GST.

Two things soften the fee. First, the 18% GST on your payment charges is generally claimable as input tax credit if your own sales are taxable, so for a GST-registered business the real cost is the fee, not the fee plus the tax. Second, because UPI is free and dominant, your blended cost of acceptance in India is usually far lower than a card-heavy business in the US or Europe would pay. On settlement, the money does not land instantly. The standard cycle is T+1, one banking day after the transaction, with cards often T+2, and most aggregators offer instant or same-day settlement for an extra fee. Under the 2025 Directions the aggregator holds your funds in escrow and settles on that cycle. If you invoice with GST, make sure your GST e-invoicing is wired to the actual settled amounts, not to the gross.

Recurring payments and autopay, the part everyone gets wrong

This is where founders coming from Stripe get surprised. In the US you save a card and quietly charge it every month. In India you cannot simply do that. Recurring payments run through the RBI's e-mandate framework, most commonly as UPI Autopay for consumers, and the rules are strict on purpose.

Setting up a mandate always requires the customer to authenticate once, with a UPI PIN or an OTP, the additional factor of authentication. After that, recurring debits run automatically, but only up to ₹15,000 per transaction without the customer re-authenticating each time. Above ₹15,000 the customer has to approve each debit. There is a higher no-authentication ceiling of ₹1 lakh for three specific categories: insurance premiums, mutual fund subscriptions, and credit card bill payments. On top of that, the bank must send the customer a pre-debit notification at least 24 hours before each charge, and the customer can cancel any single debit or the whole mandate. As of 2026 these rules sit inside the RBI's consolidated e-mandate framework, which pulled the older card, wallet, and UPI mandate circulars into one place, but the core numbers, ₹15,000, ₹1 lakh for the three categories, and the 24-hour notice, have been stable since 2023.

The practical upshot for a SaaS or subscription business: your billing has to be built around mandates and their limits, not around silently charging a card. You register a mandate, you handle the asynchronous confirmation and each debit through webhooks, and you reconcile carefully, which is exactly the kind of idempotent, callback-driven flow we wrote about in detail for Razorpay webhooks. If you are running a multi-tenant product, this billing logic usually lives in the same layer as the rest of your per-tenant billing.

Collecting from customers abroad

If you sell to customers outside India, whether that is a SaaS with global users or an exporter shipping goods, cross-border collection is its own regulated lane. It runs through the RBI's Payment Aggregator - Cross Border, or PA-CB, framework, first set out in a 2023 circular and now part of the 2025 Directions. Foreign currency lands in a dedicated export collection account and is converted and settled to you in rupees, with a per-transaction cap of ₹25 lakh.

The piece exporters miss is the paperwork that proves the money came in. For that you rely on a FIRC, or its digital form the FIRA, the foreign inward remittance certificate your bank issues, and the eBRC from the DGFT portal, which together prove that an export was realised. You need that proof for GST refunds on zero-rated exports and for any foreign-trade incentives. On providers, Razorpay, Cashfree, and PayU support international collection. PayPal shut its domestic India business back in 2021 and now works cross-border only, so it is an option for receiving from abroad but not for taking rupee payments at home. Stripe is worth flagging: it has been invite-only for new Indian businesses since around 2024, so do not assume you can just sign up. Verify its current status before you plan around it.

The zero-MDR question everyone asks

Founders often ask how UPI can possibly be free, and whether it will stay that way. The free part is law. Since 1 January 2020, merchant charges on UPI person-to-merchant payments and on RuPay debit cards have been prohibited, under provisions inserted into the Income-tax Act and the Payment and Settlement Systems Act. To offset the cost to banks, the government runs an incentive scheme for low-value UPI at small merchants.

Whether it stays free is a live debate. Through 2025 and into 2026, the payments industry pushed to bring back a small merchant fee on UPI for large merchants, arguing that free acceptance is not financially sustainable for the banks and networks that run the rail. The Finance Ministry publicly rejected reports of an imminent charge, and a parliamentary committee later suggested the government at least study a tiered model that would exempt small merchants and charge larger ones. As of mid-2026, nothing binding has changed: UPI remains free to accept. But this is the single most likely thing in this article to move, so if a lot of your margin depends on UPI staying free, keep an eye on it.

One genuine exception already exists. A RuPay credit card paid through UPI is a credit product, not a bank transfer, so it is not covered by the zero-MDR rule. Those transactions are free only up to ₹2,000, and above that they carry a merchant fee. It is a small slice of volume today, but worth knowing that your UPI acceptance is not uniformly free once credit-on-UPI is in the mix.

How we wire this up for clients

When we build payments into a product, the shape is almost always the same. We pick an aggregator based on the client's mix of UPI, cards, and international, integrate its APIs and SDKs, and put the real engineering effort into the parts that go wrong quietly. That means handling webhooks idempotently so a retried callback never double-credits an order, reconciling settled amounts against orders every day, and never storing a card number because the aggregator's token is all we keep. For subscriptions we build around e-mandates and their limits rather than fighting them. GST invoices are generated on the settled amount, and for exporters we make sure FIRC and eBRC are captured. Most of this lives on a Node.js backend where the webhook handling and reconciliation can be tested properly. None of it is exotic, but the difference between a payments integration that just works and one that quietly leaks money is entirely in these unglamorous details.

A realistic checklist to go live

If you are starting from zero, this is the order that works:

Sign up with one aggregator and finish KYC. Pick Razorpay, Cashfree, or PayU based on your fees and the features you need. KYC and activation take a few days, so start early.
Switch on UPI and cards first. UPI is free and covers most consumers, cards cover the rest. Add netbanking and wallets if your audience actually uses them.
Build webhook handling and reconciliation. Treat every payment callback as something that might arrive twice or out of order, and reconcile settled money against your orders daily. This is the part that protects your revenue.
Let the aggregator handle tokenisation. Never store raw card data. Keep only the token it gives you back.
Wire GST invoicing to settled amounts. Invoice on what actually settled, not the gross, and claim input tax credit on your payment fees.
If you bill recurring, set up e-mandates. Design around the ₹15,000 and ₹1 lakh limits and the 24-hour pre-debit notice, and process each debit through webhooks.
If you sell abroad, add a cross-border provider. Use a PA-CB-enabled aggregator and capture FIRC and eBRC as your export proof.
Test everything in sandbox first. Run success, failure, and retry cases before you take a single rupee live.

Common questions about accepting payments in India

Do I need my own payment aggregator licence to accept payments?

No. The RBI licence is for the company that holds and settles funds, which is your aggregator, not you. For virtually every business you sign up with an authorised aggregator like Razorpay, Cashfree, or PayU and use their licence and escrow setup. You would only need your own authorisation if you were building a platform that collects and settles money on behalf of other merchants, and that comes with a net worth requirement of ₹15 crore rising to ₹25 crore plus heavy compliance.

How much does it cost to accept online payments in India?

It depends on the method. UPI and RuPay debit cards are free by law. Credit cards run around 2%, and standard aggregator pricing is about 2% plus 18% GST on domestic transactions, with no setup or annual fee on most standard plans. International cards cost up to 3%. Because UPI is both free and the most-used method, most Indian businesses pay a much lower blended rate than a card-heavy business elsewhere would.

Can I charge a customer's card automatically every month like a US SaaS?

Not directly. India routes recurring payments through the RBI e-mandate framework, usually UPI Autopay. The customer authenticates once to set up the mandate, after which debits run automatically only up to ₹15,000 per transaction, or ₹1 lakh for insurance, mutual funds, and credit card bills, and the bank must notify them 24 hours before each charge. You build your billing around mandates, not around silently charging a saved card.

Is it true I cannot store customer card numbers?

Yes. Since October 2022 the RBI's tokenisation mandate forbids merchants and aggregators from storing raw card numbers, CVV, or expiry dates. Your aggregator replaces the card with a token that is useless to anyone else, and that token is all you keep. This is a good thing: it removes the single most dangerous piece of data from your servers.

How do I collect payments from customers outside India?

Through a cross-border aggregator under the RBI's PA-CB framework. Foreign currency settles to you in rupees, capped at ₹25 lakh per transaction, and you capture a FIRC or FIRA from your bank plus an eBRC from the DGFT portal as proof of the export, which you need for GST refunds and trade incentives. Razorpay, Cashfree, and PayU support this. PayPal works cross-border only, and Stripe has been invite-only for new Indian merchants, so check availability before planning around either.

Will UPI stay free for merchants?

As of mid-2026, yes, it is still free, and there is no notification changing that. But the industry has been pushing to reintroduce a small merchant fee on UPI for large merchants, and a parliamentary committee has suggested studying a tiered model. Nothing binding has happened yet, but this is the most likely rule in this space to change, so watch it if your margins lean heavily on free UPI.

Honest summary

Accepting payments in India comes down to a few clear ideas. You sign up with one authorised aggregator and switch on the methods you want, and you do not need your own licence. UPI is free and covers most consumers, cards cost around 2% and cannot be stored in raw form, and standard aggregator pricing is roughly 2% plus GST with settlement on a T+1 cycle. Recurring payments run through e-mandates with real limits and a 24-hour notice, so subscription billing has to be designed around them rather than bolted on. Selling abroad means a cross-border provider and some export paperwork. And the whole thing rewards boring engineering: idempotent webhooks, daily reconciliation, tokenised cards, and GST invoices on settled amounts. Get those right and payments become the part of your product you never have to think about again.

Setting up payments for a new product, or untangling a setup that is leaking money on fees or failing renewals? Message us on WhatsApp with what you are selling and who you are selling to, and we will tell you honestly which aggregator and which methods make sense, and what it will actually cost you.

We build payment flows into web and SaaS products the right way: the correct aggregator for your mix of UPI, cards, and international, webhooks handled idempotently so nothing double-charges, clean daily reconciliation, tokenised cards, e-mandates for subscriptions, and GST-ready invoicing on settled amounts. If you want payments that just work and do not quietly leak money, let us wire it up. → Talk to us about payments

The DPDP Act in 2026: A Practical Compliance Guide for Indian Websites and SaaS

Ravi Rai — Sun, 05 Jul 2026 07:16:13 +0000

If you run a website or a SaaS product in India, you have probably heard that a big data protection law is coming and that the fines run into hundreds of crores. Both halves of that sentence are true, but the timing and the practical reality are more nuanced than the panic posts on LinkedIn suggest. This is the honest version, written by developers who build and ship Indian products, not a law firm memo and not a compliance-vendor sales pitch.

Here is the short story. The Digital Personal Data Protection Act, 2023 (the DPDP Act) got Presidential assent back in August 2023, but it sat dormant for two years because the government had not written the Rules that make it work. Those Rules were finally notified in November 2025. So as of mid-2026, the law is real and final, but the obligations most businesses actually care about are not enforceable yet. They switch on in stages, with the main deadline landing around mid-May 2027. You are in the preparation window, not the panic window.

We think that is genuinely good news, because it means you have time to do this properly instead of bolting on a cookie banner the night before an audit. Below we walk through what the Act is, whether it applies to your business (spoiler: almost certainly yes), the core duties in plain English, how you actually build the technical bits, the penalties, and a realistic plan for what to do this quarter. One disclaimer up front: this is practical guidance to help you get oriented and start work, not legal advice. For a binding opinion on your specific setup, talk to a data protection lawyer.

What the DPDP Act actually is, and where it stands in 2026

The DPDP Act is India's first proper, standalone data protection law. Before it, the only thing governing personal data online was the Information Technology Act, 2000 and its 2011 SPDI Rules, which are thin and outdated. The DPDP Act replaces that patchy regime with something closer in spirit to the EU's GDPR, though it is leaner and built differently (more on the differences later).

The law works on a simple pair of roles. If you decide why and how personal data gets processed, you are a Data Fiduciary (GDPR calls this a controller). The person whose data it is, your user, is the Data Principal. Anyone who processes data on your behalf, like your cloud host or your email tool, is a Data Processor. Personal data is defined broadly as any data about an individual who is identifiable from it. Importantly, the Act only covers digital personal data: data collected in digital form, or collected on paper and later digitised. A paper register that never gets typed up is outside the Act, though in practice almost everything ends up digital anyway.

On status, be precise, because a lot of online write-ups get this wrong. MeitY notified the Digital Personal Data Protection Rules, 2025 in mid-November 2025 (most sources say 13 November, with Gazette publication on 14 November). That notification did not switch everything on at once. Commencement is deliberately phased into three tranches:

Phase 1 (immediate, from November 2025): the definitions and the provisions that set up the Data Protection Board of India. These are live now.
Phase 2 (around November 2026): the Consent Manager registration regime, roughly 12 months after notification.
Phase 3 (around mid-May 2027): the substantive duties that matter most to you, notice and consent, security safeguards, breach reporting, retention and erasure, children's data, Significant Data Fiduciary duties, cross-border transfer, and Data Principal rights. This is roughly 18 months after notification.

So as of 5 July 2026, only Phase 1 is in force. The core compliance duties are not yet enforceable. Until they are, the old IT Act and 2011 SPDI Rules still technically govern data protection in the interim. One more honest caveat: the Data Protection Board, the body that will actually adjudicate complaints and hand out penalties, was still being constituted through mid-2026. MeitY only invited applications for its Chairperson and Members in May 2026. So even the enforcement machinery is being built out as we write this. Treat mid-May 2027 as your working deadline, not a date that has already passed.

Does this apply to my small business?

Almost certainly yes, and this is the single most common myth we need to kill. There is no small-business, MSME, turnover, or user-count exemption in the DPDP Act. If you collect an email address for a newsletter, store customer phone numbers, run a login system, or drop an analytics cookie that captures an IP address, you are processing digital personal data and you are a Data Fiduciary. A two-person startup in Noida is in scope exactly like a large e-commerce platform.

There is one wrinkle worth being honest about. Section 17(3) of the Act gives the government the power to exempt certain classes of Data Fiduciary, and it specifically names startups, from some duties like the notice requirement and parts of the erasure and access obligations. But that is only an enabling power. As of mid-2026, the government has not actually issued any such notification. So you cannot plan around a startup exemption that does not exist yet. It may arrive before May 2027, or it may not. Build for full compliance and treat any future relaxation as a bonus.

The reach is also wider than you might expect. The Act applies to processing inside India, and it applies extra-territorially to businesses outside India that process the data of people in India in connection with offering them goods or services. So a foreign SaaS serving Indian users is squarely covered. If you are an Indian agency or product company serving Indian customers, there is no doubt at all: this is your law.

The core obligations in plain English

Strip away the legalese and the DPDP Act asks you to do a handful of sensible things. Here they are the way we would explain them to a founder over coffee.

Consent and notice. The default lawful basis for processing is consent, and consent has to be free, specific, informed, unconditional, and unambiguous, given by a clear affirmative action. In plain terms: no pre-ticked boxes, no burying agreement inside a giant terms-and-conditions blob, no bundling ten unrelated purposes into one "I agree". Every consent request must be preceded or accompanied by a notice that tells the user what data you are collecting, why, how to exercise their rights, and how to complain to the Data Protection Board. The notice has to be a standalone document in clear, plain language, and you must offer it in English or any of the 22 languages in the Eighth Schedule of the Constitution. And withdrawing consent must be as easy as giving it.

Purpose limitation and minimisation. You can only collect the data you actually need for the stated purpose, and you can only use it for that purpose. Want to use the same data for something new? Fresh notice, fresh consent.

Security safeguards. You must protect personal data with reasonable security measures. The Rules spell out a floor: encryption or masking or tokenisation, access controls, logging and monitoring, backups, and one year of retained logs. Failing this is the single most expensive thing you can get wrong under the Act, so it is worth doing well.

Retention and erasure. Delete personal data once the purpose is done or the user withdraws consent, unless a law requires you to keep it. For a few very large classes (big e-commerce, gaming, and social media platforms above specified user thresholds), the Rules add a hard three-year auto-delete clock for inactive users, with 48 hours' advance notice before deletion.

Breach notification. If you have a personal data breach, you must tell every affected user without delay, and give the Data Protection Board an initial intimation followed by a detailed report within 72 hours. There is no "it was minor so we skipped it" exemption. Unlike GDPR, DPDP has no harm threshold: any breach triggers the duty.

Grievance redressal and a contact point. You must publish the business contact of a person (or Data Protection Officer, where applicable) who can answer questions about your processing, and run an effective grievance mechanism that responds within a published timeline of no more than 90 days. Users have to exhaust your grievance process before they can go to the Board.

What actually changes for developers

This is the part we care about most, because DPDP compliance is at least half an engineering problem. Here is how the duties above translate into things you build.

Treat consent as versioned data, not a boolean. A single agreed = true column will not cut it. You need a consent object keyed to purpose, so a user can agree to "process my email for order updates" without agreeing to "send me marketing". And you need an audit-grade record of each consent event: the exact notice text or version shown, the purposes chosen, the timestamp, and the affirmative action taken, plus any later withdrawal. Think of it as an append-only consent ledger. If the Board ever asks, you need to reconstruct exactly what a given user saw and chose on a given date.

Build a real privacy notice, not a wall of text. Replace the single "Privacy Policy" link at signup with a purpose-specific, itemised notice: what fields, what purpose, and clickable links to withdraw consent, exercise rights, and complain to the Board. Multilingual delivery is expected, so architect your notice content so it can be served in more than just English.

Do not forget your existing users. For data you already hold, you do not need fresh opt-in. Section 5(2) lets you send a one-time notice to your legacy base covering what you hold and why, and you can keep processing until they withdraw. Practically, that is a one-off email, SMS, WhatsApp, or in-app campaign with embedded withdraw and rights links, and you should log delivery. Plan that campaign now; it is a clean, contained piece of work.

Build self-serve rights flows (DSAR). Users get rights to access a summary of their data, to correct it, and to erase it, plus grievance redressal and a right to nominate someone to act on their behalf if they die or become incapacitated. In code, that means authenticated endpoints for access/export, correction, and deletion, an identity-verification step, an SLA timer or ticketing workflow, and crucially, cascade deletion that propagates to your processors and backups. If you run a multi-tenant product, get this right at the tenant-isolation level; our multi-tenant SaaS architecture guide covers the data-boundary patterns that make per-user erasure actually tractable.

Nail the security baseline. The Rule 6 floor is concrete: encrypt personal data at rest and in transit, enforce least-privilege access with audit logging retained at least 12 months, run monitoring to detect unauthorised access, keep tested backups, and bind your processors contractually to the same standards. If you want a ground-up walkthrough of the fundamentals, we wrote website security basics for Indian businesses, and moving your users off shared passwords onto passkeys and passwordless auth is one of the highest-leverage things you can do to shrink breach risk. If your infra is a mess, our cloud and DevOps team does exactly this kind of hardening.

Draw a data map. DPDP has no explicit GDPR-style "record of processing" requirement, but you cannot satisfy retention, erasure, breach-scoping, or audits without knowing what personal data you hold, where it lives, which processor touches it, and what purpose and retention clock each field carries. So build the inventory anyway. It is the backbone artefact everything else hangs off.

Put processor contracts in place. You can only use a processor under a valid contract, and you stay fully liable for their compliance. So every sub-processor (cloud, analytics, email, payments) needs a data processing agreement that flows down security obligations, breach cooperation to meet your 72-hour clock, help with user requests, and deletion on termination or consent withdrawal. If you handle payments, the same discipline that makes your Razorpay webhooks idempotent and reconciled is the mindset you want across every processor boundary.

Children's data and Significant Data Fiduciary duties

Two areas carry heavier duties, and both are worth flagging early because they are hard to retrofit.

Children. Under the DPDP Act a "child" is anyone under 18, which is a much higher bar than GDPR's 13 to 16. Before processing a child's data you need verifiable consent from a parent or lawful guardian, and you have to verify that the consenting adult really is an identifiable adult, using details you already hold, details they provide, or a virtual token tied to verified age and identity from an authorised entity (think a DigiLocker-type credential). On top of that, you are barred from tracking, behavioural monitoring, or targeted advertising directed at children. This is genuinely difficult to implement at scale, partly because robust age verification pushes against data minimisation (you may end up collecting more identity data to prove age), and partly because the authorised-token infrastructure was not widely deployed as of mid-2026. There are carve-outs for specific contexts like healthcare, education, childcare, and safety-related location tracking, but a general website or SaaS gets no relief. The same verifiable-guardian regime extends to persons with disabilities who cannot make legally binding decisions.

Significant Data Fiduciaries (SDFs). This is not automatic. The government designates an entity as an SDF by notification, based on factors like data volume, sensitivity, and risk to individuals or to the state. Once designated, you carry extra duties: appoint an India-based Data Protection Officer answerable to your board, appoint an independent data auditor, run a Data Protection Impact Assessment and an audit at least every 12 months, do due diligence that your algorithms do not pose risks to users' rights, and comply with any government order to keep specified data inside India. As of mid-2026 no public list of designated SDFs had been confirmed, so unless you are notified, these duties do not apply to you yet. But if your product is scaling fast, keep this on your radar.

How DPDP differs from GDPR, and the cookie-banner myth

If you have GDPR muscle memory, do not just copy-paste it. The two laws share a philosophy but differ in ways that matter operationally.

Lawful bases. GDPR gives you six, including the flexible "legitimate interests" and "contractual necessity". DPDP gives you effectively two: consent, or a closed, fixed list of "legitimate uses" (things like data a person voluntarily gave you, state functions, legal compliance, medical emergencies, and certain employment purposes). There is no open-ended legitimate-interest ground and no balancing test for private firms. So most private-sector processing in India must be consent-based, which raises the bar on your consent capture.
No sensitive-data category. GDPR singles out health, biometric, religious, and other special categories for extra protection. DPDP has one uniform standard for all personal data. It layers extra duties by entity (the SDF mechanism) rather than by data type.
Cross-border transfers. GDPR uses a whitelist (transfer is banned unless the destination is approved). DPDP inverts this: transfer is allowed by default, except to countries the government specifically blacklists. As of mid-2026 no such blacklist had been notified. Sectoral rules like RBI's payment-data localisation still apply independently, and the government can restrict specified data categories, so "free by default" is the headline but not absolute.
Scope. DPDP covers only digital personal data. GDPR also covers structured paper filing systems.

Now the cookie question, because it is the most misunderstood. DPDP never mentions the word "cookie" and it imposes no EU ePrivacy-style banner mandate. That does not mean cookies are unregulated. Where a cookie or tracker collects personal data (an IP, a device ID, behavioural data) on a consent basis, the general DPDP notice-and-consent machinery applies. Strictly necessary cookies (session, auth, cart) can plausibly ride the "legitimate uses" exception and may not need explicit consent. Analytics, advertising, and behavioural-tracking cookies do need consent. One real difference from the EU: GDPR effectively expects granular, per-vendor toggles, while under DPDP granular consent is best practice but not strictly required, so an all-or-nothing accept/decline is currently acceptable. Cookie walls and coercive designs are out, because consent must be free. Honest caveat: this area is the least settled, drawn mostly from law-firm commentary rather than any Board ruling, and the Board could push toward GDPR-style granularity later. So build for flexibility.

The penalties, without the scaremongering

Yes, the numbers are large. The Act's Schedule sets tiered maximum penalties per breach category:

Up to ₹250 crore for failing to take reasonable security safeguards. This is the headline figure and the single most expensive thing to get wrong.
Up to ₹200 crore for failing to notify a personal data breach.
Up to ₹200 crore for breaching the children's-data obligations.
Up to ₹150 crore for a Significant Data Fiduciary breaching its extra duties.
Up to ₹50 crore as a residual catch-all for any other contravention.
Up to ₹10,000 on a Data Principal who abuses the system (files false or frivolous complaints, or supplies fake information).

Two things to keep in perspective. First, these are maximums per breach, not a fixed fine and not a single aggregate cap, and one incident could in theory trigger more than one head. When the Board sets the actual amount, it weighs the nature, gravity, and duration of the breach, the type of data, whether you took mitigating action, and proportionality. A tiny startup that made a good-faith mistake is not going to be treated like a negligent giant. Second, and this is the calming part: these penalties are not live yet. The Data Protection Board was still being constituted through mid-2026 and no penalty orders had been reported. The enforceable date for the substantive duties is around mid-May 2027. Notably, penalties go to the Consolidated Fund of India; the Act does not give affected individuals a right to compensation, so the remedy runs through the Board, not through damages suits.

If you get an adverse order later, you can appeal to TDSAT (the Telecom Disputes Settlement and Appellate Tribunal) within 60 days, and the bare Act does not require you to pre-deposit any part of the penalty to appeal. Ignore any blog claiming a 50% pre-deposit rule; that is not in the law.

What to actually do this quarter

You have until roughly mid-May 2027 for the main duties, and Consent Manager registration lands around November 2026. That is enough runway to do this calmly if you start now. Here is a realistic order of work for an Indian SMB or startup:

Map your data. List every place you collect personal data, what fields, why, where it is stored, which processor touches it, and how long you keep it. Nothing else works without this.
Audit your security against the Rule 6 floor. Encryption at rest and in transit, access controls, logging with 12-month retention, monitoring, backups. Fix the gaps here first, because this carries the biggest penalty.
Redesign your signup consent. Kill pre-ticked boxes and bundled agreement. Build a purpose-keyed consent record and a plain-language, itemised notice with withdraw and rights links.
Build the withdraw and rights flows. A self-serve way to withdraw consent, plus access, correction, and erasure endpoints with cascade deletion to processors and backups.
Plan your legacy-user notice. Draft the one-time Section 5(2) notice campaign for your existing database and log delivery.
Sign processor DPAs. Get data processing agreements in place with your cloud, email, analytics, and payment vendors, flowing down security and deletion duties.
Set up breach and grievance processes. A breach-detection and 72-hour reporting playbook, and a published grievance contact with a response timeline under 90 days.
If you touch children's data, address age-gating early. It is the hardest piece, so do not leave it to the end.
Write it down. Keep a simple internal record of what you did and when. If the Board ever asks, demonstrable good-faith effort matters.

That is not a weekend job, but it is also not a crisis. Most of it is good engineering hygiene you would want anyway. If your team is stretched, this is the kind of retrofit our Node.js development team does regularly: consent ledgers, DSAR endpoints, and security hardening baked into an existing product without tearing it apart.

Common questions about the DPDP Act

Is the DPDP Act in force in 2026?

Partly. The Act is enacted and the DPDP Rules, 2025 were notified in mid-November 2025, so it is final law. But enforcement is phased. As of mid-2026 only Phase 1 is live (the Data Protection Board framework and definitions). Consent Manager registration comes around November 2026, and the core duties, notice, consent, security, breach reporting, retention, children's data, and Data Principal rights, become enforceable around mid-May 2027. So the substantive obligations are not yet enforceable, but you should be preparing for them now.

Does the DPDP Act apply to my small business or startup?

Yes. There is no size, turnover, or user-count exemption. Any business that processes digital personal data, even just customer emails or login details, is a Data Fiduciary. The Act does let the government carve out startups from some duties in future, but no such exemption had been notified as of mid-2026, so plan for full compliance.

Do I need a GDPR-style cookie banner for a DPDP website?

Not exactly. DPDP does not mention cookies and has no ePrivacy-style banner mandate. But if your cookies collect personal data on a consent basis (analytics, advertising, behavioural tracking), you need a DPDP-compliant notice and consent flow, which is similar in spirit but different in form from an EU banner. Strictly necessary cookies can often rely on the legitimate-uses exception. Granular per-vendor toggles are best practice but not strictly required under DPDP as it stands.

What are the penalties under the DPDP Act?

The Schedule sets maximums per breach: up to ₹250 crore for weak security safeguards, up to ₹200 crore each for breach-notification failures and children's-data violations, up to ₹150 crore for Significant Data Fiduciary failures, and up to ₹50 crore as a catch-all. These are ceilings, not fixed fines; the Board weighs gravity, data type, and mitigation. They are also not being actively enforced yet, since the main duties commence around mid-May 2027 and the Board was still being set up in mid-2026.

What is the deadline to become DPDP compliant?

Treat around mid-May 2027 as your working deadline for the core Data Fiduciary duties, roughly 18 months after the November 2025 notification. Consent Manager obligations arrive earlier, around November 2026. Dates shift by a day depending on whether you count from the 13 November signing or the 14 November Gazette publication, so read it as mid-May 2027 rather than a single settled date.

The honest summary

The DPDP Act is real, final, and it applies to almost every Indian website and SaaS, including small ones. But as of mid-2026 the duties that carry the scary penalties are not enforceable yet, and the Board that would enforce them is still being staffed. That combination is a gift: you have a genuine runway to mid-2027, and most of the work (know your data, secure it, get consent honestly, let people withdraw and delete) is stuff a well-run product should do anyway. Do not panic, do not buy a fear-driven compliance package, and do not believe anyone who tells you it is already fully in force or that startups are automatically exempt. Both are wrong. Start with your data map and your security baseline this quarter, and work through the rest in order.

A last honest note: this guide is meant to orient you and get engineering moving, not to serve as legal advice. Section and rule numbers and exact dates in the public commentary vary slightly, and the wording that binds you is the official MeitY-published Act and Rules. For a formal opinion on your specific business, work with a data protection lawyer. If you want a hand translating any of this into actual code and infrastructure, that is our day job, and we are happy to do a quick DPDP-readiness look at your site or app. You can message us on WhatsApp or send us the details and we will tell you honestly where you stand and what is worth doing first.

Want a straight, no-jargon read on how DPDP-ready your website or SaaS is? We will map your data flows, check your consent and security setup against the Rules, and give you a prioritised fix list with flat INR quotes and GST invoices. No fear-selling, just what actually needs doing before mid-2027. → Get a DPDP-readiness review of your site or app

From Excel to a CRM in 2026: When to Switch, and How to Move Without the Chaos

Ravi Rai — Mon, 29 Jun 2026 20:16:56 +0000

Nearly every business starts the same way. Sales lives in a spreadsheet. One tab for leads, one for customers, a column for status, and a colour code only the person who built it really understands. For a while this works beautifully, and anyone who tells you to buy a CRM on day one is usually selling one. A spreadsheet is free, flexible, and instant. The trouble is that it scales right up until it doesn't, and the day it stops working, it stops working quietly. No alarm goes off. You just start losing deals you never knew you had.

This post is the honest version of the Excel-to-CRM conversation. Not a pitch to rip out your sheet tomorrow, but a clear way to tell when you have genuinely outgrown it, what a migration actually involves, how to move your data over without losing your history, and the part everyone underestimates: how to get your team to actually use the new system instead of drifting back to the old one. We have moved enough businesses off spreadsheets to know where it goes wrong.

If you want to see what the other side looks like before reading on, you can explore the BuildByRavi CRM live demo and click through a real pipeline, dashboard, and reports. Log in with demo@buildbyravi.com and the password Demo@2026. Seeing a working pipeline next to your spreadsheet makes the gap obvious faster than any list of features.

When a spreadsheet is still the right answer

Let us be fair to the spreadsheet first, because switching too early wastes money and goodwill. If you are one or two people, your deal volume is low enough that nothing slips, you can hold the whole pipeline in your head, and you are still figuring out what your sales process even is, a sheet is perfect. It costs nothing, it bends to whatever you need, and there is no setup. Plenty of healthy businesses run on Excel or Google Sheets far longer than a software salesperson would like to admit. The question is not whether spreadsheets are good or bad. It is whether yours has started leaking.

The signs you have outgrown the sheet

You rarely decide to leave the spreadsheet. You notice, one painful incident at a time, that it can no longer hold your business. The common signs:

Leads are falling through gaps. Someone meant to follow up, the row scrolled out of view, and three weeks later the customer bought from a competitor who simply replied. If you cannot say what the next action is for every open deal, the sheet is failing at its one job.
More than one person needs it at once. The moment two or three people edit the same file, you get version conflicts, overwritten cells, and the dreaded 'final_v3_latest' copies. Spreadsheets were never built for a team working a shared pipeline.
Nobody trusts the numbers. When the forecast in the sheet and reality have quietly drifted apart, every meeting turns into an argument about whose copy is right instead of which deals to chase.
Follow-up depends on memory. A spreadsheet cannot remind you, message a customer, or chase a quote on its own. If your follow-up only happens when a human remembers, you are losing the deals that needed a second or third touch.
You cannot see history. Who spoke to this customer last, what was said, what was promised? A sheet shows the current state, not the story, and that story is where deals are won or lost.
Reporting takes hours. If pulling a simple 'how many deals did we close this month and why did we lose the rest' answer means an evening of copy-paste, the sheet has become the bottleneck.

One of these is a nuisance. Three or more, week after week, is the spreadsheet telling you it is done. The cost is rarely a dramatic disaster. It is the slow, invisible bleed of deals that quietly went nowhere because the system forgot them.

What you actually gain by moving

A CRM is not a fancier spreadsheet. The point of moving is to get things a sheet structurally cannot do. Every contact carries its full history, so anyone can pick up a conversation without asking around. Follow-up runs on its own through reminders and automated sequences, so the second and third touch happen whether or not anyone remembers. The whole team works one shared pipeline in real time with no version conflicts. The forecast reflects what is actually happening rather than someone's optimism. And in India specifically, the conversation can live on WhatsApp where deals really close, logged against the right lead instead of trapped on one person's phone. We walked through each of these in detail in what a modern sales CRM should do. The short version: a CRM stops you losing deals you never knew you were losing.

How a migration actually works

The word 'migration' sounds heavier than it is. For most small and mid-sized businesses, moving off a spreadsheet is a few focused days, not a quarter-long project, as long as you do it in the right order:

Clean the sheet first. A migration is the best chance you will ever get to throw out dead leads, duplicate rows, and the columns nobody has filled in for a year. Move tidy data, not a mess, because garbage that goes in is garbage that comes out, now in a more expensive tool.
Map your columns to fields. Decide what each spreadsheet column becomes in the CRM: which is the contact name, the company, the deal value, the stage, the owner. This mapping is the real work, and getting it right is what makes the new system feel like yours.
Define your stages honestly. Your pipeline stages should match how you actually sell, not a generic template. New lead, contacted, quoted, negotiating, won, lost is a fine start. The CRM should fit your process, not force you into someone else's.
Import in one clean pass. Export the sheet to CSV, import it, and check a handful of records by hand to confirm everything landed in the right place. A good CRM import is mostly a file upload and a column match.
Keep the old sheet read-only for a bit. Do not delete it on day one. Freeze it as a backup and a reference for a few weeks until everyone trusts the new system, then archive it.

That is the whole shape of it. The data move is the easy part. The hard part, the part that decides whether the migration succeeds, comes next.

The real challenge is adoption, not data

Here is the uncomfortable truth that most CRM articles skip: roughly half of CRM rollouts fail, and almost never because the data did not import. They fail because the team quietly goes back to the spreadsheet. If the CRM feels heavier than the sheet it replaced, reps will route around it, keep their real pipeline in WhatsApp and a private tab, and within a month your shiny new system is a half-empty graveyard that everyone lies to in meetings. Avoiding that is mostly about a few human choices, not technology:

Make it lighter than the spreadsheet, not heavier. If logging a deal takes more clicks than typing a row, you have already lost. The CRM has to remove work, not add it.
Start with only the fields you need. A new system with forty mandatory fields is a system nobody fills in. Begin with the handful that matter and add more once the habit sticks.
Move everyone at once. If half the team is on the CRM and half is still on the sheet, both fail. Pick a date, move together, and freeze the old sheet so there is no fallback.
Let leadership live in it. If the boss still asks for updates over WhatsApp and reads the old spreadsheet, the team learns the CRM is optional. When the forecast everyone is judged on comes out of the CRM, the CRM gets used.
Show the win early. Nothing drives adoption like a rep closing a deal because the system reminded them to follow up. Find that story in the first two weeks and tell it.

Get adoption right and the migration pays for itself fast. Get it wrong and the cleanest data import in the world ends up in a tool nobody opens.

Off-the-shelf, or built around how you sell?

Once you have decided to move, the next fork is which CRM. The global names, Salesforce and HubSpot, are powerful but heavy, priced in dollars, and they make you bend your process to fit their software, which is exactly the friction that kills adoption for a small Indian team. We broke down the real numbers in custom CRM vs Salesforce and HubSpot. For most businesses coming off a spreadsheet, the better fit is a focused CRM that matches your workflow out of the box, or a custom one shaped around exactly how you sell, with only the modules you need. For marketplace and multi-seller businesses we package this as the MultiVendor CRM. The deciding question is never which CRM has the most features. It is which one your team will actually use.

What it costs to make the move

Cost has two parts, and people usually only think about the first. There is the price of the CRM itself, which for a small team can start free and scale with seats, and there is the cost of the move: cleaning data, mapping fields, importing, and training the team. The second is almost always the bigger number, and it is mostly time rather than money. Set against that is the cost of staying on the spreadsheet, which is invisible precisely because you never see the deals it loses. Most businesses that switch find the migration pays for itself within a couple of months of recovered, no-longer-leaking deals. If you want a rough figure for a custom build shaped around your process, the cost calculator gives a starting estimate, and the honest comparison lives in our custom CRM pricing guide.

How we handle the move

When we move a business off a spreadsheet, we treat the migration and the adoption as one job, because a perfect import that nobody uses is a failure. We clean and map your data, set up the stages and fields to match how you actually sell, import your history so nothing is lost, and get your team to a usable pipeline before adding anything fancy. Under the hood, BuildByRavi CRM is a multi-tenant web application on a Node.js backend with WhatsApp messaging built in, and when a business needs something specific to how it sells, we customise from what we have already built rather than starting from a blank page. You get a real working system in days, not a six-month software project.

Common questions about moving from Excel to a CRM

When should I move from a spreadsheet to a CRM?

When the spreadsheet starts costing you deals rather than saving you money. The clearest signals are leads slipping through the cracks, more than one person needing the file at once, follow-up depending on memory, and reporting taking hours. If one or two of those are happening occasionally, the sheet is probably still fine. If three or more happen every week, you have outgrown it and the leak is real.

Will I lose my data when I move to a CRM?

No, a proper migration keeps all of it. You export your spreadsheet to CSV, map each column to a CRM field, and import it in one pass, then spot-check a few records to confirm everything landed correctly. The smart move is to keep the old sheet frozen as a read-only backup for a few weeks until everyone trusts the new system, so there is always a safety net during the switch.

How long does it take to move from Excel to a CRM?

For most small and mid-sized businesses, the data move is a few days, not months. Cleaning and mapping the data is the real work; the import itself is mostly a file upload and a column match. What takes longer, and matters more, is adoption: giving the team a couple of weeks to build the habit of working in the CRM instead of the sheet. The technology is fast. The behaviour change is what to plan for.

Why do CRM rollouts fail, and how do I avoid it?

They fail because the team quietly returns to the spreadsheet, almost always because the CRM felt heavier than the sheet it replaced. Avoid it by making the CRM lighter to use than Excel, starting with only the fields you truly need, moving the whole team on one date with no fallback, and having leadership read the forecast out of the CRM rather than asking for updates elsewhere. Adoption is a human problem, not a software one.

Is a free CRM enough, or do I need a custom one?

For a small team just leaving a spreadsheet, a focused CRM with a free or low-cost tier is often the perfect first step, and far better than staying on Excel. You move to a custom build when your sales process is specific enough that off-the-shelf tools force you to work around them, or when you need particular integrations like WhatsApp, payments, or your accounting tool. Start with what gets you off the sheet fastest, and customise once you know exactly what you need.

Honest summary

Spreadsheets are a great place to start and a terrible place to scale. You have outgrown yours when leads start slipping, the team trips over a shared file, follow-up depends on memory, and nobody trusts the numbers. Moving off it is not the heavy project people fear: clean the data, map the columns, import in one pass, and keep the old sheet as a backup. The part that actually decides success is adoption, so make the CRM lighter than the spreadsheet, move everyone together, and let leadership live in it. Do that, and you stop losing the deals the sheet was quietly dropping.

Still running sales on a spreadsheet and feeling the cracks? See the BuildByRavi CRM live demo (log in with demo@buildbyravi.com and password Demo@2026), then message us on WhatsApp with how your sheet is set up today and we will tell you honestly whether it is time to move and what it would take.

Outgrowing the spreadsheet? We move Indian businesses from Excel to a CRM the right way: clean your data, import your history, set up the pipeline around how you actually sell, plug in WhatsApp, and get your team genuinely using it instead of drifting back to the sheet. See what we have built, then let us move you. → Explore the MultiVendor CRM

What a Modern Sales CRM Should Do in 2026 (Inside BuildByRavi CRM)

Ravi Rai — Sun, 28 Jun 2026 08:20:59 +0000

Most businesses do not lose deals because their product is weak. They lose deals because follow-up leaks. A lead comes in, someone means to call back, and three days later it is buried under newer work. The spreadsheet forgot, the sticky note vanished, and a customer who was ready to buy quietly went to whoever replied first. A CRM exists to stop that leak. We built BuildByRavi CRM as our own take on what a modern sales platform should do, and this post is a walk through what is inside it and why each piece earns its place.

One honest thing up front: a CRM is only worth it if your team actually uses it. Half of CRM rollouts fail because the tool is heavier than the problem it solves, so reps go back to WhatsApp and notebooks. So everything here is built around speed and clarity, not a feature checklist. A good CRM should feel like it removes work, not adds it.

Prefer to see it rather than read about it? You can explore the BuildByRavi CRM live demo and click through the dashboard, pipeline, and reports as you go. Log in with demo@buildbyravi.com and the password Demo@2026. Here is what each part does and why it is there.

Find the leads worth chasing

Most pipelines are full of names that will never buy. The cost is not just wasted time, it is that real buyers get the same lukewarm attention as dead ones. BuildByRavi CRM filters prospects by intent signals, so reps spend their hours on the accounts actually showing buying behaviour instead of working the list top to bottom. The job of a CRM is not to store every contact, it is to point you at the next right conversation.

Let the follow-up run itself

Follow-up is where humans are weakest and software is strongest. BuildByRavi CRM runs multi-step sales sequences with built-in A/B testing, so the second, third, and fourth touch happen on schedule whether or not anyone remembers. No-code automation workflows handle the busywork around them: move a deal stage, assign an owner, fire a reminder, log an activity, all without a developer. The rep does the human part, the talking, and the system does the parts humans forget.

Meet customers where they already are: WhatsApp

In India, deals do not close over email. They close on WhatsApp. A CRM that ignores that is fighting reality, so BuildByRavi CRM has WhatsApp Business messaging built in, with conversations logged against the right lead instead of trapped on one rep's phone. If you are weighing this seriously, we wrote a full guide to a WhatsApp CRM setup and cost, and a primer on what the WhatsApp Business API actually is. For Indian sales teams, this single feature usually moves the needle more than any other.

Know which deals are real

Every founder has been burned by a forecast built on optimism. A rep says a deal is 'almost closed' and it slips for the third month running. BuildByRavi CRM uses AI-powered forecasting and deal risk scoring to flag the deals that are stalling, the ones with no recent activity, and the ones the numbers say will not land, so your forecast reflects what is actually happening rather than what everyone hopes. Knowing a deal is at risk while you can still save it is worth more than any dashboard.

Learn from every call

Your best rep does something on calls your newest rep does not, and usually nobody can say exactly what. BuildByRavi CRM records and transcribes calls and turns them into coaching, so the patterns that win become teachable instead of locked in one person's head. A built-in AI co-pilot drafts replies and summarises calls, which means less time typing notes and more time selling. The CRM stops being a filing cabinet and starts being a coach.

Keep your data yours

A CRM holds your most valuable asset: every customer relationship you have. So control is not optional. BuildByRavi CRM has role-based access and audit trails, so the right people see the right data, departing employees cannot walk out with your whole pipeline, and you can always see who changed what. This matters more the moment you grow past a handful of trusted people.

The numbers we built it around

Every feature above exists to move a real metric. These are the targets BuildByRavi CRM is designed to hit, and the reason each module is in the product rather than the goals of any one customer, since your results depend on your team and your market:

Around 2.4x more replies from disciplined, tested sequences instead of one-and-done outreach.
Roughly 38% faster sales cycles when follow-up is automatic and the right leads get worked first.
Forecast accuracy within about 4%, so the number you tell your board is closer to the number that lands.
A free tier for up to 3 seats, so a small team can start without a budget conversation.
Setup in under an hour, because a CRM nobody finishes configuring is a CRM nobody uses.

Off-the-shelf or built for your workflow?

Salesforce and HubSpot are powerful, but they are heavy, priced in dollars, and they make you bend your process to fit their software. For a lot of Indian teams that means paying for ninety features to use nine, and fighting the tool every day. A CRM shaped around how your team actually sells wins on the only metric that matters for a CRM: whether people use it. We break down the real cost and trade-offs in custom CRM vs Salesforce and HubSpot, and for marketplace and multi-vendor businesses we package this as the MultiVendor CRM, a CRM built for businesses that sell through many sellers at once.

How we build it

Under the hood, BuildByRavi CRM is a multi-tenant web application on a Node.js backend, with the WhatsApp Business API for messaging, a clean internal API for the automations and integrations, and role-based security throughout. The same engineering we use for client SaaS builds goes into it, which is the point: when we build a custom CRM for your business, you get a real product, not a spreadsheet with a login screen.

Common questions about getting a CRM

Can you build a custom CRM for my business?

Yes. BuildByRavi CRM is our own product, but we also build CRMs shaped around how a specific business sells, with only the modules you need, your fields, your stages, and integrations like WhatsApp, payments, or your accounting tool. The fastest path is usually to start from what we have already built and customise, rather than from a blank page. Tell us how your team sells and we will scope it.

How long does it take to set up a CRM?

BuildByRavi CRM itself is designed to set up in under an hour for a standard sales workflow. A customised CRM built around your exact process takes longer, typically a few weeks depending on integrations, but you are never staring at a blank, generic system wondering where to start. We get you to a usable pipeline first, then refine.

Does it work with WhatsApp?

Yes, WhatsApp Business messaging is built in, because for most Indian sales teams that is where deals actually happen. Conversations are logged against the right lead so nothing lives only on a personal phone. See our WhatsApp CRM guide for how it works in practice.

Is it cheaper than Salesforce or HubSpot?

For most small and mid-sized Indian businesses, yes, both to run and to actually adopt. Global CRMs charge per seat per month in dollars and pile on features you will not use. A focused CRM, or a custom one built around your workflow, usually costs less over time and gets used more. We lay out the full comparison in custom CRM vs Salesforce and HubSpot.

Who owns the data?

You do. With role-based access and audit trails, you control who sees what, and with a custom build you can host it where you want. Your pipeline is your business, and it should never be hostage to a vendor or a single employee's phone.

Honest summary

A modern sales CRM in 2026 should do five things well: point you at the leads worth chasing, run the follow-up automatically, meet customers on WhatsApp, tell you honestly which deals are real, and turn your best calls into coaching for everyone else. That is what we built BuildByRavi CRM to do, and it is the same standard we hold a custom CRM to when we build one for a client. A CRM that just stores contacts is a spreadsheet with extra steps. A CRM that grows revenue earns its place.

Want a CRM built around how your team actually sells? Try the BuildByRavi CRM live demo to see it in action (log in with demo@buildbyravi.com and password Demo@2026), then message us on WhatsApp with how you sell today, or use the cost calculator for a rough estimate on a custom CRM build.

Tired of leads leaking out of spreadsheets? We build sales CRMs that surface the right leads, automate follow-up, plug into WhatsApp, and forecast honestly, shaped around how your team actually sells. See what we have built, then let us build yours. → Explore the MultiVendor CRM

REST API Design Best Practices 2026: How to Build APIs That Last

Ravi Rai — Sun, 28 Jun 2026 07:26:01 +0000

An API is a promise you make to everyone who builds on it. The moment your mobile app, your web frontend, or a partner integrates with it, that shape is hard to change and dangerous to break. Rename a field or change a status code and somewhere an app stops working, often silently, often in production. That is why API design deserves real thought up front, even though it feels invisible to anyone who is not a developer.

The reassuring part is that good API design is mostly conventions, not cleverness. Decades of people building HTTP APIs have settled on a set of patterns that just work, and following them makes your API predictable, easy to consume, and safe to evolve. This is the practical guide to designing REST APIs in 2026: the conventions that matter, and the mistakes that quietly cost teams later.

Resources and naming

REST is built around resources (things), addressed by URLs, acted on with HTTP methods. So URLs should be nouns, not verbs, and usually plural. Use /users and /users/123, not /getUser or /createUser, because the method already says the action. Nest to show relationships, like /users/123/orders, keep names lowercase with hyphens, and be relentlessly consistent: if it is /products in one place, it is never /product or /items elsewhere. Consistency is the single biggest thing that makes an API feel good to use.

Use HTTP the way it was meant

HTTP already gives you a vocabulary; use it instead of inventing your own. Methods carry meaning: GET reads (and never changes anything), POST creates, PUT and PATCH update, DELETE removes. Status codes carry meaning too, and getting them right is half of good API design:

200 OK for a successful read or update, 201 Created when you make something new, 204 No Content for a successful delete.
400 Bad Request for malformed input, 422 for validation errors, 401 Unauthorized when login is needed, 403 Forbidden when the user is logged in but not allowed.
404 Not Found for a missing resource, 409 Conflict for a clash like a duplicate.
500 for your own errors, and never use 200 with an error message in the body, because clients cannot tell success from failure.

Versioning: never break v1

The day you ship an API, assume someone will depend on it forever. Put a version in the path from the start (/v1/users) so you can evolve without breaking existing clients. The rule that saves you: add, do not change. Adding a new field or a new endpoint is safe; renaming a field, removing one, or changing a response shape is a breaking change that belongs in a new version. When you do need breaking changes, ship /v2 and keep /v1 alive long enough for clients to migrate.

Authentication and security

Every real API needs to know who is calling and what they are allowed to do. Use tokens (a JWT or OAuth access token) sent in the Authorization header, over HTTPS only, always. Beyond auth: validate and sanitise every input (never trust the client), apply rate limiting so one caller cannot hammer you, return only the data the caller is allowed to see, and never leak internal details in errors. The billing and payment APIs we build treat this as non-negotiable, because an API is the front door to your data.

Pagination, filtering, and sorting

Any endpoint that returns a list must paginate. Returning ten thousand records in one response is slow, expensive, and will fall over as your data grows. Offer pagination (offset-based is simplest; cursor-based scales better for large or changing datasets), plus filtering and sorting via query parameters, like /orders?status=paid&sort=-created_at&page=2. Decide on one consistent style and use it on every list endpoint.

Error handling that helps

Errors are part of your API, not an afterthought. Return a consistent error shape every time, with a machine-readable code and a human-readable message, so clients can handle failures programmatically. Make messages specific enough to be useful ('email is already registered' beats 'invalid input') without leaking internals like stack traces or SQL. A predictable error format is one of the kindest things you can do for the developers consuming your API, including your own future self.

Idempotency and reliability

Networks fail and clients retry, so design for it. GET, PUT, and DELETE are naturally idempotent (calling them twice has the same effect as once). POST is not, which is dangerous for actions like creating an order or taking a payment, where a retry could charge someone twice. The fix is idempotency keys: the client sends a unique key with the request, and your server returns the same result for a repeat of that key instead of doing the work again. We go deep on this for payments in the Razorpay webhooks guide.

Document it, or it does not exist

An undocumented API is unusable, no matter how well designed. Describe it with the OpenAPI (Swagger) standard, which gives you interactive docs developers can read and try, and which many tools can generate clients and tests from. Keep the docs next to the code so they stay current. If a developer cannot understand your API without messaging you, the design is not finished.

The mistakes that haunt teams later

Verbs in URLs. /createOrder instead of POST /orders. It works, but it fights every convention and tool.
Wrong status codes. Returning 200 for errors, or 500 for a user's bad input. Clients cannot react correctly.
Breaking changes with no version. Renaming or removing a field with no /v2 silently breaks every existing client.
No pagination. Fine with 50 records, a disaster at 50,000.
Leaky errors. Returning stack traces or database errors to the client is both confusing and a security risk.
No rate limiting or input validation. The two holes that turn an API into an attack surface.
Inconsistent naming. /products here, /item there, camelCase in one response and snake_case in another. Death by a thousand small surprises.

How we build APIs

We build REST APIs on Node.js and Laravel with these conventions baked in: noun-based versioned routes, correct HTTP semantics, token auth over HTTPS with rate limiting and input validation, consistent pagination and error shapes, idempotency on anything that touches money, and OpenAPI docs that stay in sync with the code. The same disciplined API sits under our multi-tenant SaaS builds and the MultiVendor CRM, because a clean API is what lets a web app, a mobile app, and partners all build on one backend without chaos.

Common questions about REST API design

Should API endpoints use nouns or verbs?

Nouns, almost always plural. Use POST /orders to create an order and GET /orders/123 to read one, not /createOrder or /getOrder. The HTTP method already expresses the action, so the URL should name the resource. This keeps the API predictable and works naturally with HTTP tools and caches.

How should I version my API?

Put the version in the URL path from day one, like /v1/users, and follow the add-do-not-change rule: new fields and endpoints are safe, but renaming or removing anything is a breaking change that needs a new version. Ship /v2 only when you must, and keep /v1 running until existing clients have migrated.

What is API idempotency and why does it matter?

An idempotent request has the same effect whether it runs once or many times. It matters because networks fail and clients retry, and a retried POST could create a duplicate order or a double charge. The solution is an idempotency key: the client sends a unique key, and the server returns the same result for repeats instead of redoing the work. It is essential for anything involving payments.

Do I need OpenAPI or Swagger?

You need documentation, and OpenAPI (Swagger) is the standard way to provide it. It gives consumers interactive, accurate docs and lets tools generate client libraries and tests. Even a small internal API benefits, because clear docs save endless back-and-forth. An API nobody can understand without asking you is not finished.

REST or GraphQL?

For most APIs, REST is the simpler, more widely understood choice and is what we default to. GraphQL shines when clients need to fetch many related things in flexible shapes and you want to avoid over-fetching, common in complex apps with many screens. Pick REST for straightforward resource access; consider GraphQL when query flexibility genuinely earns its extra complexity.

Honest summary

Good REST API design is mostly discipline, not genius: name resources as nouns, use HTTP methods and status codes correctly, version from day one and never break v1, secure it with token auth and validation, paginate lists, return consistent errors, make money-touching actions idempotent, and document it with OpenAPI. Get these right and your API is a pleasure to build on and safe to grow. Skip them and you inherit breaking changes, security holes, and confused integrators.

Building or fixing an API and want it done to last? Send us a WhatsApp message with what you are building, or the cost calculator gives a rough estimate for an API or backend build.

Building an API that a web app, mobile app, or partners will depend on? We design and build REST APIs in Noida and Gurgaon on Node.js and Laravel: clean resource design, versioning, token auth, idempotency, pagination, and OpenAPI docs. Built to last, not to rewrite. → Scope an API build

How to Choose the Right Tech Stack for Your Startup in India 2026 (A No-Hype Guide)

Ravi Rai — Fri, 26 Jun 2026 05:53:33 +0000

Every project starts with the same question: what should we build it on? And the moment you search it, the internet hands you a hundred confident, contradictory answers. Use Next.js. No, use WordPress. Real startups use React Native. Actually, Flutter. Everyone is right and everyone is wrong, because they are all answering a question you did not ask: what is best in the abstract, instead of what is best for you.

The right tech stack does not come from a trend or from whatever your last developer happened to know. It comes from your constraints: what you are building, your budget, your timeline, and crucially, who maintains it after launch. This is the no-hype guide for Indian founders in 2026: the questions that actually decide your stack, the sensible default for each kind of project, and the mistakes that quietly cost you later.

The wrong way to choose a stack

Three traps catch most people. The first is choosing by hype: picking whatever is loudest on Twitter or in a YouTube title, regardless of whether it fits a small business. The second is choosing by whoever you hired: a freelancer who only knows WordPress will tell you everything is a WordPress job, and a React enthusiast will build a single-page app for a brochure site. The third is choosing by 'what big companies use': Netflix's architecture is the worst possible template for your five-page site or your first MVP. None of these start from your actual situation, which is the only place a good answer can come from.

The five questions that actually decide it

What are you actually building? A marketing site, an online store, a web app or SaaS, and a mobile app are four different problems with four different right answers. Be precise about which one you have.
What is the budget? A custom build and a template on a builder are an order of magnitude apart. The honest stack depends on what you can spend now and later.
What is the timeline? Need to be live in two weeks, or building a serious product over months? Speed-to-launch favours different tools than long-term flexibility.
Who maintains it after launch? The most ignored question, and the most important. A stack your team (or a local developer) can actually maintain beats a clever one nobody can touch.
How complex and how big will it get? A simple site and a multi-tenant SaaS with real scale need very different foundations. Build for where you are heading, not three startups beyond it.

Answer those five honestly and the choice narrows itself. Most bad stack decisions come from skipping straight to the tool before answering these.

The right default for each kind of project

A marketing or content website

If it is mostly pages and a blog and a non-technical person updates it, WordPress is still a sensible default for the easy editing. If speed, security, and scale matter more, a modern Next.js build wins on performance and maintenance. We compared them directly in WordPress vs Next.js for Indian small businesses.

An online store

For most first stores, Shopify gets you selling fast with the least maintenance. WooCommerce fits if you live in WordPress already or need deep customisation, and a custom or headless build makes sense at scale. The trade-offs are in Shopify vs WooCommerce and WordPress vs Shopify.

A web app or SaaS

This is custom territory: a Next.js or React front end with a Laravel or Node.js backend is our default, chosen by the team that will maintain it. Start with the smallest version that proves people will pay, as in how to build a SaaS MVP.

A mobile app

Cross-platform is almost always the right call for a startup: one codebase for iOS and Android. The choice is Flutter vs React Native, which we build with on the mobile side, and the right pick depends on your team and whether you also have a web app.

You just need a site, fast and cheap

Be honest if you are at the validate-the-business stage. A website builder can be the smart short-term move, covered in website builder vs custom and AI website builders vs hiring a developer. Move to a custom build you own once revenue justifies it.

The mistakes that cost you later

Over-engineering. Building for a million users you do not have yet. The cost is real now; the scale is hypothetical.
Choosing a stack nobody local can maintain. An exotic framework feels clever until your developer leaves and nobody in your city can pick it up.
Picking by trend. The hot tool of this year is the legacy burden of the next. Choose proven, well-supported tools.
Ignoring who maintains it. If you do not know who updates and fixes it after launch, you have not finished choosing.
Lock-in you did not notice. Some platforms make it painful to leave. Know how you would move before you commit.

Our default stacks, and why

After enough builds you stop chasing novelty and settle on tools that are fast, hireable, and boring in the best way. Ours: Next.js and React for sites and web apps (great performance, huge talent pool), Shopify for most stores, Laravel or Node.js for backends, and Flutter or React Native for mobile. We pick from these based on your five answers above, not the other way around, and we will happily talk you out of a heavier stack than you need.

Common questions about choosing a tech stack

What is the best tech stack for a startup?

There is no single best stack, only the best fit for your project, budget, timeline, and maintenance situation. For a web app or SaaS, a Next.js or React front end with a Laravel or Node.js backend is a strong, hireable default. For a store, Shopify; for a content site, WordPress or Next.js; for mobile, Flutter or React Native. Decide by your constraints, not by what is trending.

Should I use what is popular or what my developer knows?

Lean toward what can be maintained, which usually means a proven, widely-known stack rather than the newest one or a niche one only your current developer understands. Popularity matters mainly because it means more developers can maintain and extend the project later. Avoid both blind trend-chasing and being locked to one person's favourite tool.

Is WordPress still a good choice in 2026?

Yes, for the right job. WordPress remains excellent for content-led sites where non-technical people update pages, as long as it is maintained. For high-performance sites, web apps, or anything that needs to scale, a modern framework like Next.js is usually the better foundation. It depends on the project, not on WordPress being good or bad.

Can I change my tech stack later?

You can, but it costs time and money, so the goal is to choose well enough that you do not have to soon. Migrations are normal as a business grows (a builder to a custom site, a monolith to something more scalable), and a good team plans the move with redirects and data migration. Choosing a maintainable, non-locked-in stack makes any future move far cheaper.

Do I need a different stack for mobile and web?

Often you can share a lot. A web app and a cross-platform mobile app can share a backend and API, and React Native shares language and tooling with a React or Next.js web app, which is one reason teams pick it. Flutter is a separate toolchain but excellent for polished apps. If web and mobile both matter, factor that into the choice from the start.

Honest summary

Choosing a tech stack is not about finding the objectively best technology, it is about matching the tool to your project, budget, timeline, and the people who will maintain it. Name what you are building, answer the five questions honestly, pick the sensible default for that category, and avoid the traps of hype, over-engineering, and stacks nobody local can maintain. Boring, proven, hireable tools win far more often than exciting ones.

Not sure which way to go for your project? Send us a WhatsApp message with what you are building and your constraints, and we will give you an honest recommendation, or the cost calculator gives a rough estimate once you know the shape of it.

Stuck on what to build your product on? We help Indian founders choose a tech stack that fits the project and the budget, not the trend, then build it: Next.js, Shopify, Laravel, Node.js, Flutter, and React Native. Honest advice first, in Noida and Gurgaon. → Get an honest stack recommendation