[#48] The New Payment Orchestration Playbook: Merchant Effort Needed & a Crossborder focus
Recent changes in PhonePe's strategy to not integrate with Juspay's Hyperswitch, and PayU onboarding on Boxpay suggest a shift in payment orchestration strategies
So a couple of interesting news pieces came out in the last couple of months, which were to do with payment orchestration.
PhonePe announced that it will not be a part of Juspay’s payment orchestration platform (Hyperswitch) anymore, and focus on direct integration and relationships with the merchant. This is a significant move, since according to sources, 15% of PhonePe’s volume comes routed through Hyperswitch.
PayU onboarded on Boxpay, which is a cross border payment orchestration platform
If I had to look at the top payment aggregators in India, in no particular order, I’d say they are PayU, Razorpay, PhonePe, Cashfree, and Plural. So both these moves together are interesting. One is moving away from an orchestration platform, but another has onboarded on yet another.
It’s not that simple though. There are multiple things to unpack here.
When PhonePe drew away from Juspay’s orchestration platform, this is the domestic (India) orchestration. PhonePe launched its PA services in India in 2022 - 2023. So it clearly feels that it’s developed enough of a brand on the B2B side to enter into direct relationships with merchants. Enough to take a 15% hit on their total volumes (15% of PhonePe volumes come through Juspay’s orchestration platform. Just as a refresher, PhonePe started out as a consumer app in 2015, and rode the UPI wave to capture the consumer app market share in India, currently trending at 50%.
Juspay earlier was purely a tech player. It provided payment optimization (orchestration) & and a payments stack to power UPI Apps. However, it received a payment aggregator license in Feb 2024. So from an agnostic tech player, it suddenly became a competitor to the leading PA’s in India, which it had at that time, onboarded on its orchestration platform. And this is probably what has led to PhonePe stepping back, and I expect other top PA’s in India to follow suit. Another point to note here is that reportedly 88% of Juspay’s revenue comes from orchestration platform. So somewhere, some maths has been done, which justifies building a PA in a crowded market at the cost of orchestration volumes. My own view? It’s one step towards an international play by Juspay, since thats where the margins are.
Boxpay is an international payment orchestrator, HQ’ed in singapore, which probably means its focused on the SEA region, similar to INAI. And it’s a fairly young company: founded in 2022. Doesn’t have a PA license (yet). Which is probably why PayU onboarded on them. The challenge comes in when the standalone orchestrators expand into full stack payment services, and start competing with their “clients.”
And by the way: increasingly, orchestration as a standalone play is not working. Most PA’s have their own orchestrators now: Razorpay has Optimizer, Cashfree launched Flowwise, Stripe has Stripe connect. Juspay, which was the OG orchestrator is expanding into a full stack fintech. Only newer players, which were founded in 2020 and after, such as INAI (2021), Boxpay (2022), and Primer (2020) are standalone orchestrators. Zooz was standalone, but was acquired by PayU in 2018.
Source: Dealroom
But lets take a step back. How does payment orchestration work?
Well, at a high level, for a merchant to accept payments, they need to have a payment gateway, and / or a payment aggregator. A payment aggregator is an aggregator of payment gateways.
Before payment aggregators, merchants would have to get enabled separately on different payment gateways, which could be through different banks, and different requirements were needed for different methods. Example: The gateway for cards would be different, the gateway for UPI would be different and so on. And for each of these, the merchant would have to open an account with the bank, and maintain it, for settlement purposes.
Enter the payment aggregator: Now, through one integration, the merchant could enable all payment methods. It was the payment aggregator’s responsibility to maintain the different pool accounts with the acquiring bank, get it settled into their escrow, and then settle to the individual merchant account.
Below is a snapshot of how payment aggregators work.
As this evolved, and the dependency on payment aggregators grew, merchants very rightly so, didn’t want to put all their eggs in one basket. Merchants wanted to integrate with multiple PA’s, but more than that, optimize routing to the different gateways aggregated by the different PA’s.
They wanted to build out more optimizations, by routing based on success rates, methods, and pricing. Enter the “payment orchestrator.”
Think of this as a layer between the different payment aggregators, that based on certain predefined rules routes the payment to the gateway of a specific aggregator. And the OG payment orchestrator in India atleast was Juspay, with their hyperswitch model. The way this works is, once the checkout is initialised, the customer initiates payment, which is then sent to the orchestrator, which routes this payment request to the gateway basis certain logics that the merchant has written out: could be basis success rates, costing, methods, or anything else.
The only catch here is that the merchant has to individually onboard on each payment aggregator, since they are separate entities, and there are stringent KYC laws around payment aggregators. The way it works right now is that you onboard on each PA directly, and then enable it on the orchestrator that you’re on. You can check out this video here to see how Razorpay optimizer works.
And essentially, once the merchant has onboarded different PA’s to its orchestration platform, the orchestration platform becomes what the merchant uses the manage payments across multiple PAs. The orchestrator provides a dashboard that the merchant can use to manage payments across different PAs. An example: At the orchestrator level, I can see which methods are enabled on different PAs, and enable accordingly. I also have one dashboard that I can see all my payments metrics across.
A diagram of how payment orchestration works below:
Razorpay Optimizer dashboards to add PA / PGs, and configure rules
The payment orchestrator flow
The payment orchestrator acts as the middle layer between the merchant and the PAs. Here’s an example of how it works:
The customer comes to the merchant checkout, and initiates the payment
The merchant backend calls (lets say Juspay’s) Orchestrator API (which is hosted with Juspay servers)
The orchestrator analyzes the SR and routes the transaction to the PA / PG which has the best success rates, lowest latency, and whatever other metrics the merchant has enabled: things such as cost etc.
Transaction is sent to the chosen PA, which then sends it to the PG. The PA further processes the request and sends it to a PG. Example: Juspay → Razorpay (PA) → Razorpay PG (or another PG integrated with Razorpay).
PA / PG handles authentication (Acquiring Bank + Network Rails). This happens via a MPI / DS under the 3DS 2.0 (which is mandatory in India) or via the UPI rails.
If the transaction fails, the orchestrator auto retries via a different PA. If Razorpay fails, the transaction can be retried via PayU, for example.
Once successful, the acquiring bank (of the PA) sends a capture request to the issuing bank. The funds are moved from the customer bank to the acquiring bank pool account. From there they are settled into the PA escrow, and then into the merchant account.
And there’s an additional point here: All saved customer payment preferences, and tokenized details are stored at the orchestrator layer, and then used across PAs.
This is another reason why PA’s want to go the direct route. While orchestrators come in and handle a lot of the preliminary checks, transaction routing, data visibility and customer data, this is a problem for PAs, since in the absence of orchestrator’s PAs would own all this. An example is tokenized customer data / preferred payment methods / tokenized card details. Earlier the PA’s were holding this. Now, in the case of an orchestrator, the merchants are handling all this on the orchestrator dashboard and platform.
Orchestrators monetize on total volume routed. On crossborder, the potential margins on orchestration are higher, because payment margins generally are higher.
Like payments, they make money on the total volume routed. On the domestic side at least, this is not more than a few bps. However, on the cross-border side, this could have more, just by virtue of 1) higher margins in cross-border, and 2) increased complexity of routing.
Cross border orchestration complexity stems from different regulations, payment method preference, frauds, and data privacy laws in different geographies.
Europe has GDPR & PSD2 for customer data handling. India is coming out with its DPDP Act. Australia has CDR. Singapore has their own MAS playbook. So for cross border orchestrators, how they’re handling, and routing the data in different regions can be very different. There are also different payment method preferences in different regions, and each of these have different fraud propensities. For a payment orchestrator to optimize payments, this is also visibility that it needs to have, and this needs to be configured as an additional parameter, OR handled seamlessly at the backend.
Additional fees can also play a role in routing: exchange rate lock in for dynamic currency conversion may place an additional cost burden on the merchant. And finally, maintaining integrations with multiple PA’s and multiple gateways in each region requires a lot of investment.
And it’s not just orchestration to optimize on payment routing. Another benefit is settlement reports & data.
And along with just orchestration, there is another use case. It’s data. Earlier, when merchants had multiple integrations with multiple PA’s, they would get separate reports, and data from separate PA’s. The orchestrator acts as a unifying platform, which is able to give consolidated data & analytics, essentially providing a 360 degree view of the merchant payment performance.
There’s also an opportunity to hop on the AI bandwagon, and basis the data provide the merchant insights and recommendations on improving metrics such as GMV, AoV, frequency and Success Rates across overall payments, not just at an individual PA level. An example of an AI powered recommendation is, “We’ve seen xx% merchants of your profile, increase SR by enabling xx method.”
Below is an example of the analytics a payment orchestrator can provide. You can check out the Razorpay docs here
So orchestration is definitely adding value. Its a merchant need. But then how will it evolve - if all PA’s are also orchestrators, and no PA wants to get on a competitors orchestrator?
I mentioned before: All PA’s seem to have their own orchestrators now. And standalone orchestration as a theme may not work, atleast on the domestic side, since players are expanding from just orchestration, to full stack fintechs which usually includes a PA play. On cross border a standalone orchestration play may still work because of the massive TAM. But this is yet to be seen
So if everyone has their own orchestrator, and competitors don’t want to get on competitor orchestrators, how will this play out? Because in this example, if the merchant is on Razorpay’s orchestrator, then this orchestrator will aggregate Razorpay as a PA, probably the long tail PA’s (Billdesk, CCAvenue come to mind), and the direct integrations that the merchant have done with bank payment gateways. It won’t have the top PA’s such as PhonePe, Cashfree, PayU and others.
Will orchestration go away?
Well, orchestration won’t go away. Merchants want it. But then this will have to be merchant driven / deployed by the merchant on their servers.
The way orchestration works currently is that there is a middle layer between the merchant checkout (which can either be the merchant front end, or managed entirely by the PA, depending on the type of integration that has happened). When the payment is initiated by the merchant, the request goes to the payment orchestrator, that is hosted on the 3rd party servers (could be Juspay in case of Hyperswitch, or Razorpay in the case of Optimizer). The routing logics kick in, and then are routed seamlessly to the relevant gateway which have been aggregated by the PAs. This is how the current orchestrators in India work, and what cross border orchestrators such as Spreedly and Payoneer offer.
But now PhonePe is moving away from this. And my hunch is, so will other PAs. So whats the alternative? Well. For starters merchants will have to build this orchestration layer, and deploy it within their servers. This way, the merchant does the routing in its own infra, and then calls the PA / gateway, and this doesn’t happen through some third party. So what are the options?
Merchants building this from scratch may be improbable, since this would require payments focus, so it would require some TSP building this, and handing over to the merchant to integrate and deploy: global analogues for this exist.
There are some solutions that exist for this.
Solution 1: Current orchestration solutions such as Juspay, Razorpay’s Optimizer and so on. Global examples also exist: Such as Primer & WhenThen which offer whitelabelled tech that the merchant can use to build, but this is still deployed on Primer & WhenThen’s servers for payment orchestration. The advantage of current orchestrators, and Primer / Whenthen is that go-live can be very fast, in some cases, it will take only days. Here, the deployment is done on a shared cloud and is controlled by the TSP that has built the orchestrator. So the merchants share the same environment, and all deployments are done here, and its more standardized, with less flexibility. This is important, as this is the issue current PAs have is that they have accused Juspay of “biased routing.” (Note: I am just stating facts, these claims have not been verified and are unproven as yet)
Solution 2: Go completely self hosted by the merchant, where the deployment is handled by the merchant, on merchant servers, either on-prem, or on the cloud. This is the toughest solution, and may only be viable for bigger merchants (such as MAANG companies) because of the expertise and the costs involved to self host it. However, this solution gives the merchant complete control of the payments orchestration layer, and so if a PA feels there is “biased routing” it only has the merchant to blame. (Edit: As 25th March 2025, Juspay has open sourced its orchestration code, and offers a completely self hosted model to merchants)
Solution 3: Hosted by the tech provider, but in a isolated cloud
Gr4vy is one example: it offers an orchestration solution that can is deployed within an isolated cloud instance, but is still managed by Gr4vy. What this means is that the merchant in this case gets a separate cloud environment that is different from other merchants, but Gr4vy still manages all the infra, maintenance and updates, so the merchants don’t have to worry about setting up servers or databases. This is a middle ground between 1 & 2. This gives a merchant more control over data and security, and allows more customization, but also takes more time and requires more merchant involvement. Also, here, the PAs may still have a problem with Gr4vy in the case of “biased routing” since Gr4vy manages it.
Solution 1 (the standardized Shared SaaS one) is plug & play. It requires minimal involvement from the merchant.
For the self hosted solution it’ll take way more time: it requires more payments expertise.
So for a bigger merchant, yes this will work. For a smaller merchant. Maybe not. But then again, orchestration only starts making sense for enterprise merchants who are processing a significant amount of GMV, for smaller merchants, the cost - benefit of this does not make sense anyway. So the payment orchestration model will probably change, in terms of the type of deployment.
And as cross-border payments grow, orchestration with its complexity will have to be figured out, and its possible that whoever figures it out first will end up capturing a large % of the market
For payments players with dreams of international expansion, orchestration may be the easier way to go. While there are complexities, there are significantly less regulatory hurdles, since the orchestration platform just handles routing logics, its not really involved in money movement, unlike a payment aggregator.
But, from another perspective it could be harder, because while merchants can always use one more PA or PSP in the name of “more options” they really only need one payment orchestrator. You don’t really need an “aggregator of orchestrators.”
And while the cross-border payments TAM is big (projected by some sources to be upwards of $200B by FY30), certain corridors and merchants are what will contribute to the maximum %. (the 80-20 rule, 80% of volumes contributed by 20% of the ‘n’). So it could very well be a situation of “whoever is first to the market” winning the game.
However, I do think there is an opportunity to build region specific orchestrators. The reason is simple: they will have similar regulations.
Ex: Boxpay and INAI are HQ’ed in Singapore, which means they’re focused on SEA & the Indian market. Other markets are Europe, LATAM, and the Americas. And we already see this with other fintechs, look at neobanks as an example: Revolut is primarily a European neobank, while Nubank focuses on LATAM - it started off in Brazil, and is now expanding to Mexico and Columbia. Kakaobank started off in South Korea, and is reportedly applying for a banking license in Thailand. And then of course, is the cross border connectivity across all SEA countries. So there are synergies between similar regions, which will also make it easier to build region specific orchestrators.
The way I think about is this: If you’re a merchant handling payments domestically then you just need visibility on the different payment methods domestically. And it may still be simpler to handle 4-5 PAs. Not easy, but manageable. But as a merchant wanting to go cross border, you’d want to have 2-3 PAs in each georgraphic corridor (one being the main, and one being the back-up). So automatically the number of PAs that you’re handling will increase. Handling these direct integrations will not work, it just doesn’t make sense. And another angle: there is similarity between regions, as I mentioned earlier. So if you’re expanding into Thailand, you’ll probably look at the SE Asia side. And if you’re going into Brazil, you’ll probably look at the whole of LATAM. The customer behavior will also be similiar, so similar payment methods etc would probably be used. Ideally then, I’d want 1 dashboard & platform to handle payments for each region.
So that’s an additional layer of tech that will have to be built: depending on the region, knowing which orchestrator to hit. But this is simple enough, and should be able to be handled by the merchant: not something you need another 3rd party building tech for.
First of all, this is a great article, and I truly appreciate the insights shared. However, here’s my perspective: the loss of PhonePe could ultimately be a bigger setback for PhonePe itself than for Juspay.
To truly disrupt Juspay’s dominance, it would require a coordinated exit of the top five payment aggregators simultaneously, creating a "trouble in paradise" scenario for Juspay. Otherwise, Juspay appears to be actively fortifying its position by enabling banks with the same smart gateway solutions it developed for HDFC.
Juspay’s stronghold becomes even more evident when we consider its robust merchant relationships and its Android and iOS SDKs. These SDKs, which are deeply integrated into the Indian ecosystem, inherently create powerful retention hooks that many are underestimating. Coupled with its high-retention orchestration product, this "super sticky" SDK makes it incredibly challenging to displace Juspay from the equation.
Your perspective aligns closely with mine on ecosystem to be moving toward merchant infrastructure-deployed solutions. This involves a connector-based system where Juspay-like infrastructure is embedded on merchant servers, communicating directly with gateways. This approach is likely to be well-received by gateways.
At the same time, it’s worth noting that payments have become highly commoditized, where processing a card transaction via Razorpay or HDFC’s smart gateway delivers nearly identical outcomes in terms of success rates. Decisions today are largely price-driven. If Juspay succeeds in collaborating with banks, the departure of any payment aggregator (PA) will have minimal impact on Juspay or the merchants relying on their solutions.
Great article and very informative as always, but do you have more info on the fraud cases for xborder orchestrator, since what you mention is a solution, but any idea on the actual fraud cases.