Razorpay AI Buildathon · Track 03
Recover watches your Razorpay payment stream for the ones that didn't go through — a card that expired, a balance that was short, a mandate that lapsed, an invoice past due — works out why, and runs one careful, policy-bounded attempt to get it back. Every step is written down.
Demo instance with synthetic merchant data. Reviewer sign-in details are in the For reviewers section.
The gap
When a payment fails, the customer usually meant to pay. But chasing every drop-off by hand doesn't scale, generic “your payment failed” blasts get ignored, and finance teams write off the long tail. The money is recoverable — it just needs a fast, correct, bounded follow-up.
How it works
Every case moves through the same six stages. A person only steps in when the engine is unsure or the amount is large — otherwise it runs on its own, and stops the moment a policy limit is reached.
A payment.failed webhook, an abandoned checkout, or an overdue invoice opens a case.
A rules table maps the Razorpay code to a cause. Unclear ones go to review, never a guess.
The policy for that cause picks one action and mints a real Razorpay Payment Link.
A template fills in the real name, amount and link — no invented facts.
The message goes out over email via Brevo, with the delivery reference recorded.
When the customer pays, the amount and time-to-recovery are logged on the case.
A case, start to finish
One real case from the demo instance: a checkout that dropped off at payment. The engine matched the decline code to INSUFFICIENT_FUNDS at 95% confidence, scheduled a retry link, wrote the email from a template, and sent it through Brevo — then a reviewer confirmed the customer had paid.
Nothing in that chain is a black box. Each line carries a reason code, an actor, and a before/after snapshot, and the whole thing exports to CSV. When a step fails — a Payment Link that didn't mint, a bounced send — that's in the trail too, next to the retry that recovered it.
What it handles
The same detect–diagnose–decide loop covers all three. Each scenario adds its own cause codes, policies, and message templates — not a separate system.
A card declined, funds were short, an OTP was abandoned, the gateway timed out. Recover sends a reassuring retry link inside the allowed hours.
The auto-pay mandate lapsed, expired, or hit a low balance. Recover explains that the authorization itself needs re-doing and links straight to it.
A three-tier ladder — a friendly nudge, then a firm reminder, then escalate to a human. Large balances always reach a person first.
Where it stops
Recovery is only useful if merchants trust it near their customers and their money. Every limit below is configuration, editable per cause code on the Policies screen, and applied on the next run.
If the diagnosis scores below the policy threshold, the case is held for review — never sent on a guess.
Anything over the review threshold waits for an approval before any outreach leaves the system.
A per-cause cooldown stops Recover contacting the same customer twice in quick succession.
Outreach is pinned to an IST send window per cause code. Nothing goes out at 3am.
Once the maximum attempts for a cause are spent, the agent stops and the case is closed or escalated.
Every transition — the agent's own, and every failed step and retry — writes a reason and an actor to the audit trail.
For reviewers & judges
A buildathon build on a demo instance — the merchants, customers and failed payments are synthetic. Sign in with any account below (all use the password recover123) and the console opens on the recovery summary.
The console opens on the recovery summary — recovered amount, recovery rate, average time to recovery, and a live feed as the engine works through cases.