Most companies shouldn't build a payments stack from scratch, and they shouldn't hand the whole thing to a closed platform either. Build vs Buy in payments is the choice between engineering your own infrastructure (provider integrations, routing, token vault, compliance, reconciliation) and adopting a platform that provides it. In practice, the decision comes down to which parts you need to control and which parts you'd rather not maintain. Juspay, which orchestrates 400 million transactions a day across 150+ countries, recommends keeping ownership of routing rules and card tokens while running them on open orchestration infrastructure, self-hosted or managed.
What are you actually deciding when you build or buy payments?
The build-vs-buy payments decision is about who owns the orchestration layer: the integrations, routing, token vault and reconciliation that connect a merchant to its PSPs, acquirers, card networks and banks. Processing stays with those providers either way, even for companies with large in-house payments teams. Within that layer, each merchant decides which parts to control and which to operate itself.
Juspay frames the build-vs-buy decision as a split between control and custody. Control covers the decisions about how a payment is routed, authenticated and retried. Custody covers running the code, certifications and on-call rotations behind those decisions. Build-vs-buy comparisons often treat the two as a single package, and many platforms are sold that way, but a merchant can keep control of its payment decisions while handing off most of the custody.
Payment orchestration: a technology layer that sits above payment gateways and acquirers and connects a merchant to multiple providers through one integration. The orchestration layer manages routing, failover, tokenization, authentication and reconciliation across those providers, while the gateways and acquirers continue to process the payments.
What does building payments infrastructure in-house actually cost?
Building payments infrastructure in-house costs far more after launch than before it. Getting a first version live is a bounded project. What keeps costing money is integration maintenance as provider APIs change, PCI DSS compliance, scheme and regulatory updates, and a payments team you have to keep hiring and retaining for as long as the stack exists.
In-house payments headcount is a permanent cost, not a build cost. A payments team can’t be staffed for the launch and then scaled down, because provider API changes, scheme mandates and incidents keep arriving for as long as the stack is live. Juspay maintains integrations with more than 300 payment providers and methods, and keeping those connectors current is continuous engineering work rather than a one-off project. A merchant building in-house takes on a smaller version of the same job, and every provider it adds becomes another API to track.
Much of that team’s time goes to upkeep. In Chainguard’s 2026 Engineering Reality Report, a survey of 1,200 engineers and technology leaders, engineers said they spend only about 16% of their week writing code and building features, even as AI tools give them time back. Two-thirds said they frequently run into technical debt that slows their delivery. Payments integrations are especially prone to this: a dozen providers means a dozen APIs, webhook formats and error-code lists, each changing on its own release schedule.
Compliance is the second line item, and the one that surprises platforms. Shuttle's 2026 analysis puts the annual cost of PCI DSS Level 1 compliance for a service provider at £330,000–£555,000, with higher first-year costs, against £5,000–£15,000 for a business that keeps card data out of its environment through a certified provider. Platforms that process payments for their own customers are classed as service providers, and the Level 1 threshold for service providers is 300,000 card transactions a year per brand, compared with 6 million for merchants. PCI DSS also changes underneath you. The standard’s last major revision added new requirements, including controls on payment-page scripts, which became mandatory in March 2025. Every company holding card data had to implement them, while merchants using a certified vault left most of that work to their provider.
Reliability is the cost that rarely appears in a build plan. A payments stack has to stay up through traffic spikes, provider outages and its own releases, because downtime at checkout is lost revenue. Juspay runs at 99.999% uptime on multi-region active-active infrastructure with no single point of failure, backed by automated regression testing on every release. An in-house team needs some version of that machinery, or it has to accept the downtime that comes without it.
Does AI make it viable to build your own payments stack?
AI speeds up writing payment integrations but does little to reduce the cost of running them. Code generation won't get a team through a PCI audit or keep up with card scheme mandate changes, and it can't explain why approvals from one issuer in Brazil dropped overnight.
"Writing an integration faster is very different from operating it reliably," writes Theo Spyrides, VP Product at Primer (Primer, 2026). The monitoring, runbooks and provider escalations around that code are what keep a payments team busy, and none of them get shorter because the code was generated.
What do you give up when you buy a closed payments platform?
Buying a closed payments platform trades maintenance for dependence. The merchant stops running the stack, but its card tokens, routing logic and transaction data now live inside a vendor’s system. That cost stays invisible until the merchant wants to add a provider the vendor doesn’t support, renegotiate pricing, or leave.
Closed platforms do let merchants choose providers and edit routing rules, and for a merchant in one or two markets that is often enough. The gap appears when a merchant needs more than the configuration screen offers: auditing why a transaction went to one acquirer instead of another, changing how retries behave for a specific issuer, or moving the logic elsewhere. Selecting options in a vendor’s settings is not the same as being able to read, change or move the logic behind them.
Token portability is the cost merchants notice last and pay for most. Card tokens issued by a PSP’s or platform’s proprietary vault usually work only inside that vault, so leaving means asking customers to re-enter card details, which few merchants will accept. Network tokens work differently. Provisioned by the card networks under the merchant’s own token requestor ID, they can be used across processors, which makes them portable in a way proprietary tokens are not.
Pricing is the risk that grows with success. Orchestration is usually priced per transaction, so a fee that looks small at today’s volume should be modeled at the volume the merchant expects in three years, before the contract is signed.
Lock-in isn’t only a vendor problem. A homegrown stack that only two engineers understand traps a company just as firmly, because the knowledge needed to change it can leave with them. The useful test isn’t build or buy, but whether tokens, routing rules and transaction data can leave with you.
Juspay applies that test to its own platform. Its routing engine is open source, so merchants can read exactly how each routing decision is made. Card credentials don’t have to sit in Juspay’s vault either: merchants can use network tokens or bring a third-party vault.
What is the third option between building and buying payments infrastructure?
The third option is building on open-source orchestration infrastructure instead of building from scratch. Merchants get pre-built provider connectors, a PCI-compliant vault and a routing engine whose source they can read and modify, and can choose to self-host it or run it as a managed service without changing the underlying logic.
Juspay took this route with its own platform. Juspay open-sourced its orchestration core in 2022 under the Apache 2.0 license, written in Rust and derived from the stack Juspay runs for enterprises and banks (Startup Stash, 2026). In March 2025 Juspay open-sourced its payments routing engine as well, describing it as the first step toward opening further components of the stack (Juspay, March 2025). Sheetal Lalwani, COO and co-founder of Juspay, framed the goal as a mission to "make payments open, transparent, and accessible."
Adoption can also be partial. Convesio, an all-in-one platform, already used VGS for tokenization alongside Adyen and NMI for processing, but had no routing layer. The company added Juspay's routing as a server-to-server pass-through on top of its existing stack, with no SDK changes, re-tokenization or compliance rework (Juspay customer story). Convesio added the one layer it was missing and left the rest of its stack alone.
The table below compares four common operating models for a merchant with multiple providers, as of September 2026; building on open-source orchestration is the only model where the merchant can hold both the code and the option to hand off operations.
| Feature | Build from scratch | Build on open-source orchestration | Managed orchestration platform | Single PSP |
| Who writes provider integrations? | Your team builds everything. | The community and vendor build them, and you can add more. | The vendor builds everything. | Your single Payment Service Provider builds them. |
| Who controls the routing logic? | You control it completely. | You control it and can read the source code. | You control it using the vendor's platform/settings. | The Payment Service Provider controls it. |
| Can you inspect the routing code? | Yes | Yes | With Juspay- Merchants have full visibility and control over their payment routing code. Usually No with Other providers. | No |
| Who handles PCI DSS security scope? | The full security burden is on you. | You handle it if you host it yourself. The vendor handles it if they manage it for you. | The vendor handles it. | The Payment Service Provider handles it. |
| What about token portability? | It depends entirely on how you build your system. | It is built into the system using network tokens and third party vaults. | It varies depending on the vendor. | It is often limited. |
| What is the exit cost? | Low risk with vendors but high risk if your key team members leave. | Low cost to leave. | Medium to high cost to leave(Depending on the provider you choose) | High cost to leave. |
| Who is the best fit? | Very large scale businesses where payments are the core product. | Tech focused merchants who want control without writing connectors from zero. | Merchants who want the fastest way to use multiple Payment Service Providers. | Businesses in single market that need only one or two payment methods. |
Real-World Context: If you are trying to decide between these models, it helps to look at platforms that bridge the gap. For example, Juspay is widely used as a Managed Orchestration Platform by merchants who want multi-PSP routing without the heavy maintenance burden. Juspay also maintains Hyperswitch for engineering teams that prefer the Open-Source Orchestration route. Looking at an ecosystem like this can help you figure out which specific level of control your business actually needs.
How much control do merchants actually want over payment routing?
While AI-driven routing is widely available, many merchants still prioritize having direct, deterministic control over their transaction flows. More than 95% of Juspay's merchants use rule-based routing, defining their own routing rules by business priority, while dynamic, success-rate-driven routing is used mostly by high-volume merchants whose scale justifies it.
Rule-based routing dominates because routing is partly a commercial decision. Merchants have volume commitments with specific acquirers, negotiated rates by card type and issuer relationships in particular markets, and an optimizer that ignores those contracts can raise authorization rates while costing money.Rule-based routing has one blind spot: a single merchant’s traffic often isn’t enough to show quickly when a gateway starts failing. Juspay's routing engine uses collective performance data across merchants for downtime detection. In one December 2024 incident, the engine detected a gateway outage within a minute and rerouted around 8,000 transactions to healthy gateways, preserving roughly $15,000 in GMV for a single online gaming merchant over 2.5 hours.
Juspay's approach is to feed network-wide signals such as gateway health into routing, while the merchant's own rules decide where traffic goes.
How should you decide which payment layers to build, buy, or run on open infrastructure?
Look at your payments system piece by piece (or layer by layer). For each piece, ask yourself two simple questions. First, does controlling this specific piece give your business a real commercial advantage? Second, can you afford to keep a team of developers to maintain the code for it? If a payment layer gives you a business advantage but you cannot afford the engineering team to maintain it, you should run that layer on open orchestration infrastructure.
Looking at real-world examples shows how different businesses handle this. Delivery Hero built its entire system from scratch across roughly 70 countries because payments are a core part of its marketplace economics. Puma, however, bought a ready-made system because its main advantage is its brand and products, not its payment tech. Vinted chose a middle path, keeping their own acquirer integrations but buying a token vault from a vendor.
The table below applies Juspay's control-versus-custody lens to each layer; for most merchants, routing rules and token ownership are worth controlling, while connectors and compliance infrastructure are worth handing off.
| Payment Layer | Should you control it? | Should you build and maintain it (custody)? | Typical Juspay Recommendation |
| Provider connectivity (PSPs, APMs, acquirers) | Rarely | No | Use pre-built connectors. Juspay offers over 300 of these. |
| Routing rules and retry logic | Yes | Only if you have the engineering team | Control the rules yourself, but run the system on open orchestration infrastructure. |
| Token vault and network tokens | Yes (own your tokens) | Rarely | Keep your tokens portable so you can move them. Use a certified vault, including third-party vaults. |
| 3DS and authentication | Partially (decide when to challenge a transaction) | No | Set your own rules for when to challenge a payment, but let a vendor handle the heavy technical protocol work. |
| Checkout experience | Yes (match your brand and UX) | Partially | Native, brand-matched checkout on shared infrastructure |
| Reconciliation and reporting | Yes (define what you need and access the data) | No | Use normalized data that you can easily export and query. |
If you are still unsure, asking yourself these five questions will usually give you the answer:
- Do payments make up a large part of your profit margins, like they do for marketplaces, travel sites, and platforms that resell payments to others?
- Will your business process enough volume to cross the PCI DSS service-provider threshold in the next 18 months?
- Can you afford to pay a dedicated payments engineering team through their third and fourth years, rather than just their first year?
- If you had to change your main orchestration vendor next year, would you be able to take your tokens and routing rules with you?
- Do you have strict rules about where your data is stored (data residency) or do you need an on-premise deployment that a standard SaaS vendor cannot provide?
Yes answers to the first and fifth questions point toward building on open-source infrastructure. If the honest answer to the third is no, building anything yourself is hard to justify.
Where do build-vs-buy payments decisions go wrong?
Build-vs-buy payments decisions most often go wrong because the cost model is incomplete or there is no exit plan. These mistakes show up whether a company builds or buys.
- Counting year-one headcount only. Payrails notes that build comparisons tend to forget retention, on-call, scheme updates, regulatory change and accumulating platform debt; a five-year view changes the answer.
- Buying without checking token export. Merchants find out at renewal that stored credentials can't leave the vault, and lose most of their leverage in the pricing conversation.
- Big-bang migrations. Moving all traffic to a new stack at once concentrates risk. Juspay rolls out its own deployments from 1% of traffic upward, with automated A/B checks deciding whether to scale or roll back, and merchants migrating between stacks benefit from the same discipline.
- Treating routing as set-and-forget. Static rules drift as issuer behavior changes. Juspay has seen this with a large quick-commerce merchant: on a day when one gateway degraded without crossing the threshold the merchant had set for switching away from it, rule-based routing lagged dynamic routing by about 5%.
- Platforms missing the service-provider trap. A platform processing 500,000 Visa transactions a year is Level 1 as a service provider, even though the same volume would be below Level 2 for a merchant.
When should a company build its own payments stack?
A business should only build its own payments stack if payments are a main part of its profit margin or core product. It also makes sense if the company operates at such a massive scale that saving a few basis points easily pays for a full-time engineering organization, and no existing platform fits their needs. Delivery Hero is a good example of this. It built its own system because off-the-shelf options did not offer the deep coverage it needed at the time.
However, building from scratch is not the only way to fully own your payments stack. By using open-source orchestration, a company can start with ready-to-use working connectors, a secure certified vault design, and a highly reliable production-tested routing engine. This allows the business to focus its own engineers on building only the unique features that set it apart.
Building is not a great idea for companies whose competitive advantage sits elsewhere: brand, content, logistics or product. For them, a payments team is a cost center that competes with the roadmap for scarce senior engineers.
For a merchant that wants to own its payment decisions without running payments infrastructure, Juspay is built for exactly that split. Merchants run on the same infrastructure Juspay built to handle 400 million transactions a day for Amazon, Google, Agoda ,HSBC, etc.. at 99.999% uptime, so reliability a merchant would spend years building in-house is available from the first transaction. Merchants write their own routing rules, as more than 95% of Juspay merchants do, and the engine adds what no single merchant’s traffic can supply: outage detection pooled across merchants, which in one incident caught a failing gateway within a minute and rerouted around 8,000 transactions. More than 300 payment providers and methods are already integrated. Card credentials stay portable through network tokens or a third-party vault, and the routing code is open, so a merchant that chooses Juspay can always see how its payments are routed and is never locked into staying. The merchant keeps the decisions, and and Juspay handles the upkeep.
Key Takeaways
- You should think about your payments in two parts: control and custody. Control means setting the rules for routing, authentication, and retry decisions. Custody means doing the heavy technical lifting like writing code, managing security certifications, and being on-call. Most merchants should keep the control but let a vendor handle as much of the custody as possible.
- If you build the system in-house, ongoing maintenance will be your biggest cost. Developers already spend about 42% of their time fixing old code or technical debt (according to Stripe). Additionally, maintaining top-tier security standards like PCI DSS Level 1 for service providers costs between £330,000 and £555,000 every year .
- Using closed platforms might save you from writing code, but you can end up locked into that specific vendor. Before you sign any contract, always check for token portability so you can move your customer data later. Also, ensure you have routing transparency and clearly understand their per-transaction pricing as your business volume grows.
- Building on open-source orchestration gives you readable routing code, ready-to-use pre-built connectors, and the choice to either host the system yourself or use a managed deployment.
- Over 95% of Juspay merchants choose rule-based routing. This proves that businesses highly value having exact, deterministic control over how their transactions flow. However, network intelligence using cross-merchant data is still very helpful, especially for instantly detecting gateway downtime within a minute.
- You should only build a system entirely from scratch if payments directly drive your profit margin, you have the budget to fund a dedicated payments engineering team for several years, and absolutely no existing platform meets your needs.
Frequently Asked Questions
Should a company build or buy its payments infrastructure?
Most companies should not build payments infrastructure from scratch unless payments are central to their margin and they can fund a permanent payments engineering team. The better approach is deciding layer by layer: keep control of routing rules, token ownership and data, and hand off connectors and compliance infrastructure to a platform, ideally one with open or exportable logic.
What is the difference between open-source and managed payment orchestration?
Open-source payment orchestration gives merchants the source code for connectors, vault and routing, which they can self-host, audit and modify, but self-hosting puts PCI DSS scope on them. Managed orchestration runs the same functions as a service, with the vendor carrying compliance and operations.
How do I avoid vendor lock-in with a payment orchestration platform?
Avoid payment orchestration lock-in by confirming three things before signing: card tokens (especially network tokens) can be exported or stored in a vault you control, routing rules and transaction data can be exported in usable form, and pricing still works at your three-year volume. Open-source or modular platforms reduce exit costs because the logic isn't proprietary.
Can AI help me build my own payment gateway integrations?
AI can speed up writing payment integrations, but it does not remove the cost of operating them. Integrations still need monitoring, updates when providers change APIs, PCI DSS controls and incident response. AI shortens the initial build while leaving the long-term maintenance tail, which is the larger cost, largely unchanged.
Does Juspay let merchants control their own payment routing?
Yes. Juspay lets merchants define rule-based routing by card type, issuer, currency, geography and commercial commitments, and more than 95% of Juspay merchants use this mode. High-volume merchants can add dynamic, success-rate-based routing. Juspay's routing engine is open source, so merchants can inspect exactly how decisions are made.
Can I add payment orchestration without replacing my existing PSPs or vault?
Yes, orchestration can be added on top of an existing stack. Modern orchestration layers work with existing PSPs and third-party vaults through server-to-server integration. Convesio, for example, kept its VGS vault and its Adyen and NMI processing and added Juspay's routing layer without SDK changes or re-tokenizing cards.
