Choosing a QR Platform in India: GST Invoices, INR Billing and DPDP

Choosing a QR platform for a business rarely gets the procurement scrutiny a comparable software purchase would, mostly because the sticker price looks small enough to expense without much of a second look. That's a mistake specifically in an Indian business context, where currency, tax, and regulatory obligations all attach to even a modest recurring subscription in ways that matter more than the headline monthly number. What follows is eight things worth verifying before committing to any vendor, written as a checklist you'd hand to a colleague actually doing the evaluation, with MyQRx's own answers stated plainly alongside each one.

The eight-point checklist

Currency, payment rails, and the real cost of a foreign charge

A subscription billed in US dollars to an Indian card doesn't cost you exactly what the sticker says, because the actual charge depends on the card network's exchange rate that day, plus a foreign-transaction markup most Indian card issuers apply on top, typically adding a noticeable percentage to every international charge. Neither of these is disclosed clearly at the point of purchase, and both can shift the effective price meaningfully over a year of monthly renewals. A vendor billing natively in INR through a payment rail built for the Indian market removes both variables at once: the price quoted is the price charged, every time, with no currency conversion or cross-border transaction fee involved.

This is also where a working payment rail matters beyond convenience. An overseas-only payment processor can decline Indian cards outright, or handle recurring billing on them unreliably, which turns into an unpleasant surprise the month a renewal silently fails and a service you depend on stops working with no warning, sometimes taking down live customer-facing codes with it if a plan lapses mid-campaign. A payment rail purpose-built for the Indian market, handling recurring billing reliably on Indian cards and net banking, removes this specific failure mode, and it's worth actually testing a renewal cycle once early on rather than assuming it will simply work when the time comes.

Worth naming honestly here: not every vendor serving Indian customers has built out full INR billing yet, and a platform that still runs its billing exclusively through international card processing, even if it happily accepts Indian cards, is passing both the exchange-rate risk and the markup straight through to you every single month, whether or not that's obvious from the checkout page.

GST invoicing: the difference between an expense and a claimable one

Any subscription paid for business use should, in principle, be a GST input credit opportunity, not just an expense. In practice, that only works if the vendor issues a proper GST invoice carrying your business's GSTIN, structured the way your accounts team needs it for filing. A generic payment receipt, or a USD invoice from a vendor with no Indian GST registration, typically doesn't qualify, which means the tax component of that spend is simply lost rather than claimed back. For a subscription renewed monthly across a full year, that's not a trivial rounding error; it's tax paid and never recovered, purely because of how the vendor happens to invoice.

DPDP posture and where your customers' data actually goes

India's Digital Personal Data Protection framework creates real obligations around consent, data-subject rights, and how personal data is collected and handled, and a QR platform sits directly in that chain the moment it collects any scan-level data tied to a real customer. Verify, at minimum, whether a vendor's cookie consent defaults to declining non-essential collection rather than opting a visitor in by default, whether there's a working consent centre a visitor can actually use, and whether the published privacy position documents data-rights actions, letting someone request or correct their own data, that actually exist rather than being a line in a policy nobody has tested.

Where a vendor's data is physically stored and under which jurisdiction's law it sits is a fair and increasingly common question to ask directly, and it's worth pressing for a specific answer rather than accepting a vague one. This is a case worth naming plainly: not every vendor, including newer ones, has published a specific data-residency commitment yet, and a buyer with a hard requirement here should ask the question directly and get it in writing before committing, rather than assuming a favourable answer that hasn't actually been confirmed.

Grievance Officer and named legal entity: knowing who's actually accountable

A published Grievance Officer and a working grievance contact are, for many categories of online intermediary in India, a statutory requirement under the IT Rules, tied directly to the liability protection those rules extend to a compliant intermediary. This is worth stating plainly because it's commonly mistaken for a nice-to-have customer service gesture rather than what it actually is: a legal obligation, and a signal about whether a vendor understands and takes seriously the regulatory context it's operating in.

A named Indian legal entity matters for the same underlying reason. A vendor operating behind a product name alone, with no disclosed company name, registration, or jurisdiction, leaves a buyer with no clear answer to a question that matters the moment anything goes wrong: who, specifically, is accountable, and under which country's law can that accountability actually be pursued. It's worth confirming directly that the entity named in a vendor's terms actually matches the one issuing your invoices, rather than assuming two different names appearing in two different places refer to the same accountable party. A vendor's full disclosure posture, the named entity, the domain, and the Grievance Officer together, is worth checking as a single set rather than accepting one piece of it and assuming the rest follows.

Realistic per-code cost, not the headline monthly number

A plan advertised at an attractive low monthly price can still be the more expensive option once your actual code volume is accounted for, if that price only covers a small code allowance and the next tier up jumps sharply. Work out your genuinely expected code count, not an optimistic minimum, and price each vendor's tier against that number specifically, rather than comparing headline prices for tiers that don't actually match your real usage. Also check whether a plan's quota covers static and dynamic codes together or separately, since a vendor splitting them into two separate allowances can make an otherwise comparable plan considerably tighter in practice than its headline code count suggests.

The category gap is worth knowing in general terms: global QR platforms commonly price a comparable mid-tier plan somewhere in the $37-$100 a month range, while an India-priced alternative in the same category can land closer to a few hundred rupees a month, a gap worth roughly a sixth to a tenth depending on the specific comparison. Treat this as a category-level pattern rather than a claim about any one named competitor's current price, since prices change and a stale specific figure is a liability the moment it's quoted back to you. What the gap is actually built from matters more than the number itself: an India-priced vendor billing natively in INR has no currency-conversion margin to absorb into its pricing, no international payment-processing fee stacked on every transaction, and often a leaner cost base built around the Indian market specifically rather than a global one adapted for it after the fact.

The exit path: knowing how to leave before you need to

Ask any vendor, before signing anything, what actually happens to your live codes if you stop paying or decide to leave. A dynamic code's behaviour on cancellation, whether it stops resolving, downgrades to a landing page, or keeps working on a reduced free tier, should be a documented answer, not something you discover by testing it after the fact. The cleanest exit path of all belongs to a static code: because a static code carries no server-side dependency on any vendor at all, it keeps working identically regardless of what happens to your account, your subscription, or the vendor itself. For anything printed at volume where continuity matters more than editability, that's worth factoring into the format decision itself, not just the vendor decision.

What this means for your next campaign

Run this checklist before signing with any vendor, not just MyQRx, since every one of these eight points applies regardless of which platform you're evaluating. Confirm INR billing and a working Indian payment rail first, since currency and payment friction are the most common source of unpleasant billing surprises. Then verify the GST invoice, the Grievance Officer, and the named legal entity together as a single disclosure question, and price any shortlist against your actual expected code volume rather than a headline number. MyQRx's own pricing is built around these eight answers directly; where the answer is still a gap, no international card billing, that's stated here rather than left for you to discover after signing up.

See MyQRx pricing in rupees