How I built REVA for Track 3 of the Razorpay AI Buildathon 2026—and why deterministic guardrails matter more than AI autonomy when money is involved. The Problem I Wanted to Solve Building for Track 3 of the Razorpay AI Buildathon 2026 as a solo developer came with one obvious challenge: There were a lot of talented engineers building impressive things. I didn't want to build another chatbot with an LLM sitting on top of an API. I wanted to build something where AI had to make real decisions, while still operating within the constraints of a financial system. That led me to a problem I found particularly interesting: What should happen after a payment fails? A failed payment doesn't always mean lost revenue. Sometimes it's a temporary bank issue. Sometimes the card is expired. Sometimes the customer needs another payment method. And sometimes the payment may have actually succeeded even though the original request didn't return a definitive response. The difficult part isn't simply retrying. The difficult part is deciding when to retry, when not to retry, and when to involve a human—without accidentally charging the customer twice. That's what led me to build REVA — Razorpay Revenue Recovery Agent. 1. The Problem: A Failed Payment Isn't Always Lost Revenue Payment failures can leave merchants with potentially recoverable revenue. The obvious solution seems simple: Retry the payment. But blindly retrying every failed transaction creates another set of problems. A recovery system needs to understand why the payment failed before deciding what to do next. For example: A temporary bank failure might justify a retry after a delay. An expired card should not be retried. A high-value order might deserve human intervention. A payment with uncertain settlement status should not be blindly retried. Most basic recovery systems approach this in one of two ways. Blind Retries Retry failed payments according to a fixed schedule. The system doesn't really understand the failure. It simply assumes that trying again is better than doing nothing. That can lead to unnecessary retries and, more importantly, duplicate-charge risks when payment state is uncertain. Static Rules Build a large collection of if/else conditions. This is more predictable, but eventually becomes difficult to maintain and doesn't handle contextual decisions particularly well. I wanted something in between. An agent that could reason about the situation, while a deterministic system made sure that the reasoning could never violate critical financial policies. 2. The Realization: AI Shouldn't Touch Money Directly My initial idea was straightforward: Payment fails | v Send error to LLM | v LLM decides what to do | v LLM retries payment