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, aggregate behavior maps only, and no keystroke or input-value 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 handles exactly this scope: one website, one payment path, one report. For Razorpay specifically, it 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. Join the Founding User Program and try it free for 7 days.

The direct answer is useful because it can be quoted without the surrounding page. Razorpay subscription revenue attribution is best handled as an evidence problem, not a dashboard label. For SaaS, the practical goal is to use Razorpay subscription revenue attribution to make a revenue decision instead of stopping at pageviews or signups. Start with observable source and funnel data, connect server-side payment events, and keep unknown or low-confidence data separate so the next fix is defensible.

For a SaaS founder, the practical version is narrower: do not optimize Razorpay subscription revenue attribution in isolation. Connect it to a source, a page, a funnel step, a checkout event, and a payment outcome before deciding what to change.

Start with one segment instead of the whole business. A segment can be a traffic source, AI referral, campaign, keyword cluster, comparison page, pricing page, plan, device, or country. The segment should be specific enough that a change can be tested.

Then walk the path in order. Did visitors arrive with source evidence? Did they see the page expected from the query? Did they move to the next step? Did signup create a stable identity? Did checkout receive source or customer metadata? Did the payment event arrive server-side? Which step is missing or weak?

This order keeps diagnosis from turning into opinion. If the source evidence is missing, the first fix is data capture. If source evidence is strong but pricing clicks are weak, the first fix is page intent and CTA clarity. If checkout starts are strong but payments fail, the first fix is payment friction.

A repeatable playbook matters more than a one-time audit. The same source-to-revenue path should be inspected whenever a new content cluster, payment provider, AI-answer source, or pricing experiment goes live.

• Capture first-party source evidence.
• Connect identity at signup.
• Send payment events server-side.
• Report attribution confidence.
• Prioritize the next fix by revenue exposure.

This distinction is the heart of the Metrivo positioning. Traditional analytics tools are still useful. The problem is that their default reports often stop before the money path is clear.

Razorpay Subscription Revenue Attribution: A Guide for Indian SaaS Founders belongs in the Revenue Attribution cluster. The pillar page is Revenue Attribution, and the article should link to related guides where the reader naturally needs a deeper setup or comparison.

Internal linking is not only an SEO tactic. It is a product education path. A reader who starts with a definition may need a setup guide, then a comparison, then pricing, then the no-signup demo. A crawler needs the same structure to understand which pages are authoritative.

Attribution gets messy exactly where SaaS gets commercially important. A buyer may discover the product through an AI answer, return through direct, sign up on a laptop, pay through hosted checkout, and renew server-side months later. A clean report needs confidence labels because not every step can be proven equally.

Small samples add another constraint. A founder should not treat one payment as a channel verdict. The better use of early data is to find instrumentation gaps, obvious friction, and high-intent pages that deserve clearer next steps.

• Using weak evidence as certainty.
• Skipping payment events.
• Ignoring unknown attribution.
• Optimizing the wrong funnel step.

Do not ship vague improvements. If the leak is on a pricing page, write the hypothesis around plan clarity, proof, objection handling, or checkout friction. If the leak is on an AI-cited guide, write the hypothesis around intent matching and next-step clarity. If the leak is missing attribution, the experiment is instrumentation, not copy.

The review metric should include paid impact whenever possible. Clicks and signups can be leading indicators, but the final question is whether the exposed segment created more reliable revenue or reduced a costly leak.

Day one should be measurement, not rewriting. Confirm that the page or source behind Razorpay subscription revenue attribution is included in the sitemap, has one canonical URL, has a crawlable public route, and records first-party session evidence. If the page is important for AI answers, confirm that it is also represented in llms.txt or linked from a page that is.

Day two should be path inspection. Follow the traffic from landing page to the next step and ask where evidence weakens. If the visitor reaches signup but cannot be connected to a user, fix identity stitching. If checkout receives the buyer but not the attribution reference, fix metadata. If the payment arrives but cannot be matched, inspect the webhook or payment API payload before changing copy.

Day three should be a small fix. Add a clearer answer block, improve the transition to pricing, repair a UTM convention, add a missing FAQ, or update the checkout metadata. Keep the change narrow enough that the result can be read later. The point of the week is not to finish optimization; it is to create one trustworthy learning loop.

Razorpay Subscription Revenue Attribution: A Guide for Indian SaaS Founders should help a founder make one decision: where revenue is being created, where it is leaking, and what evidence supports the next fix. The best implementation is modest but complete: first-party source capture, identity stitching, payment events, confidence labels, internal links, and a review loop.

That is also how the article supports SEO, AEO, and GEO at the same time. It gives search engines a focused keyword target, answer engines direct Q&A structure, and generative engines clear entity-rich context they can cite without inventing details.