Razorpay Subscription Revenue Attribution: A Guide for Indian SaaS Founders

Razorpay subscriptions in India often go through UPI, NetBanking, or card mandates. Each method has slightly different webhook behaviour and dunning patterns. Failed-payment recovery is more common than in card-only markets, which means recurring revenue reporting needs to handle multiple attempts gracefully.

On top of that, the buying journey is often longer. A SaaS prospect may research on desktop, share with a co-founder on WhatsApp, and pay weeks later from a phone. Without first-party identity stitching, only the last touch is visible — usually direct traffic or brand search.

Razorpay's orders, subscriptions, and payments all accept a notes field — a flat string-to-string dictionary that is preserved across the lifecycle of the object. The notes field is what you use to carry attribution metadata.

At the moment you create a Razorpay order or subscription on your server, attach the visitor ID, session ID, and (optionally) the originating page URL into notes. Razorpay echoes these back in every webhook event for the lifecycle of the object, including renewals.

Do not put personal data into notes. Keep it to opaque visitor IDs and short tokens. Hashed emails are fine when matching across devices.

Set a first-party visitor ID on first page load and store it in localStorage on your own domain. Capture landing URL, referrer header, UTM parameters, user agent, and any AI-search signals. Send the session to your own ingestion endpoint.

Metrivo's tracking script handles all of this in a single line and ships with privacy-friendly defaults: hashed IPs, no session replay, no heatmaps, no keystroke tracking. The same pattern can be built manually if you prefer.

When the buyer clicks 'Subscribe' or 'Pay', your server calls Razorpay's API to create an order (for one-time) or subscription (for recurring). Attach the visitor ID and session ID into the notes field at creation. Use a stable key name like rp_visitor_id so your webhook handler always reads from the same field.

For Razorpay Subscriptions, the notes attached at subscription creation propagate to every renewal payment. That means recurring revenue stays attributed without re-instrumentation as long as the initial setup is correct.

Razorpay signs every webhook with HMAC SHA-256 using a shared secret. Verify the signature before reading the body. The events that matter most for attribution are payment.captured, payment.failed, subscription.activated, subscription.charged, subscription.cancelled, and subscription.completed.

On each event, write a payment row, read the notes, and trigger the attribution matcher. Use the event ID as an idempotency key — Razorpay retries on timeouts, and idempotency is the only protection against duplicate revenue rows.

The matching layer is identical to other providers. High confidence: the notes carry a visitor ID that exists in the session store. Medium confidence: notes are missing but a hashed email matches. Low confidence: only a UTM or referrer hint is present. Unknown: no usable join exists.

Indian SaaS funnels often produce a higher proportion of medium-confidence matches than US/EU funnels because cross-device journeys are more common. A clean report still surfaces this honestly rather than promoting low-confidence matches to high-confidence ones to look more decisive.

Razorpay subscription lifecycle events are noisy: charges, failed attempts, mandate updates, and reactivations all fire. The attribution ledger should record the evidence at each step rather than collapsing the history into a single final answer.

Metrivo's ledger is append-only. Each new piece of evidence appends a new row with a timestamp. When attribution shifts (say, an email hash match arrives a week after a 'direct' payment), the change is visible — not silently overwritten.

Razorpay's mandate-based subscription system retries failed payments according to your configuration. Each retry fires a webhook. Without idempotency and de-duplication, the recovered payment can be counted twice — once on the initial attempt and once on the recovery.

The right pattern is to write payment rows keyed by Razorpay payment ID, then derive revenue totals from the latest state per subscription period. Attribution stays attached to the subscription, not the individual retry.

If you operate a multi-tenant system — or if Metrivo writes payments on behalf of multiple workspaces — webhook handlers need strict workspace isolation. Metrivo's Manual Payment API resolves the workspace from the API key on the server, never from the client payload. Any spoofed workspace_id in the body is ignored. The same principle applies to Razorpay webhooks: workspace is derived from configured integration credentials, not from the request body.

This matters in real production systems. A bad tenant isolation bug can silently leak revenue rows into the wrong workspace. The fix is to make the workspace assignment derive from a verified credential, then add tests that prove the rule cannot be bypassed.

Setting notes on payments but not on the parent subscription — renewals will lose attribution.

Trusting client-supplied attribution in webhook handlers — always derive workspace and tenant scope from server-side keys.

Ignoring mandate states — a subscription with a paused mandate looks like a churn event even though revenue may resume.

Counting revenue on payment.created rather than payment.captured — leads to inflated metrics that drop when captures fail.

Storing PII in notes — keep it to opaque IDs and hashes.

Pull the attributed-revenue view filtered to Razorpay. Sort by confidence-weighted revenue across source, landing page, and plan.

Inspect the biggest leak. Common patterns: comparison content sends qualified visitors to checkout but mandate setup drops on one plan; AI-search traffic reaches pricing but skips checkout for a specific tier.

Generate a fix draft, assign an owner, and ship one test. Two to four weeks later, measure paid conversion for the targeted segment.

Record the result in Revenue Memory so the next iteration accounts for it. Patterns specific to UPI vs card mandates show up over time and can drive plan-level packaging decisions.

If your Razorpay revenue is mostly labelled direct or unknown, the data is telling you the notes field is not being attached at order or subscription creation. That is fixable in a single afternoon.

Metrivo's $99 Guided Revenue Leak Audit handles exactly this scope: one website, one payment path, one report. For Razorpay specifically, the audit checks notes-field flow, webhook signature verification, idempotency, and the matcher's confidence breakdown. If the data is missing, you get a missing-data report and a fix path instead of an inflated revenue claim.