What a Hyperswitch implementation involves
A Hyperswitch implementation means running an Apache 2.0 payments orchestration platform, maintained by Juspay, inside infrastructure your organization controls. The work is larger than installing a service. It covers the Router and Scheduler services (the Router is the Rust core app server that handles routing, retries, vaulting and observability), PostgreSQL with a master and replica setup, Redis for caching and the scheduler queue, the card vault, the encryption service for key management, the Control Center merchant dashboard, and the client SDKs your checkout pages and mobile apps call.
Most teams start this work for one of two reasons. The first is a planned move off a single processor integration or a hosted orchestrator, where you want to connect several processors and control routing yourself. The second is a decision to own routing logic and card data handling directly rather than delegating them to a vendor. Either trigger changes the scope. Once you hold card data, the card vault model, network isolation and PCI DSS scope become design inputs from the first sprint, not items to address before audit.
On delivery, most organizations keep product decisions and payments operations in-house. That includes which processors to connect, routing priorities, dispute handling and who approves changes to live traffic. Partners are more often used for the platform build and assessment preparation: Kubernetes environments, Helm-based deployment, database and Redis configuration, vault and key setup, and the evidence that supports a PCI DSS assessment. Confirm with any partner which of these items sit in their written scope and which remain with your payments and security teams.
What the work includes
An implementation runs as a set of connected workstreams, each with its own inputs, checks and handover. The cards below cover what is built and what you receive at the end.
Kubernetes environment build
Hyperswitch documents self-hosting with Helm charts on Kubernetes, with guides for Minikube, AWS, GCP and Azure. The work covers building the environments your chosen cloud or data center requires, applying those charts with your values, and separating dev, test and production. Confirm which Kubernetes distribution and cloud services your platform team supports before scoping.
Database and cache setup
Hyperswitch architecture uses PostgreSQL with a master and replica setup, and Redis for caching and the scheduler queue. This workstream provisions both, sets connection limits, backup schedules and access rules, and checks that the router and scheduler can reach them. Ask who owns database backup testing after handover.
Processor connector configuration
Hyperswitch lists more than 100 processors, but only the connectors in your agreed scope are configured and tested. Each connector needs credentials, webhook endpoints, currency and payment method settings, and sandbox test runs before production keys are used. The number of connectors in scope is one of the main drivers of effort.
Control Center setup
The Control Center is the merchant dashboard for connecting processors and managing payments, refunds and disputes. Setup covers deployment, first administrator access, user invitations and role design inside Hyperswitch. If you plan single sign-on, confirm early that it uses OpenID Connect, since SAML and SCIM are not supported.
Card vault model implementation
Hyperswitch documents three vault models: the native in-house vault, an external PCI vault provider, or the SaaS vault. The chosen model determines which systems are in PCI DSS scope and who carries responsibility for them. This workstream builds the chosen model, isolates the vault and records the reasoning for the assessor.
Routing baseline
Hyperswitch offers rule-based, volume-based, auth-rate, multi-objective, least cost and default fallback routing. A baseline sets an initial routing order, a fallback path for when no rule applies or a processor is ineligible, and test cases that prove the baseline behaves as written. Further routing tuning is a separate decision made once live data exists.
Observability setup
Payment operations need logs, metrics and alerts for the router, scheduler, database, cache and connector errors. This workstream connects the platform to your monitoring stack, defines alert thresholds with your operations team and documents what on-call staff should check first. Confirm which tools your organization has already approved.
Go-live support
Go-live support covers the window in which production traffic first reaches the platform. It includes a documented rollback plan, a named decision-maker for go or no-go, and a watch period agreed in advance. The length and staffing of that window should be written into the scope before work starts.
Deliverables you receive
Typical deliverables include deployed environments, configuration as code, runbooks for operations, test evidence and PCI DSS evidence packs prepared for an assessor. DeployOpen prepares this evidence but does not issue audit reports or attestations, so confirm with your assessor which artifacts they require in the written scope.
What drives cost and duration
This table lists the decisions that move implementation effort for a self-hosted Hyperswitch deployment, with why each one matters and how to keep it under control.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Number of processor connectors | Hyperswitch documents more than 100 processors, and each connector you enable needs credentials, configuration, routing eligibility and test transactions. The in-scope list sets the test matrix. | Agree the launch list of processors by name and volume before the build. Add the rest in later phases as separate, scoped change requests. |
| Wallet and SDK coverage | Apple Pay, Google Pay and other wallets each need domain setup and certificates. Client SDKs for web, Android, iOS, React Native and Flutter are separate integration and test tracks. | Limit launch to the channels you actually sell through. Confirm which SDK platforms your front ends use and defer the rest. |
| Vault model | The native in-house vault puts card data handling and PCI DSS responsibility on your team. An external PCI vault such as VGS or Tokenex, or the SaaS vault, changes which systems are in scope and what integration work is needed. | Decide the vault model in the first phase, before connector and network design. Ask the vault provider for its own PCI DSS evidence and responsibility matrix. |
| Number of environments and hosting target | Each environment needs its own Kubernetes deployment, PostgreSQL, Redis, secrets and network rules. Helm-based guides exist for local, AWS, GCP and Azure, but your target cloud or data center still needs its own build and hardening. | Use a single Helm chart and configuration baseline across environments. Keep the number of production-like environments to what your release process needs. |
| Superposition and other required configuration dependencies | The v1.124.0 release notes make Superposition a required dependency, and it must be running before upgrading to that version. Each extra service adds deployment, backup and monitoring work. | Confirm required services against the release notes for the version you deploy. Include them in the platform baseline from day one. |
| Identity integration for the Control Center | The Control Center supports OIDC single sign-on only. SAML is not supported, there is no JIT or SCIM provisioning, and roles are managed in Hyperswitch. Users must be invited, so access reviews are manual unless you add a process. | Agree the role model and the joiner, mover and leaver process before go-live. Confirm with your identity team how accounts will be invited and removed. |
| PCI DSS assessment scope and evidence work | Scope follows the vault model, network design and every system that touches card data. Evidence collection, control documentation and an assessor engagement are separate effort from the build, and DeployOpen prepares evidence but does not issue assessments. | Map the cardholder data environment early and limit it with network isolation and the chosen vault. Ask your assessor which evidence they expect and collect it during the build. |
| Number of internal reviewers | Payments, security, compliance, risk and operations staff each review routing, configuration, access and evidence. Slow or unavailable reviewers extend the schedule even when the build is on track. | Name reviewers and their decision rights in the plan. Book review windows at the start of each phase and agree what counts as sign-off. |
Project phases and outputs
The sequence moves from agreed scope and vault decision through a working non-production stack to a controlled production cutover with handover material.
Run discovery and scoping
DeployOpen works with your payments, risk, engineering and compliance leads to define the processors in scope, target markets, payment methods and the card vault model. The output is a signed scope document and a vault model decision that records who carries PCI DSS responsibility. The schedule is set in the written scope.
Design architecture and environments
The team maps Router, Scheduler, PostgreSQL with replica, Redis, the card vault and the encryption service to your Kubernetes clusters, network zones and cloud accounts. The output is an architecture decision record covering isolation, ingress, secrets and the environments to be built, reviewed and approved by your architecture owner.
Build non-production environments with Helm
DeployOpen deploys Hyperswitch on Kubernetes using the documented Helm charts into the development and test environments you control, with configuration versioned in your repositories. The step closes when the components start, connect to the database and cache, and pass basic health checks, with the deployed environments handed to your team.
Configure connectors and routing baseline
The agreed processors are connected in the sandbox, with a baseline routing configuration covering default fallback order and the first rule set. Your team confirms credentials are held in your secrets store. The output is a connector and routing configuration record that shows which processor handles which payment flow.
Complete security and PCI DSS readiness work
DeployOpen hardens the environments, documents network segmentation, key management, logging and access controls, and prepares the evidence your assessor will ask for. The assessment itself is performed by a qualified assessor, not by DeployOpen. The output is a readiness pack mapped to the relevant requirements and a list of open gaps with owners.
Test in sandbox and controlled live traffic
The team runs functional, failover and routing tests in the sandbox, then enables controlled live traffic for a limited set of flows agreed in scope. Results are recorded as test evidence with defects tracked to closure. The step closes when your payments owner signs off on the results.
Prepare cutover readiness and handover
DeployOpen drafts cutover and rollback steps, validates monitoring and alerting, and delivers runbooks for operations, upgrades and incident response. The step closes with a go or no-go review and a documented handover to your operations team, with support terms as set out in the written scope.
What teams keep in-house and what they outsource
This table maps each part of a Hyperswitch rollout to the team that usually owns it, the skills it needs, and whether a partner, the client, or both supply those skills.
| Work area | Skills needed | Who usually supplies them |
|---|---|---|
| Payments product and processor relationships | Payments domain knowledge, processor contract terms, connector credentials, onboarding timelines with each processor | Client keeps this; partner can advise on connector configuration and test plans |
| Risk and fraud rules | Fraud policy design, rule thresholds, chargeback and dispute handling, familiarity with routing decisions that affect approval rates | Client keeps this; partner helps encode rules in Hyperswitch routing configuration |
| Finance and reconciliation owners | Settlement review, reconciliation mapping across processors, ledger and close processes | Client keeps this; partner supplies reconciliation module setup and data mapping |
| Platform engineering for Kubernetes and PostgreSQL | Kubernetes operations, Helm deployment, PostgreSQL administration with primary and replica, Redis operations, backup and restore | Both share this; partner builds the initial deployment and client team takes over operations |
| Customization of connectors and routing logic | Rust or payments domain knowledge for connector and core changes, testing against upstream releases | Both share this; partner usually builds custom connectors, client reviews and maintains them |
| Control Center administration | Control Center user and role management, OIDC single sign-on configuration, API key handling | Client keeps this day to day; partner usually configures the initial single sign-on setup |
| Security engineering | Network isolation, secrets handling, TLS, logging controls, key management for the encryption service | Both share this; partner hardens and tests, client owns policy and ongoing monitoring |
| QSA or internal assessor relationship | PCI DSS scoping, evidence collection for the chosen vault model, assessor communication | Client keeps this; partner prepares systems, controls and evidence but does not issue assessment results |
What usually goes wrong
Most Hyperswitch delays and budget overruns trace back to a short list of decisions made late or assumed too early. Each risk below comes with a check to run before the build reaches that point.
Choosing the vault model late
The vault model decides which systems fall into PCI DSS scope, so a late change reopens network design, hosting and assessment plans. Fix the vault model in the planning phase, before infrastructure is provisioned, and record who carries PCI DSS responsibility for each option you evaluated.
Underestimating connector and onboarding time
Each processor integration needs certification, test credentials and merchant account approval that run on the processor's schedule, not yours. Ask each processor for its onboarding steps and lead times in writing, and start those requests in parallel with the platform build rather than after it.
Missing the Superposition dependency
Hyperswitch v1.124.0 made Superposition a required configuration dependency, and deployments need a running Superposition service before upgrading to that version. Add it to the environment inventory and Helm values from the first build, and confirm it is present in every environment, including upgrade rehearsal copies.
Treating the in-house vault as a checkbox
The Hyperswitch docs state that in the self-hosted, in-house PCI model the merchant is fully responsible for PCI DSS certification and data handling. Budget for key management, access reviews, logging and assessor time as ongoing work, and confirm with your assessor which controls apply before selecting this model.
Assuming SAML or SCIM for Control Center
The Control Center supports OpenID Connect only, with no SAML, no JIT or SCIM provisioning, and roles managed inside Hyperswitch. Plan an invitation and role assignment process for administrators, and map who approves each role before go-live rather than expecting directory groups to drive access.
Running one production environment with no staging
Without a staging environment, routing changes, connector updates and monthly upgrades reach live payment traffic untested. Provision a non-production environment that mirrors the production Kubernetes and database layout, and use it to rehearse each upgrade before the production change window.
Under-resourcing payments and security reviewers
Internal payments and security staff are needed for connector review, routing decisions, vault controls and assessment evidence, and that time is often unbudgeted. Name the individuals and their weekly hours for each phase in the plan, and ask any implementation partner to show which of those tasks it will carry and which remain with your team.
How the work changes by starting point
You are standing up Hyperswitch with no existing Kubernetes platform or PostgreSQL service to reuse. Most of the effort sits in the platform itself, so the plan starts with infrastructure decisions before any connector work.
- Platform build: choose a Kubernetes distribution, cluster topology and the Helm chart path for your cloud or data center, then harden it before payment workloads arrive.
- Data layer: design PostgreSQL with a primary and replica, plus Redis for caching and the scheduler queue, and set backup and recovery expectations early.
- Identity and access: the platform team, security team and payments owners agree on how Control Center users are invited and which roles they hold.
- Who is involved: a platform team builds the foundation, while payments and security owners join once the environment is reachable.
- Confirm with the vendor: the supported chart and component versions for your target release before you lock the cluster design.
You already run a Kubernetes platform and a PostgreSQL service that the organization supports. The work shifts from building infrastructure to fitting Hyperswitch into standards that already exist, which can shorten some phases and add coordination in others.
- Fit assessment: compare your cluster policies, ingress, secrets tooling and node pools against the Helm deployment Hyperswitch expects.
- Database decisions: confirm whether a dedicated PostgreSQL cluster or a shared service with separate databases and roles is acceptable for payment data.
- Change control: existing platform teams will want the Hyperswitch namespaces, network policies and upgrade process to follow their release gates.
- Who is involved: the existing platform and database teams own the shared services, and DeployOpen works through their change process.
- Effort driver: the number of existing policies that must be adapted, not the Hyperswitch install itself.
Your Hyperswitch environment cannot pull images, charts or dependencies directly from the public internet. Image and chart delivery becomes a planned workstream that runs before and alongside the build.
- Artifact pipeline: mirror container images, Helm charts and any build dependencies into an internal registry, and record exactly which versions were approved.
- Upgrade path: each monthly release must go through the same mirroring and approval step, so plan that cycle as a recurring task.
- Connectivity to processors: outbound access to payment processors and any external vault is often the hardest approval, so raise it with the network team early.
- Who is involved: the network, security and artifact management teams carry much of the early work, with the payments team waiting on their approvals.
- Confirm with the vendor: which components need outbound access at runtime, so the allowlist is based on facts.
Your organization must keep cardholder data in an external PCI vault provider, so the Hyperswitch build integrates with that vault rather than storing card data in its own vault. Scope and responsibility decisions come before the technical design is final.
- Vault boundary: define which data flows to the external vault, which tokens return to Hyperswitch and which systems never see raw card numbers.
- Assessment scope: the PCI DSS assessment depends on how the external vault and your environment divide responsibilities, so involve your assessor early.
- Security reviews: network segmentation, logging and access reviews for the systems that touch vault interfaces need stronger evidence than a standard build.
- Who is involved: payments, security, compliance and the vault provider each hold a part of the design, which makes governance the main coordination task.
- Out of scope here: migrating any stored card tokens, which is covered in the migration topic.
What you need to provide
Before we can scope a Hyperswitch implementation, the client needs to supply the inputs that determine the plan. The most important are access to the target environments: the cloud accounts, data centers or Kubernetes clusters where Hyperswitch will run, with a named platform owner who can approve network, storage and cluster changes. Without that person, the first weeks of the engagement tend to go to finding out who controls the environment.
On the payments side, provide the processor list with the contracts or agreements in force, and sandbox credentials for each processor you plan to connect. Also state the target payment methods and markets, since these set the connector and wallet work. Record the vault model decision early, and if you intend to use an external PCI vault provider such as VGS or Tokenex, provide that contract so its onboarding steps and data flows can be planned against it.
Provide details of your identity provider for OIDC sign-in to the Control Center. Hyperswitch supports OpenID Connect only, not SAML, and does not provision users automatically, so confirm the OIDC client details and who will invite and manage users. For PCI DSS scoping, prepare network diagrams, data flow diagrams and a list of systems that touch cardholder data. Named owners are needed from payments operations, risk, finance and security, along with the person who holds approval authority for production changes.
Decisions and accountability stay with the client. The partner executes against the agreed scope, but the client decides on processors, routing priorities, vault model and go-live approval. Confirm these owners and approvers in writing before scoping starts, because unassigned decisions are the most common reason a fixed-scope plan slips.
Frequently asked questions
How is the cost of a Hyperswitch implementation structured?
The cost has three main parts: DeployOpen's fee for the agreed fixed-scope work, your infrastructure, and your internal people time. Infrastructure includes Kubernetes clusters, PostgreSQL with a primary and replica, Redis and storage, and each is paid to its own provider, so ask for those as separate lines. Setup work is one-time, while hosting, monitoring, upgrades and support recur. DeployOpen does not publish a price list. Ask the quote to itemize each connector, the vault model, each environment, and which items are one-time versus recurring.
What drives the effort of a Hyperswitch implementation up or down?
The biggest drivers are the number of processor connectors, the card vault model, and the number of Kubernetes environments you run. Each connector needs credentials, field mapping, test transactions and error handling, so every added processor adds work. The vault choice decides whether you use the native Hyperswitch Vault, an external PCI vault such as VGS or Tokenex, or the SaaS vault, and that changes both build and assessment effort. Routing rules, Control Center single sign-on, reconciliation and any custom code add further effort on top of those.
How long does a Hyperswitch implementation take to deliver?
Duration depends on the scope, and no single timeline fits every deployment. The schedule follows the connector count, the vault model, the number of environments, integration with your order and ledger systems, and how quickly your teams review test results and approve changes. Ask for a proposal that shows phases, dependencies, internal review points and the assumptions behind each date. Minor Hyperswitch releases ship roughly monthly, so confirm which version the plan targets and when it will be frozen. Any PCI DSS assessment runs on its own calendar and should be planned in parallel.
Can an internal team implement Hyperswitch on its own?
Often yes, if the team already runs Kubernetes, PostgreSQL and Redis in production, but the work needs several skill areas. Plan for Rust and service engineering to read and change the core app server, Kubernetes and Helm operations, database administration for a primary and replica setup, payments domain knowledge for connectors and reconciliation, and identity administration for OIDC single sign-on. Security engineers must own network isolation and key handling for the card vault. Confirm internal capacity in writing before committing, because the same people also carry monthly upgrades and new dependencies such as Superposition, required since v1.124.0.
What must our team provide before a Hyperswitch engagement starts?
Your team provides the access, decisions and people the plan depends on. That includes cloud or data center accounts, Kubernetes cluster access, decisions on PostgreSQL and Redis hosting, and sandbox or live processor credentials for each connector you plan to add. You also need a named product owner, a payments operations contact, a security contact for the card vault and key management, and an identity owner for single sign-on. Provide processor contracts, routing preferences, the sources of stored card tokens, and your change approval process. Gaps in these inputs usually move dates, so list them in the written scope.
Is Hyperswitch PCI DSS certified, and can DeployOpen issue audit reports?
No, Hyperswitch is not PCI DSS certified, and DeployOpen does not issue audit reports, attestations or certifications. The assessment applies to your environment, which includes the systems, networks and data flows you run around Hyperswitch. The Hyperswitch docs state that in the self-hosted, in-house PCI model the merchant is fully responsible for PCI DSS certification and data handling. An external PCI vault or the SaaS vault changes that split, so confirm it in writing with your provider and assessor. DeployOpen prepares systems, controls and evidence for the assessment, and an independent assessor makes the determination.
How DeployOpen scopes and delivers this work
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Hyperswitch, that means turning connector count, vault model and Kubernetes environments into a written plan before any build starts.
How we scope
- Confirm which processors and wallets are in the first connector set, and which are planned later.
- Choose the card vault model with you, since it sets who carries PCI DSS responsibility and what is in scope.
- Record environments, hosting targets and Kubernetes distribution so the plan matches where Hyperswitch will run.
- Agree the written scope, deliverables and timelines before work starts. Engagements are fixed-scope.
How we build
- Deploy Hyperswitch with Helm charts on Kubernetes in your environments, with PostgreSQL and Redis configured for your targets.
- Configure connectors, Control Center access and routing strategies in line with the agreed scope.
- Test payment flows, routing changes and failover in non-production environments before any live traffic.
- Document the configuration, network boundaries and evidence your assessors and internal teams will need.
How we hand over
- Deliver runbooks for deployment, upgrades, backups, key handling and incident response, written for your team.
- Walk your payments, platform and security staff through the environments and the operating model.
- Provide the scope record, configuration baseline and PCI DSS readiness evidence agreed in the written scope.
- Confirm with your QSA or assessor which evidence they need. DeployOpen prepares evidence but does not issue attestations.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after go-live.
- Plan monthly Hyperswitch minor release reviews, including the compatibility matrix for Control Center and SDK versions.
- Check each release for new required dependencies before upgrading, such as Superposition service requirements.
- Ask any support provider to state response scope, change control and who owns the upgrade calendar in writing.
