Find revenue at risk
A signed Razorpay Test Mode failure becomes one durable, idempotent recovery case instead of disappearing into a payment log.
About RecoveryOS
Razorpay detects failure.
RecoveryOS decides what follows.
An explainable, policy-controlled system that turns failed payments into recoverable cases, schedules the right next action, and tracks the outcome without giving AI direct control over money or messages.
The simple version
A decision layer for revenue that would otherwise be lost.
Razorpay already tells a merchant that a payment failed. RecoveryOS answers the harder next question: should the system wait, offer another path, create a recovery link, contact the customer, escalate the issue, or stop?
Every recommendation is explained, every action is checked by deterministic policy, and every result is stored so the merchant can see what recovered and why.
Razorpay challenge fit
Payment degradation → root cause → recovery action.
RecoveryOS deliberately completes one revenue-recovery direction end to end: detect the loss, determine the intervention, execute within policy, and prove the outcome with measured money and an audit trail.
Choose the right response
Deterministic diagnosis explains the failure, then GPT-5.6 Terra proposes one structured intervention from read-only facts.
Keep execution controlled
Policy can approve, delay, replace, escalate, or deny the proposal before the worker reaches any Razorpay tool.
Show incremental recovery
A reproducible 250–500-payment run compares RecoveryOS with no intervention and a naive retry using the same outcomes.
Avoid false intervention
Attempt limits, cooldowns, merchant-error rules, duplicate protection, and payment-state checks decide when to escalate or stop.
Make every action auditable
The case timeline retains detection, evidence, proposal, policy decision, execution, verification, and the final outcome.
Checkout abandonment, subscription recovery, B2B receivables, mandate sequencing, voice recovery, and promise-to-pay tracking remain out of scope. The failed-payment loop is the complete first version.
Frozen batch evidence
Same payments. Measured uplift.
This fixed Test Mode-labelled simulation compares all three strategies against identical generated payments and outcome rolls.
₹28,75,582
500 synthetic failed payments.
₹5,50,591
Named immediate-retry baseline.
₹13,34,223
45.2% recovered.
+₹7,83,632
164 policy stops · 63 escalations · 8 unnecessary interventions prevented.
SIMULATED DATASeed 20260821Configuration 925ba5d21500 stored outcomesAll amounts are simulated; no real money moved.
How it works
One accountable recovery loop.
The model advises. Deterministic code decides what is allowed. The execution layer alone can create a side effect.
- 01Detect
Razorpay Test Mode sends a payment failure, or the demo simulator creates a clearly labelled synthetic case.
- 02Diagnose
A deterministic engine reads the failure source, reason, payment method, and attempt history.
- 03Decide
GPT-5.6 Terra proposes one bounded recovery strategy using only the case facts it is given.
- 04Guard
Deterministic policy checks consent, cooldowns, limits, duplicates, and whether the payment already succeeded.
- 05Execute
BullMQ schedules an approved action. Only the execution layer can call Razorpay or update durable state.
- 06Observe
Recovery is verified, written to the audit timeline, and reflected in the dashboard and simulator comparison.
System architecture
From payment failure to verified outcome.
PostgreSQL keeps the business truth. Redis and BullMQ keep work moving. The worker connects diagnosis, AI, policy, provider tools, and verification.
Dashboard, Reported Issues, case detail, and Test Mode checkout.
Orders, signed events, payment state, and silent Payment Links.
Validates requests, persists webhook events, serves product data, and enqueues background work.
Cases, actions, policies, jobs, outcomes, and audit history.
Delayed jobs, retries, stable IDs, and the repeatable scheduler.
Background runtimeRecovery worker
Reconciliation every 60 seconds- 01Payment event
- 02Failure analysis
- 03Recovery action
- 04Outcome verification
- 05Reconciliation
Classifies failure cause and provides a safe fallback.
Proposes one structured action. It has no execution tools.
Checks safety, consent, limits, cooldowns, and duplicates.
The worker re-checks payment state, executes a bounded action, verifies the result, and sends the updated truth back to the product.
No external cron service or dedicated VM is required.A BullMQ repeatable scheduler runs reconciliation every 60 seconds while the worker is online, recovering stale webhooks, overdue actions, and cases waiting for analysis.
What is integrated
Real components, narrow responsibilities.
Test Mode and simulated records are visibly labelled so a demo outcome can never be mistaken for real merchant revenue.
Razorpay Test Mode
Test checkout, signed webhook ingestion, payment status checks, and silent Test Mode Payment Links.
OpenAI · GPT-5.6 Terra
Structured Responses API proposals with strict Zod validation, time and token limits, and a deterministic fallback.
PostgreSQL · Prisma
Durable cases, payments, actions, policies, job records, simulator outcomes, and complete audit events.
Redis · BullMQ
Persistent delayed work, bounded retries, stable job IDs, verification, and scheduled reconciliation.
Fastify · TypeScript
Validated product APIs, webhook endpoints, analytics, simulator runs, secure headers, and rate limits.
Next.js · React
Executive recovery metrics, Reported Issues, case reasoning, Test Mode checkout, and visible data-source labels.
Judge-ready proof
From healthy infrastructure to judge-ready proof.
Each gate is verified. Live Razorpay Test Mode evidence stays separate from the labelled simulated batch comparison.
- 01 · VerifiedHosted foundation
The Vercel merchant experience is connected to healthy Railway API and worker runtimes backed by Aiven PostgreSQL and Redis Cloud.
- 02 · VerifiedWebhook proof
A signed payment.failed event creates exactly one visible Test Mode case. Replaying the same provider event does not duplicate the case, action, or job.
- 03 · VerifiedLive recovery loop
The case timeline shows a GPT-5.6 Terra proposal, an independent policy decision, a silent action-bound Payment Link, and a verified paid Test Mode outcome.
- 04 · VerifiedMeasured evidence
A frozen 250–500-payment run compares RecoveryOS with no intervention and naive retry, reconciling incremental rupees, policy stops, escalations, and false interventions.
- 05 · VerifiedSubmission hardening
The reset flow, audit trail, graceful Razorpay 5xx retry, architecture explanation, and judge walkthrough are packaged as a repeatable demo.
The important boundary
AI can propose. It cannot move money.
RecoveryOS gives GPT-5.6 Terra read-only case context. It cannot write to PostgreSQL, call Razorpay, or message a customer. Those capabilities stay behind deterministic policy and auditable tools.