Juspay's Nishant Sameer on open-source, composable payments

Nishant Sameer, VP Product Strategy & US Business at Juspay, explains how open-source, composable infrastructure is reshaping enterprise payments.

What has changed (technically, commercially, or in terms of merchant expectations) that is now making open-source infrastructure a credible alternative in payments?

The fundamental change is that payments has become much more of an infrastructure problem. Merchants today are dealing with an evolving payments landscape: multiple processors, payment methods, fraud systems, authentication layers, regulatory requirements, and increasingly sophisticated optimisation needs. 

The payment stack is no longer something you integrate once and leave alone.
Traditionally, there were two choices. You could build a lot of this infrastructure in-house, which gave you full control but required a very large engineering investment, both in building and maintaining your stack. Or you could buy it from a provider, which helped you go live faster, but often meant accepting someone else's architecture, roadmap, and commercial model. Open source provides a third option. You can start with a proven foundation, inspect how it works, adapt it to your requirements, and decide how much of it you want to operate yourself.

At the same time, the barriers to adopting and operating open-source infrastructure have come down. Cloud infrastructure, containerisation, and modern developer tooling make self-deployment much more practical than it was even a few years ago. Merchants also increasingly expect their payments infrastructure to be adaptable, whether they’re adding a new processor, supporting a new payment method, or changing how transactions are routed and optimised.

One additional nuance is understanding what open source prioritises to replace. It doesn't necessarily touch the card networks, the regulated and licensed PSPs and acquirers, or the certified vault, tokenization, and 3DS providers who operate the compliance layer the industry designed. It prioritises itself to sit above them as the harness – the software layer that controls the critical path of the customer experience and ties those regulated components together.

The important point is that open source isn't compelling simply because it is free. For payments, the bigger value is control, transparency, and flexibility. That is becoming increasingly important as merchants realise that their payments infrastructure is strategic infrastructure, not just another SaaS dependency.

Hyperswitch operates under an Apache 2.0 licence and is PCI-certified. How did you approach building an open-source platform that satisfies both community-style openness and the compliance rigour that enterprise payments teams require?

We don't see openness and enterprise-grade security or compliance as opposing ideas. In fact, when the underlying code and architecture are open, enterprise security teams can inspect what they are actually running rather than having to take a provider's assurances at face value.

With Hyperswitch, we deliberately chose the Apache 2.0 licence because we wanted the platform to be genuinely usable by enterprises, developers, and partners without creating licensing barriers. Anyone can read the code, fork it, deploy it, or build a product on top of it. An enterprise legal team can approve it without a long negotiation.

But that openness doesn't change the engineering standards we apply to the platform. We have treated Hyperswitch as payments infrastructure first, which means security, reliability, performance, observability and PCI compliance are designed into the platform from the beginning. For merchants that want to self-host, we publish deployment guidance, so they know exactly what falls into their scope and what doesn't.

The design decision that made both possible was isolating card data handling from everything else. In Hyperswitch, the vault is a pluggable component. A merchant can use ours or connect an existing one –such as VGS or TokenEx – to keep card data entirely outside our boundary and pass us tokens. Their PCI scope stays where they already had it, and adopting orchestration doesn't widen it.

For us, the goal has been to make openness and compliance work together rather than treating them as trade-offs. Open source determines how the software is developed and distributed; compliance determines how the software and the surrounding environment are designed, deployed and operated. One doesn't eliminate the other.

The composable architecture is often seen as a technical benefit, but it may also shift responsibility onto the enterprise itself. What does that shift look like in practice for a merchant or bank moving from an all-in-one provider to a modular payments stack?

There is a shift, but it is primarily a shift from dependency to architectural ownership, rather than taking on operational burden. With an all-in-one provider, key decisions about how payments work – how routing works, which processors you connect to, how integrations are maintained – sit outside the enterprise’s control. With a modular stack, the enterprise gets to make those decisions itself. It can also replace or upgrade one component without disturbing the parts that are working.

What that requires in return is architectural thinking. Once a merchant or a bank is assembling components, it needs to start thinking about things such as reliability and failover, scalability during peak volumes, security boundaries, observability, and how changes are deployed and rolled back. That is the difference between a composable architecture and a collection of point solutions.

But modularity doesn't mean the enterprise has to own every component or operate everything itself. It can choose where it wants to have control and where it wants to rely on a service provider. The important difference is that those choices are explicit rather than being dictated by an all-in-one platform.

It is also why migration is designed the way it is with Hyperswitch – an enterprise can introduce the orchestration layer alongside its existing payments setup and gradually move traffic across rather than making a disruptive cutover. That allows it to take ownership incrementally rather than having to rearchitect its entire payments stack at once.

So, I would see the shift less as taking on more responsibility and more as choosing where you want responsibility to sit. A composable architecture gives merchants and banks the ability to own the parts of payments that are strategically important to them, while continuing to abstract the parts they don't want to operate themselves.

Hyperswitch allows merchants to self-deploy and test the platform independently. What distinguishes the organisations that are ready to take on that responsibility from those better served by a managed deployment?

It is less about the size of the organisation and more about how strategically it views payments and how much control it wants over its infrastructure.

Organisations that have complex payment setups – multiple processors, markets, payment methods, or optimisation requirements – tend to get more value from owning the payments layer. If payments have a direct impact on revenue, conversion, costs, or the customer experience, having the ability to make changes to the stack without waiting on a provider can be strategically important.

The other factor is operational maturity. Self-deployment makes sense when an organisation has the engineering and infrastructure capabilities to operate production systems, along with the security, compliance, and observability practices that come with running critical payments infrastructure.

But that doesn't mean self-hosting is inherently better. There is no value in taking on operational responsibility simply for the sake of it. An organisation may want the flexibility and control of an open, composable payments stack while preferring someone else to manage the underlying infrastructure. And because Hyperswitch is open source, organisations can evaluate it on their own terms before making that decision, without having to commit significant time or resources upfront.

We treat self-hosted and SaaS as different operating models rather than different philosophies. Both give organisations the same underlying open payments infrastructure, and they can choose the model that fits their capabilities and priorities. As those priorities change, they can also move between operating models without having to change the underlying architecture.

As card networks, regulators, and PCI frameworks were largely built around identifiable, accountable vendors, how is the industry adapting compliance and liability models to accommodate open-source infrastructure that enterprises self-deploy and customise?

Open source doesn't mean that accountability disappears. When an enterprise self-deploys a payments platform, it is responsible for how that software is configured, where it runs, what data flows through it, how it connects to other systems, and how the overall environment meets the applicable regulatory and security requirements.

What matters is having clear boundaries of responsibility. Enterprises have been running open-source operating systems, databases, networking software, and security infrastructure for years. The creator of an open-source component isn't automatically responsible for how an enterprise chooses to deploy and operate it. It's the same shared-responsibility model that already applies to cloud – what the enterprise is responsible for depends on which parts it operates and where it stores the card data. The merchant or bank remains accountable for its payment environment and the controls it operates. Processors, acquirers and other regulated participants remain accountable for the services they provide. The orchestration layer sits above the regulated line, inside the merchant's own environment, and simply creates workflows without displacing a regulated participant. The infrastructure layer needs to support those responsibilities with the right controls, documentation, and auditability. 

When an enterprise needs a contractual counterparty, it can ask the creator of open-source software for enterprise-edition support or even a managed SLA-led deployment model in which the creator operates the infrastructure and the core payments-harness, and is fully accountable for software upgrades, SLAs, incident response, issue resolution, and its own service-provider certification for the hosted offering. The enterprise chooses how much accountability to internalise and how much to place on the creator as a commercial counterparty. 

This is also where open source can be an advantage. When the architecture and code are visible, enterprises have greater ability to understand what is actually happening inside their payments infrastructure and to validate how different components interact. As payments infrastructure becomes increasingly modular, that clarity will become more important, not just for compliance, but for security, operational resilience, and ultimately trust.

Looking at how AI is starting to reshape commerce, why does open, programmable infrastructure matter more in that future than it did in the card-present, rules-based world payments has run on until now?

AI changes the nature of the interaction between commerce and payments. In a traditional flow, a customer chooses what to buy, goes through a checkout, and initiates a transaction. The payments stack can therefore be designed around relatively predictable, rules-based flows. With AI, the agent transacts under a mandate – a delegated authority to discover a product, compare options, choose a payment method, and decide when to buy on behalf of a consumer or business, potentially making repeat purchases over time. The payment infrastructure has to respond to those decisions dynamically, and honour the limits behind them, rather than simply execute a fixed checkout flow. It now has to enforce those constraints at the moment of execution and produce a verifiable record of why the transaction happened at the point of payment.

That makes programmability much more important. You need infrastructure that can make decisions based on context: the merchant, customer, geography, payment method, processor performance, cost, risk, and potentially the intent of the transaction. That is where an open payments layer matters more. You don't want those decisions sitting inside a single provider's system, where you can't see or change how they're made. If the commerce layer is becoming more dynamic, the underlying payments infrastructure needs to be equally flexible and accessible to the systems making those decisions.

Hyperswitch's role is the merchant-side execution layer: it receives the agent's decision, enforces the mandate's constraints, routes accordingly, and produces the audit trail – while the consumer-side agent is built by the platforms themselves. Because the underlying payments infrastructure is open and programmable, enterprises can build and integrate new capabilities, and adapt to new agentic standards as they emerge, without having to wait for a single provider to decide what the next generation of commerce should look like.

AI is going to make payments more software-defined. And when infrastructure becomes more software-defined, openness, programmability, and composability become much more valuable.

About Nishant Sameer

Nishant Sameer is Vice President, Product Strategy at Juspay, where he leads new products bringing Hyperswitch to the US – the open-source composable payments infrastructure for merchants, banks, and vertical SaaS platforms.

Nishant's work spans payment infrastructure, orchestration, and autonomous, interoperable systems built in partnership with merchants and fintechs. Before payments, he built products across biometrics, identity, adtech, and ecommerce, and spent a decade in devices, wireless, and multimedia systems engineering.

About Juspay

Juspay is a multinational payments technology company, powering superior conversion rates, seamless customer experiences, cost optimisation, and fraud reduction at scale for 500+ top global enterprises and banks. Founded in 2012, the company processes over 300 million daily transactions, exceeding an annualised total payment volume (TPV) of USD 1 trillion with 99.999% reliability. Headquartered in Bangalore, India, Juspay’s global network of 1,500+ payment experts operates across Dubai, Dublin, San Francisco, São Paulo, and Singapore.

Juspay Hyperswitch is the world’s first open-source, modular payments platform. With an Apache 2.0 license, PCI DSS certification, and a Rust codebase, it gives merchants a fully transparent payments stack with no vendor lock-in and no black-box logic. Merchants can self-host it, deploy it on their own cloud, or use it as a fully managed SaaS with out-of-the-box compliance and enterprise SLAs. Engineered as the ‘Linux for Payments,’ Hyperswitch has crossed 43,000 stars on GitHub, making it one of the most starred open-source projects in fintech.