The Payments Black Box Problem Every US Engineering Team Knows
In a widely-read post on the Airbnb Engineering blog, Angela Zhu and Karen Kim described what scaling a payment platform from the inside actually looked like: "The integration of new payment processors was time-consuming and continued to increase code complexity”. Each new processor had to be built from scratch with no shared framework — and over time, the sprawl of isolated integrations created a system that was increasingly painful to change, report on, or extend into new markets.
Airbnb is not an outlier. Uber has published a similar arc across multiple engineering posts documenting the internal complexity of building a next-generation payment platform. Companies like these invested years of engineering effort and significant headcount into problems that, at their core, come down to the same set of challenges: no visibility into why a transaction failed, no leverage to change how routing decisions are made, and no clean abstraction across payment providers.
The underlying cause is structural. Proprietary payment processors are intentionally opaque. Their routing logic is their competitive moat. Their fee structure is their business model. And the more deeply your infrastructure depends on them — tokenized cards in their vault, webhooks baked into your application layer, reporting built on their APIs — the harder and more expensive it becomes to leave.
This is the problem Hyperswitch was built to solve. Hyperswitch, developed by Juspay and released under an Apache 2.0 license, is an open-source payments orchestration platform written in Rust. With 40,000+ GitHub stars, it is the payments infrastructure that engineers can actually read, run locally, audit before deploying, fork if needed, and self-host on their own cloud. No black boxes. No proprietary routing algorithms that have to be trusted without evidence. No vendor whose pricing model changes after you're fully integrated.
Why Payment Vendor Lock-In Is a CTO-Level Risk in 2026
Payment vendor lock-in isn't just an engineering inconvenience. For a US company processing millions of transactions annually, it is a strategic liability that compounds over time across three dimensions.
Cost leverage disappears. When your card vault, routing logic, webhook infrastructure, and reporting pipelines all live inside a single provider's ecosystem, you have no credible alternative at contract renewal. A 2022 Gartner study found that 58% of customers who feel "trapped" by a vendor eventually leave despite switching costs — and when they do, they become detractors. In payments, arriving at that point means years of suboptimal processing fees paid without recourse, because switching felt prohibitively expensive.
Unilateral policy changes land without recourse. Proprietary vendors change fee structures, dispute policies, and platform terms on their own timelines. When a merchant's entire volume runs through a single provider and card data lives in that provider's vault, there is no structural ability to respond by shifting volume. That is what lock-in looks like in practice: dependency so deep that the vendor's interests and the merchant's interests can diverge without consequence to the vendor.
Procurement and security teams can't audit what they can't see. Enterprise security reviews and vendor procurement processes at US companies increasingly require code-level visibility into the systems handling payment data. A proprietary black box fails this test by definition. "How does your routing algorithm work?" "What happens to card data when a customer disputes a charge?" "Can we verify your retry logic doesn't expose PII in logs?" These are reasonable questions that are simply unanswerable when the system is closed source.
Open-source infrastructure changes this calculus entirely. When the code is public, procurement teams read it. Security engineers audit it. Trust is earned through transparency, not asserted through a vendor's claims.
Why Rust Is the Right Foundation for Payment Infrastructure
Hyperswitch being written in Rust is not a stylistic choice. It is an engineering decision with direct consequences for reliability and security — the two properties that matter most in payment systems.
Rust has been named the most admired programming language in the Stack Overflow Developer Survey every year since its 1.0 release in 2015. In 2025, 72% of Rust users reported wanting to continue using it — the highest sustained retention rate of any language surveyed, according to the Rust blog. That loyalty reflects something real: Rust eliminates entire classes of bugs at compile time that other languages allow into production.
For payments infrastructure specifically, three Rust properties matter most:
Memory safety without garbage collection. Rust's ownership model prevents null pointer dereferences, buffer overflows, and use-after-free errors at the compiler level — not at runtime. A payment service that can produce a memory corruption bug under load is not infrastructure a CTO should be running at scale. As one distinguished cloud infrastructure engineer told the Rust team: switching from Java to Rust delivered "close to 9x to 10x performance wins" while eliminating the entire class of memory errors that had previously required dedicated debugging cycles.
No runtime performance overhead. Rust has no garbage collector pausing execution. For a payment service where latency directly affects checkout conversion, this matters. Garbage collection pauses are unpredictable by nature — they introduce latency spikes precisely during the high-traffic moments that most affect revenue. Rust's zero-cost abstractions deliver C/C++-level performance with none of the manual memory management risk.
When Juspay chose Rust for Hyperswitch, the team was making a deliberate bet: payment infrastructure should be held to the same reliability standard as operating systems and databases — not web applications. That bet reflects 12+ years of operating payment infrastructure at production scale, where reliability isn't a feature; it's the baseline.
What Makes Hyperswitch Architecturally Different
Most US merchants evaluating payment orchestration encounter a standard pitch: "One API, many processors, smart routing." Hyperswitch delivers on this, but the architecture underneath is fundamentally different.
Modular by Design — Not All-or-Nothing
Most orchestration platforms require merchants to adopt their full stack: routing, vault, checkout, reporting — all from one vendor. The migration barrier is, by design, the product.
Hyperswitch is built as independent, composable modules. A merchant already integrated with an existing processor can add Hyperswitch's intelligent routing on top without touching their vault or checkout. A team that wants to eliminate PCI compliance burden can adopt Hyperswitch Vault as a standalone service. An engineering team fighting subscription churn can deploy the revenue recovery retry engine without migrating their entire payments infrastructure.
This is how mature infrastructure software works — the same way teams adopt Postgres alongside an existing database, or Kafka for a specific data pipeline, without replacing their entire data stack. You compose what you need.
Self-Host or Fully Managed — No Lock-In Either Way
Hyperswitch supports two deployment models without forcing a choice at sign-up:
Self-hosted (Enterprise Edition): Deploy on AWS, GCP, or Azure using Helm charts or CloudFormation scripts. The AWS deployment is provisioned in 30–45 minutes. Engineering teams get complete infrastructure control, full data sovereignty, and the ability to run Hyperswitch inside their own security perimeter. Card data never leaves their environment.
Neither model creates lock-in. The code is Apache 2.0 licensed. If a team starts on managed SaaS and wants to move to self-hosted — or vice versa — the migration is an infrastructure decision, not a vendor negotiation.
300+ Connectors, One Integration
Hyperswitch connects to 300+ payment processors and local payment methods through a single unified API. For a US company expanding internationally, this means routing transactions across domestic and international markets — all through the same routing logic and analytics layer, without managing separate integrations.
The alternative is what the Airbnb Engineering team described: each new processor "built from scratch," with no shared framework, each integration adding to "the complexity of the system and introducing the potential for new bugs and issues." Hyperswitch replaces that accumulation of point-to-point integrations with a single, auditable abstraction layer.
Hyperswitch's Technical Capabilities That Engineering Teams Care About
Intelligent Routing: Rule-Based, Volume-Based, and ML-Driven
Routing is the core capability of any payment orchestration platform, and Hyperswitch exposes it at multiple levels of sophistication simultaneously:
Rule-based routing lets engineering teams codify business logic directly: route all card transactions over a certain amount to a specific processor, direct domestic debit to a lower-interchange acquirer, or apply geography-specific logic for each market. These rules run in a no-code visual builder in the Control Center, but they're also fully API-configurable for teams that want routing logic version-controlled alongside the rest of their infrastructure.
Volume-based routing distributes traffic across processors at configured percentages — useful for load balancing, A/B testing new processor integrations, or managing processor-specific volume commitments.
ML-driven routing dynamically selects the processor with the highest predicted authorization probability for each transaction, based on real-time performance data across card type, BIN range, amount, geography, and issuer. This is the mode that maximizes authorization rates without manual configuration — and it runs in parallel with rule-based logic, with configurable priority between the two.
Revenue Recovery: 30+ Parameters for Retry Logic
Passive churn from failed recurring payments is one of the most predictable revenue leaks in subscription businesses — and one of the most preventable. Hyperswitch's retry engine is configurable across 30+ parameters including decline code, error type, card BIN, ticket size, region, payment method, and issuer. The result is a retry strategy tuned to the specific characteristics of each failure type — not a blunt "retry after 24 hours."
For a US SaaS company with $10M ARR and even a 2% monthly passive churn rate from payment failures, recovering half of those failures through intelligent retries translates to $200,000 in recovered annual revenue.
Cost Observability: See What You're Actually Paying
Merchants on single-processor setups often discover processing costs only when the monthly statement arrives — with little ability to understand which transactions drove unexpected fees, why interchange downgrade penalties occurred, or whether they're on the optimal pricing tier. Hyperswitch's cost observability dashboards surface this data in real time: hidden fees, interchange downgrades, processing penalties, and cost breakdowns by processor, payment method, and geography.
This visibility has a direct commercial application: before routing optimization, you need to understand the cost baseline. After routing optimization, you need to verify the savings are materializing. Cost observability makes the economics of multi-processor payment infrastructure legible to both engineering and finance teams simultaneously.
PCI-Compliant Vault: Separate, Auditable, Yours
Hyperswitch Vault stores network tokens, PSP tokens, raw card credentials, and wallet data in a PCI-compliant vault deployed separately from the main application server. For US companies managing their own PCI compliance posture, this is operationally significant: the vault is a distinct, auditable service with a narrow attack surface, rather than card data embedded in a monolithic payment application.
Teams can deploy Vault as a standalone module — independent of whether they use Hyperswitch's routing or checkout capabilities. This makes incremental adoption viable: start with Vault to consolidate card data and reduce PCI scope, then layer routing optimization on top.
The "Linux for Payments" Analogy: Why It's More Than a Marketing Line
Linux succeeded not because it was free, but because it gave engineering teams a shared, auditable, composable foundation that no single vendor controlled. Teams could read the kernel, modify it for their use case, contribute improvements back, and trust that the underlying platform wouldn't change in ways that served a vendor's interests over their own.
Payment infrastructure has never had this. Orchestration platforms control their routing logic, their pricing, their API design, and their roadmap. When their interests and yours diverge, you find out after you're already committed.
The open-source model inverts this. With 40,000+ GitHub stars, Hyperswitch has a global community of engineers reading the code, filing issues, contributing connectors, and validating the architecture in real deployments. That community scrutiny is a different kind of quality assurance than a vendor's internal QA process — it's adversarial, public, and continuous.
For US engineering teams evaluating critical infrastructure, the question is no longer "Is open-source payments infrastructure mature enough?" It's "Why would I trust a payments black box when I can run code I can actually read?"
Who Is Hyperswitch Built For? US Engineering Profiles That Benefit Most
Platform engineering teams at high-volume e-commerce companies who have outgrown a single-processor setup and need routing, failover, and cost optimization — but don't want to build and maintain those capabilities in-house. Hyperswitch externalizes the complexity without creating a new black-box dependency.
CTOs at Series B/C SaaS companies evaluating payments infrastructure as they expand into international markets. The choice at this stage typically comes down to: build multi-processor integrations in-house (expensive, slow), go all-in on a proprietary orchestrator (creates new lock-in), or adopt open-source infrastructure that gives engineering teams control without the full build cost.
Fintech engineering teams at companies where the payments stack is a core product differentiator. For these teams, the ability to read and modify routing logic, run the vault in their own infrastructure, and audit the retry engine is not optional — it's a procurement requirement.
Enterprise security and compliance teams at US companies in regulated industries — healthcare, insurance, financial services — that need to verify payment infrastructure behavior before approving deployment. Open source passes this audit by design.
Juspay's Production Pedigree: What "Battle-Tested" Actually Means
Hyperswitch isn't a startup's first product. It's the open-source version of payment infrastructure that Juspay has been operating in production since 2012 — infrastructure that now processes 300 million transactions per day across 150+ countries, with USD 1 trillion in annualized payment volume, at 99.999% uptime.
That uptime number deserves context. Achieving this at 300 million daily transactions requires the multi-active architecture Juspay operates: no single point of failure across data centers, a horizontally scalable caching layer that absorbs traffic spikes without degradation, and a deployment framework where new releases roll from 1% of traffic progressively — automatically benchmarking against stable versions and rolling back on performance regression before the issue affects most users.
This is infrastructure that Amazon, Google, HSBC, Agoda, and Zurich Insurance trust with their payment stacks. The Hyperswitch GitHub repository is the public, auditable version of that same infrastructure. The production track record is what makes the "Linux for Payments" analogy credible: this isn't reference code — it's the same system running at global scale.
"At Juspay, we envision a future where payment systems are open and accessible. With Hyperswitch, our open-source payments operating system, we are delivering enterprise-grade performance — high reliability and scalability at low cost — to the global payments ecosystem," says Sheetal Lalwani, COO & Co-founder of Juspay.
Open Source vs. Proprietary Orchestrators: An Engineering Comparison
| Capability | Proprietary Orchestrators | Hyperswitch (Open Source) |
| Code visibility | ❌ Closed source | ✅ Apache 2.0, fully public |
| Self-hosting | ❌ Vendor-hosted only | ✅ AWS, GCP, Azure (30–45 min setup) |
| Routing logic auditability | ❌ Black box | ✅ Readable, configurable, forkable |
| Vendor lock-in risk | High — proprietary APIs and vault | Low — open standard, portable data |
| Modular adoption | ❌ All-or-nothing | ✅ Pick the modules you need |
| Processor coverage | Varies (typically 50–150) | 300+ |
| Core language | Varies | Rust (memory-safe, no GC overhead) |
| Deployment model | SaaS only | SaaS or self-hosted |
| PCI vault | Bundled, vendor-controlled | Standalone, self-deployable |
| Retry engine parameters | Limited | 30+ configurable parameters |
| Cost observability | Partial | Full, self-serve dashboards |
| Community validation | Vendor QA only | 40,000+ GitHub stars, public issues |
| Security audit process | Vendor-asserted | Code-level, independently verifiable |
Key Takeaways
- Proprietary payment processors create structural lock-in — through vaulted card data, proprietary APIs, and opaque routing logic — that compounds in cost and migration difficulty over time, as engineering teams at Airbnb and Uber documented publicly.
- Hyperswitch, built by Juspay and released under Apache 2.0, is the world's first open-source modular payments orchestration platform, written in Rust for memory safety, C-level performance, and compile-time concurrency guarantees.
- With 40,000+ GitHub stars, Hyperswitch has a global developer community auditing, contributing to, and validating the platform in real deployments — a form of quality assurance no proprietary vendor can replicate.
- Modular architecture means US engineering teams can adopt routing, vault, revenue recovery, or cost observability independently — without migrating their entire payment stack.
- Self-hosting on AWS, GCP, or Azure takes 30–45 minutes via CloudFormation or Helm. Fully managed SaaS onboarding is typically two to three weeks.
- Juspay processes 300 million transactions per day across 150+ countries at 99.999% uptime and USD 1 trillion in annualized payment volume — the production infrastructure Hyperswitch is built on.
- US enterprise procurement and security teams can audit Hyperswitch before deployment because the code is public — the answer to "Can we verify how your system handles our card data?" that no closed-source vendor can provide.
Frequently Asked Questions
What is Hyperswitch and how is it different from a traditional payment processor?
Hyperswitch is an open-source payments orchestration platform — not a payment processor. A payment processor handles transactions through its own infrastructure. Hyperswitch sits above multiple processors simultaneously, routing each transaction to the provider most likely to approve it at the lowest cost. It's written in Rust, released under Apache 2.0, has 40,000+ GitHub stars, and can be self-hosted on your own cloud. You own the routing logic, the vault, and the data.
Why is Hyperswitch written in Rust and why does that matter for payment infrastructure?
Rust prevents memory safety bugs — null pointer dereferences, buffer overflows, data races — at compile time, not at runtime. For payment infrastructure handling thousands of concurrent transactions, this means an entire class of production incidents that can affect systems built in other languages simply cannot occur in well-written Rust code. Rust also delivers C/C++-level performance without a garbage collector, eliminating unpredictable latency spikes during peak traffic. Rust has been the most admired language in the Stack Overflow Developer Survey every year since 2015.
Can Hyperswitch be added to an existing payment stack without a full migration?
Yes. Hyperswitch's modular architecture is designed explicitly for incremental adoption. An engineering team can add Hyperswitch's intelligent routing on top of their existing processor without migrating their vault or checkout. A subscription business can deploy only the revenue recovery retry engine. An enterprise team can adopt the PCI vault as a standalone service. Each module is independent — you pick what solves your specific problem and integrate it into your existing infrastructure.
How long does it take to deploy Hyperswitch?
Self-hosted deployment on AWS using CloudFormation takes approximately 30–45 minutes to provision the infrastructure. For teams that prefer a fully managed SaaS setup, typical onboarding from integration to go-live is two to three weeks. Hyperswitch also offers a fully hosted sandbox environment that requires no setup — configure connectors and test payments directly from the Control Center UI before committing to a production deployment.
Is Hyperswitch production-ready for US enterprise use?
Yes. Hyperswitch is the open-source version of payment infrastructure that Juspay has operated in production since 2012, processing 300 million daily transactions at 99.999% uptime across 150+ countries. It is PCI-certified, supports Apache 2.0 licensing for enterprise legal review, and is trusted by companies including Amazon, Google, HSBC, and Zurich Insurance. Juspay's San Mateo hub provides local US enterprise support.
What happens to card data when I self-host Hyperswitch?
When you self-host Hyperswitch on your own cloud, card data never leaves your environment. The Hyperswitch Vault stores network tokens, PSP tokens, and raw card credentials in a PCI-compliant vault that runs inside your own AWS, GCP, or Azure account. You control the encryption keys, the access policies, and the audit logs — directly answering what enterprise security teams ask most: "Can we verify how your system handles our card data?"
How does Hyperswitch handle payment routing decisions?
Hyperswitch supports three routing modes simultaneously: rule-based routing (business logic you define — card type, amount, geography); volume-based routing (traffic distribution across processors at configured percentages); and ML-driven routing (dynamic processor selection based on real-time authorization performance data). Engineering teams configure which mode takes priority for each transaction type through the no-code Control Center UI or directly via API.
What US payment methods and processors does Hyperswitch support?
Hyperswitch connects to 300+ payment processors and payment methods globally. For US merchants, this includes major card networks (Visa, Mastercard, Amex, Discover), digital wallets (Apple Pay, Google Pay), ACH and bank transfers, BNPL providers, and FedNow for real-time account-to-account payments. International connectors cover local payment methods across Europe, Asia-Pacific, Latin America, and the Middle East — all accessible through one unified API.
