Vulcan: How Razorpay built a foundation model for payment decisions

Anyone who has bought something online has been through this journey.

To a shopper, a payment is one action: choose a method and click Pay. Behind that action, we have to get many decisions right, from the moment checkout renders to long after the parcel ships. Four of the most consequential:

• Routing is real time: the decision to send a payment down the right path must be made with low latency, while the shopper waits.
• Fraud is distributed: the decision to block a payment must be made from evidence spread across merchants who cannot see each other, with confirmation arriving weeks later.
• Delivery risk is anticipatory: the decision to offer cash on delivery must be made at checkout, before the payment or the delivery outcome exists.
• Checkout ordering is silent: the decision to show one method first must be made as the page renders, with feedback that never says why a shopper left.

For years, each decision had its own machine learning model and its own view of a payment. That approach worked, but the learning stayed inside each model. Vulcan is Razorpay’s payments foundation model. Its reusable core—called the backbone—learns patterns common to payments; task-specific context and decision layers use that learning to answer particular questions. This article explains why we built Vulcan this way, how the four decisions differ, and what a shared foundation gives us that separate models could not.

Table of Contents

Toggle

One purchase, four decisions

These decisions belong to the same purchase journey, but none of them can be made well from one payment in isolation. Each becomes reliable only with signals learned across many payments — which methods a customer tends to prefer, how a route has been behaving, how often parcels from a delivery area come back. They also happen at different points and receive useful feedback at different speeds. Routing must finish while the shopper waits. Fraud may take weeks to confirm. For a cash-on-delivery order, the decision is made around checkout, before the payment and delivery outcomes are known.

Because all four problems sit on the same journey, they draw on many of the same underlying signals — how a payment method behaves, how an issuer responds at this hour, what a merchant’s traffic normally looks like. This is why one deep understanding of payments can serve them all, and it is what Vulcan’s foundation aims to provide. The nuance sits on top: each decision still needs its own data, its own label and its own way of measuring success, so each gets its own head — a small task-specific layer — trained on the shared base.

Vulcan’s backbone

Vulcan’s public launch covers routing, fraud detection, cash-on-delivery risk and checkout personalisation. These applications draw on a shared understanding of payments, but they are not four copies of the same model.

In simple terms, a foundation model learns a broad domain before it is adapted to specific tasks. Language models learn patterns in text; Vulcan learns relationships inside structured payment records.

The backbone is Vulcan’s reusable core. It learns common relationships across payment records and turns each payment into a compact numerical summary that task-specific layers can use. Each application still brings its own decision-time inputs, recent context, label, decision layer and way of measuring success. Here, a label is the later-known answer used during training—for example, whether a routed payment succeeded or a parcel was returned.

How Vulcan learns reusable payment patterns

The backbone is pretrained across varied payment records spanning payment methods, merchants, issuers, credentials, geography and time. The records are not selected for one downstream outcome such as routing success or fraud. This breadth is what lets the model learn the structure shared by many payment decisions.

A payment record is not a sentence. Its fields do not have a useful left-to-right order, and many fields are absent for a given payment method. Vulcan therefore represents the available fields as a set. Each field carries its identity as well as its value, and a Set Transformer learns which fields explain one another.

The self-supervised task is called Masked-Field Prediction (MFP). During training, some fields are hidden and the model predicts them from the fields that remain. It might see the payment method, amount and time while the issuing bank is hidden. The task is to recover the bank, not to predict fraud or routing success.

The result is a reusable payment representation. A new application can start from that foundation instead of relearning basic payment relationships, while still training and testing the parts that are specific to its decision.

How routing combines durable knowledge with recent state

Routing needs two kinds of knowledge. The backbone encodes the fields in the current payment and produces a durable payment representation. Separately, a recent-context encoder summarises recent terminal, merchant and gateway activity. Live route-health signals join this second path at decision time.

Fusion lets the current payment ask which parts of that recent context matter now. The routing head turns the fused context into a score for one eligible candidate. Calibration converts that score into an estimated probability of success. The flow repeats for every eligible candidate, and the routing system orders them by those probabilities.

With that architecture in mind, the routing problem becomes easier to state: choose well while the shopper waits, using both long-lived payment structure and conditions that may have changed moments ago.

Question one — which route will succeed?

Of the paths available to this payment right now, which is most likely to work?

• Decision moment – inside the payment, in milliseconds, while the customer waits
• Cost of error – a customer who wanted to buy is turned away by infrastructure
• Core challenge – there are many possible paths, and their performance can change within minutes

When an online payment fails, the shopper waits and then sees an error message saying it did not go through. They had already decided to buy, yet the payment infrastructure turned them away. Some retry; others leave. One failure rarely looks like an incident, but many small failures add up to lost sales. It can also distort checkout analysis: an infrastructure failure may look like shopper abandonment, while a retry prompt that ignores the failed attempt may choose the wrong recovery.

What does “failure” actually mean?

“The payment failed” tells us very little. Several different events can produce the same message, and only some of them can improve if we choose another route.

What happened	Example	Can a different route help?
The route declined	The bank refused the payment because of capacity, a risk rule or maintenance.	Yes. Another path to the same account may work.
The route timed out	No response arrived in time. The payment may even have succeeded without sending a timely confirmation.	Yes. This is especially costly because the customer waits before seeing the failure.
It failed late	Accepted, then failed at the last step. The customer often believes they have paid.	Sometimes. Worth predicting because the experience is worst here.
Customer-side constraint	Insufficient balance, wrong PIN, limit exceeded, expired instrument.	No. Infrastructure routing cannot solve these conditions.
The customer left	The payment app never opened, the request expired or the one-time password was never entered.	No. This is not an infrastructure failure.

Before Vulcan can score routes, training must separate failures that a route can influence from those it cannot. A wrong PIN or abandoned payment adds noise to the routing signal; declines and timeouts can reveal patterns by route, bank and time of day.

What a route actually is

“Route” sounds like one choice. It is not. A payment travels through a specific credential on a specific payment rail. That credential represents one merchant’s arrangement with one provider. A merchant may have several eligible credentials on the same rail, and two similar credentials can perform differently on the same afternoon.

The shopper chooses the payment method. We choose the path that method takes. The shopper never sees this second decision.

A purchase in India may use the Unified Payments Interface (UPI), a card, netbanking or a wallet. Within each method, the possible paths vary by payment flow, bank, provider, credential and time. A rule that works for one bank at 11 a.m. may be wrong for the same bank at 6 p.m.

Why rules and retries run out

Rules are fast, visible and easy to debug, so they are a sensible starting point. But there are too many combinations of path and condition to describe by hand, and rules grow stale. A rule written for an outage in March may still avoid the route in September, months after it recovered. Because the system no longer tries that route, the better outcome remains unobserved.

Retries help after a failure, but they do not replace a good first choice. The shopper is still waiting, and another route cannot fix an insufficient balance, a wrong PIN or an abandoned payment. Vulcan’s routing decision has to choose well before a retry is needed.

Question two — is this fraud?

Is this payment part of a pattern that will turn into a loss?

• Decision moment – at the risk check, before the payment is authorised
• Cost of error – both directions hurt — a loss, or a real customer turned away
• Core challenge – the evidence is spread across merchants who cannot see each other

Routing is difficult because paths change quickly. Fraud is difficult because one merchant may see only a small part of an attack. In card testing, attempts can be spread across unrelated merchants so that each business sees only a few ordinary-looking, low-value failures. Across the network, related instruments and tight timing can reveal the pattern.

The confirmed outcome also arrives slowly. Fraud may be confirmed only when a dispute appears weeks later, and some fraud is never reported. We therefore compare detection at the same alert volume: catching more fraud by reviewing more payments is a threshold change, not proof that the model improved.

Question three — will this parcel come back?

If this customer is offered cash on delivery, will the parcel be accepted?

• Decision moment – around checkout or order placement, before the payment or delivery outcome is known
• Cost of error – the merchant pays shipping twice and gets the item back, possibly unsellable
• Core challenge – the available context is limited, and the answer arrives after the delivery attempt

Cash on delivery remains important for many Indian shoppers and merchants. But a rejected parcel costs more than a lost sale: the merchant pays for the outward and return journey, ties up working capital and may receive an item that is harder to sell again.

The decision is made around checkout or order placement, when the order, delivery location, cart and available customer context may be known but the payment and delivery outcomes are not. Feedback arrives only after the delivery attempt. A merchant’s own return history may also be small, so patterns across delivery areas and repeated ordering behaviour become useful.

Checkout asks a different kind of question. It is not trying to detect risk or choose infrastructure. It is trying to understand what the shopper is likely to use.

Question four — which method does this shopper want?

Magic Checkout, Razorpay’s checkout, has to order payment choices before the shopper selects one.

Of the payment methods we could show, which will this shopper actually complete with?

• Decision moment – as the checkout page renders
• Cost of error – a shopper hunts for their method, or gives up looking
• Core challenge – the options are nearly identical, and failure is silent

The order matters. A shopper who sees their preferred UPI app near the top can continue immediately; someone who has to search may leave. Unlike routing, the choices can look almost identical. The useful signal comes from the shopper’s context and earlier behaviour.

Feedback is incomplete. We can see the method a shopper selects, but not the method they wanted and could not find. If the shopper leaves, the data rarely explains whether the ordering caused it.

The four decisions now look very different in timing and feedback. The next question is why we should build one shared model for them instead of continuing with a separate model for each.

Why sharing matters

Separate models repeat work. Teams prepare similar payment records, define overlapping features and train another base model, while useful learning stays inside the model that discovered it.

Vulcan moves that common learning into the foundation. A new application still needs its own data, label, decision layer and evaluation, but it can start from an existing payment representation instead of rebuilding the base model from the beginning.

What we can see across the network

Several decisions above depend on patterns that one merchant cannot see alone. We can see how the same route, issuer or instrument behaves across many businesses. That network view is one reason a shared payment model is useful.

A bank has a long history of one customer’s account and can learn deeply about that person. A payments platform sees less of any one person’s financial life, but it sees payment infrastructure working across many merchants. These are different kinds of information, suited to different questions.

Why India’s payment variety matters

A purchase in India may use UPI, a card, netbanking or a wallet. Within those methods are many banks, providers and merchant credentials. Their behaviour changes with capacity, maintenance and time of day. This variety makes fixed rules difficult to maintain, but it gives a model useful examples of how payment conditions differ.

The network view is most useful when a simple lookup has little history: a new credential, an instrument seen only once, or a pattern spread across merchants. Vulcan can start from broader payment patterns instead of treating every unfamiliar case as completely new.

The model does not decide what a merchant is allowed to use. Eligibility, merchant configuration and contract rules remain outside the ranking model. Vulcan ranks the choices that are already allowed.

How we measure it

A model number is useful only when the reader knows what it was compared with, which traffic it covered and when that traffic occurred. Without that context, an improvement can be technically correct and still be misleading.

For payment success, the comparison should be the routing logic that would otherwise have handled the same traffic. Absolute success rates move when merchant mix, payment methods or seasonality change, so a before-and-after average is not enough.

Time matters too. A random split lets training and test rows share the same period. We instead train on earlier payments and evaluate on later ones. Results should also be checked by payment flow because a single average can hide one flow improving while another becomes worse.

Ranking and calibration answer different questions. Ranking asks whether the model puts better choices above worse ones. Calibration asks whether a score interpreted as a probability behaves like one. A model can improve the ordering while making its scores less trustworthy, so both need to be checked on later traffic and within the flows that will actually use them.

Routing also has a counterfactual limit: logs reveal what happened on the chosen route, not what would have happened on every route that was available but not selected. Out-of-time tests expose drift, but they do not remove this selection bias. Controlled online evaluation is still needed to measure the causal improvement from changing the routing decision.