Recoup
Razorpay AI Buildathon · Track 03 · Revenue recovery

Failed payments are not a support ticket. They are a queue of decisions.

Recoup watches failed one-time payments and failing subscriptions, works out why each one failed, then executes a bounded recovery playbook per case — retry, card-update nudge, fresh payment link, or deliberately nothing. It reports the rupees it actually brought back, and the ones it decided to leave alone.

Two lanes
one-time + subscription

Subscription cases never propose a retry — Razorpay already retries 4× then halts.

Hard stops
fraud · revoked mandate · opt-out

Not overridable by the model or by a human. The refusal is audited.

Degraded ≠ silent
confidence capped at 0.6

If the model is unreachable, the case falls below the act threshold and routes to a human.

How it stays trustworthy

Rules first, model second

Unambiguous Razorpay error codes resolve from a deterministic table. The LLM is only invoked when the code is missing, vendor-mangled, or contradicts the payload — and its confidence is written to the case.

Bounded by a policy gate

Quiet hours, value floors, attempt caps, contact-frequency limits, daily send caps and a kill switch. The executor runs strictly after an allow verdict and never re-decides.

Append-only audit trail

Every stage writes one row — actor, verdict, latency, tokens, raw payload. There is no update or delete procedure in the API. Human overrides are appended next to the machine decision.

Measured, not claimed

Batch runs score the classifier against ground truth and surface false positives, false negatives, degraded cases and the full exception list beside the money recovered.