Inside Razorpay’s Engineering Behind Billions of Successful Transactions

Ninety seconds before the first ball of the 2024 IPL season opener, Razorpay's payment success rate began to decline. It went from 98.5% to 95%, then to 92%.

Across India, millions of users were simultaneously ordering food on Swiggy, buying snacks on Blinkit, and locking fantasy teams. All of these transactions were flowing through Razorpay's infrastructure. The window to respond was vanishingly small.

This was the situation the Razorpay engineering team reconstructed on stage at FTX26, the company’s annual flagship event. Anand Lakshmanan, VP of Product at Razorpay, used it as the starting frame. Not because the system failed spectacularly, but because at this scale, the margin between normal operation and crisis is almost invisible.

“In those ninety seconds that you’re trying to raise an on-call request, get an engineer on Slack to respond to that, you've already lost hundreds of crores of money. Tens of thousands of transactions are already failing,” Lakshmanan says.

Users see a checkout screen, a UPI prompt, and a confirmation. What Razorpay’s engineers see is different. “Payments as an architecture is a ten-layer cake,” he adds. Ten components must act in unison, within milliseconds, for a payment to succeed.

How Razorpay Satisfies 100% Accountability

The complexity begins even before the user touches the payment interface. In the 800 milliseconds it takes to render a checkout page, the system has already made 27 decisions, determining payment method preferences, instrument ordering, and applicable offers. 

Once the user initiates payment, control is transferred out of Razorpay. The transaction is routed to an acquiring bank, passed through a card network such as Visa, Mastercard, or RuPay (or NPCI for UPI), and forwarded to the issuing bank for authorisation. Each handoff requires exactly-once processing. After authorisation, reconciliation follows across dozens of banks with different settlement schedules.

Razorpay controls roughly 30% of the systems involved in a transaction. The remaining 70%, the banks, networks, and issuers, are external. But the company is accountable for 100% of outcomes. “We cannot go tell Swiggy tomorrow, ‘Hey, that's not our problem. There was a gateway that failed, and your customer could not place the order.’ That's not an acceptable scenario,” Lakshmanan explains.

During IPL matches, traffic does not arrive as a single spike. It comes in waves over several hours. Fantasy gaming peaks before the toss, food delivery rises as viewers settle in, and quick commerce surges as snack orders pile up. Razorpay responds with multi-layer traffic shaping, where each layer evaluates system health in real time. 

When services degrade, non-critical workloads are shed. Payment traffic is never deprioritised. Thousands of metrics feed automated monitoring. In one instance, rising latency was traced to database replication lag, triggering an automated failover within 30 to 40 seconds without human intervention.

Reliability also means removing fragile dependencies from the payment path. In a live demo, engineers scaled the merchant service to zero on production. 

This service provides configuration data like fee structures and transaction limits. In earlier versions of the system, losing it would have caused order failures. But a refresh-ahead caching system, which updates data in the background before cache entries expire, kept the system running. Errors for the merchant service spiked immediately, but order failures remained at zero.

The Routing Problem

The next layer of complexity is routing. Razorpay integrates with hundreds of gateways and must select one for each transaction in under 100 milliseconds, evaluating over 150 attributes, including merchant configuration, real-time gateway health, and issuer behaviour.

The routing pipeline operates in stages. A context builder enriches the transaction with data. A downtime detection layer monitors gateway health. If a gateway's success rate falls below 40%, it is automatically removed from the pool. A rule engine applies merchant preferences while overriding unsafe choices. A scoring system then selects the most reliable path.

Previously, after filtering, the final selection could be arbitrary.

“From the rest, we were picking them by a roll of the dice. Sometimes it would work, sometimes it would not,” Lakshmanan says.

Enter Doppler

The replacement is Doppler, a machine learning system trained on Razorpay’s full transaction history. Lakshmanan compared the shift to going from rolling dice to playing like a chess grandmaster, recognising the winning move from patterns rather than calculating everything in real time. 

Every payment feeds into a feature engineering pipeline, generating over 300 signals. The most important are interaction features, where variables are combined rather than evaluated independently. 

The success rate of a specific issuer can vary by gateway or time of day. An HDFC credit card might show higher success through one gateway for high-value electronics on Flipkart, but a different pattern for grocery transactions. These combinations surface insights no human could write rules for.

The models are gradient-boosted trees, retrained weekly, with inference under 100 milliseconds. If Doppler encounters errors, it falls back to rule-based routing. Optimisation never compromises reliability. Decisions are made transparent using SHAP values, which break down how each factor contributes to a gateway's score, making every prediction auditable.

In a live demo, engineers degraded a production gateway. Doppler detected the declining success rate and redirected traffic to healthier alternatives within seconds. 

Volume through the degraded gateway dropped sharply, but overall success rate held steady. The team estimates that Doppler delivers a four to five percentage-point uplift over rule-based routing. At Razorpay’s volume, this could translate to hundreds of crores in recovered transaction value daily.

Lakshmanan returned to the IPL night that opened the session. “We recovered in no time, in a matter of a few seconds, and no transactions were lost,” he says.

How Stripe Tackles Similar Challenges

Razorpay’s approach focuses on choosing the right gateway before a transaction is sent. Stripe has tackled a related but distinct problem: what happens after a transaction is sent and the issuing bank says no.

The company’s Adaptive Acceptance system uses AI to identify legitimate transactions mistakenly declined by issuers, and retries them in real time before the customer ever sees a failure. The retry is not generic. The system modifies how the transaction is presented to the issuer, adjusting formatting, field structure, and in some cases, routing based on learned behaviour of individual banks and networks.

The underlying premise is that many declines are not caused by insufficient funds or fraud, but by how issuer systems interpret transactions. False declines cost US online retailers an estimated $81 billion in 2023, often exceeding losses from actual fraud.

“These patterns involve the intricate interplay of factors such as bank policies, routing, messaging, formatting, and issuer preferences,” Stripe said in a blog post detailing the system.

To better capture these interactions, Stripe recently moved from a gradient-boosted tree model (XGBoost) to a deep neural network it calls TabTransformer+. This architecture uses high-dimensional embeddings to encode subtle behavioural patterns across issuers and transaction types, enabling the model to evaluate hundreds of factors and their interactions simultaneously.

The result was a 70% greater precision in identifying false declines, while reducing retry attempts by 35%. In 2024, Adaptive Acceptance recovered $6 billion in falsely declined transactions, a 60% year-over-year increase in retry success rate.

Stripe also overhauled its training pipeline, reducing model training time from days to hours. This allows new model versions to be deployed multiple times per week, keeping the system current as issuer approval patterns shift.

“We can now train and deploy new versions of our Adaptive Acceptance model multiple times per week,” the company said.

Unlike routing systems that optimise the path before a transaction is sent, Adaptive Acceptance operates at the boundary between the payment processor and the issuer. It treats the issuer’s response not as final, but as a signal that can be acted on, recovering transactions that would otherwise be lost.