What does Hyperswitch cost of ownership include once you self-host it?
Hyperswitch is licensed under Apache 2.0, so the software itself carries no license fee. Cost of ownership comes from everything around it: the infrastructure it runs on, the card vault model you choose, PCI DSS responsibility, monitoring, monthly upgrades and the people who operate the platform. Payments and finance leaders usually ask this question for one of three reasons. They are choosing self-hosting over a hosted orchestrator, they are budgeting for a new payments platform, or they are comparing Juspay's hosted options with running the open-source stack in their own environment. Each trigger leads to the same starting point: a list of one-time and recurring costs that can be priced against a written scope.
The one-time costs cluster around the build. They include architecture decisions, environment setup for the Router, Scheduler, PostgreSQL primary and replica and Redis, connector integration for each processor, vault and PCI scope work, and team training. The recurring costs are the ones that persist after go-live: cloud or data center capacity, monitoring and alerting tooling, on-call coverage, the upgrade effort that follows each monthly minor release, and the annual cycle of PCI DSS evidence collection. Confirm with your own engineering team which of these already exist in your environment, because duplicated tooling is a common hidden cost in a new platform budget.
The vault model changes the cost structure more than any other single choice. The Hyperswitch docs state that with the self-hosted, in-house PCI model, the merchant is fully responsible for PCI DSS certification and data handling, so assessment effort, control operation and staff time recur for as long as the vault runs. An external PCI vault provider or the SaaS Hyperswitch Vault shifts part of that scope, but each carries its own contract terms and fees. Ask every vendor in writing which systems fall in your PCI DSS scope under their model and which controls remain your responsibility, then price those controls separately.
Most teams model the cost in-house first, using their own infrastructure and staffing figures, then bring in a partner once the vault model, connector count and target environments are settled. A partner can build the cost model from a written scope, which is how DeployOpen prepares its quotes, since it does not publish a price list. Ask for line items that separate one-time and recurring costs, the infrastructure assumptions behind each figure, the expected upgrade effort per release, the cost of running any required dependency such as Superposition, and the boundary of PCI DSS assistance. Request Juspay's hosted pricing in writing so the comparison uses the same assumptions.
What a Hyperswitch cost-of-ownership study covers
A cost-of-ownership study turns a self-hosted Hyperswitch deployment into a set of costs you can compare against a hosted option. Each component below produces a document you keep, and each is scoped in writing before work starts so that the assumptions behind the numbers are visible.
Cost model in one-time and recurring lines
The cost model separates one-time items, such as planning, connector setup, vault decisions and initial PCI DSS preparation, from recurring items, such as cloud infrastructure, database and cache operation, monitoring, upgrades and staff time. Each line names who is paid for the work, whether that is your team, a partner or a vendor. The deliverable is a cost worksheet with an assumptions log, so you can change one input and see its effect on the totals.
Vault model decision and PCI DSS consequences
Hyperswitch documents three self-hosted vault models: the native in-house vault, self-hosted orchestration with an external PCI vault provider such as VGS or Tokenex, and self-hosted orchestration with the SaaS Hyperswitch Vault. The study records which model you choose and what it means for your PCI DSS scope and assessment effort. Under the in-house model, the Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling, so that cost sits on your side of the ledger. The deliverable is a vault decision record with a responsibility split.
Kubernetes and database sizing view
Hyperswitch documents Helm-based deployment on Kubernetes, with router and scheduler services backed by PostgreSQL with a master and replica setup and by Redis. The sizing view estimates node pools, database capacity, cache capacity and environment count for development, staging and production, and lists the inputs that move each figure, such as transaction volume and connector count. Ask for the sizing inputs to be written down so the infrastructure line can be re-run when volumes change. The deliverable is a sizing sheet tied to the cost worksheet.
Upgrade and dependency calendar
Hyperswitch ships roughly monthly minor releases, and each release has a compatibility matrix for Control Center and web client versions. Some releases add required dependencies: v1.124.0 made Superposition a required configuration dependency, and deployments must run a Superposition service before upgrading to that version. The calendar maps each expected release, its dependency changes and the test and change-window effort it implies. The deliverable is an upgrade calendar with a dependency register, which is the main driver of the recurring engineering line.
Staffing and responsibility model
Running Hyperswitch in production spreads work across platform engineering, payments operations, security and compliance, and vendor or partner support. The staffing model names which roles cover on-call, connector maintenance, routing changes, vault and key management, and PCI DSS evidence collection, and estimates the time each role needs to budget. Confirm with your own HR and finance teams how internal time is costed, because that choice changes the total. The deliverable is a responsibility matrix with a staffing table for the recurring cost model.
Which factors move Hyperswitch running costs up or down
This table lists the drivers that change the cost model of a self-hosted Hyperswitch deployment, with why each one matters and one practical way to keep it under control. Read it as a checklist to bring into a quote, since most rows change both infrastructure and the people time needed to run the platform.
| Driver | Why it moves cost | How to keep it down |
|---|---|---|
| Connectors and processors | Hyperswitch connects to more than 100 processors, and each live connector adds configuration, certification testing, reconciliation mapping and monitoring work. | Enable only the processors you route to today and add others as a planned, tested change request. |
| Transaction volume | Higher volume raises compute for the Router and Scheduler, database write load and log and metric storage, and it makes failover capacity more expensive to hold. | Size from measured peak traffic in a staging load test and set autoscaling limits instead of permanent headroom. |
| Vault model | An in-house PCI vault puts card data storage, key management and assessment effort inside your environment, while an external or SaaS vault shifts part of that work to a provider. | Compare the three documented vault models against your PCI DSS scope before choosing, and ask each provider for its responsibility matrix. |
| Kubernetes environments | Each extra environment (development, test, staging, production, disaster recovery) repeats clusters, Helm releases, secrets and monitoring, and each one needs patching. | Keep non-production environments smaller and share platform tooling, but keep staging close to production in configuration. |
| PostgreSQL primary and replica | The primary and replica pair, storage, backups and restore testing are recurring infrastructure costs, and replica sizing grows with reporting queries. | Confirm the managed or self-run database tier with your team and route reporting reads to the replica rather than scaling the primary. |
| Redis footprint | Redis serves caching and the scheduler queue, so memory size, persistence settings and node count affect both cost and failover behavior. | Size memory from measured key counts and review eviction and persistence settings with the platform team before production. |
| Control Center users and identity integration | Users must be invited first, roles are managed in Hyperswitch, and SAML and SCIM are not supported, so onboarding and offboarding stay partly manual. | Keep the user list small, use a named role model and document a monthly access review owned by one person. |
| PCI DSS scope | Every system that stores, processes or transmits card data or could affect its security adds assessment, logging and hardening work, and scope grows with each integration. | Restrict card data flows to the vault and tokenized paths, and confirm scope boundaries with your qualified assessor early. |
| Monthly release cadence | Hyperswitch ships roughly monthly minor releases, and some versions add required dependencies such as Superposition, so each upgrade needs testing, compatibility checks and staff time. | Set a fixed upgrade window, skip versions deliberately with a tested plan and check the compatibility matrix for Control Center and SDKs before each change. |
Which Hyperswitch costs are one-time and which recur
The most useful way to compare self-hosted Hyperswitch with a hosted option is to split every cost into two groups before looking at any totals: one-time spend that is incurred to get to a working, compliant deployment, and recurring spend that continues for as long as payments run on the platform. Ask for both groups on every quote. A single combined number hides the difference between a large first-year bill and a steady annual run rate, and a multi-year comparison depends on that difference. One-time spend covers the work that happens before and around the first live transaction. That includes requirements gathering, architecture decisions such as the number of processors to integrate and the card vault model, the initial deployment onto Kubernetes using the Helm charts, connector setup for each processor, the selection of a vault option, and the first PCI DSS scoping exercise that defines which systems touch cardholder data. It also includes staff training for the people who will run the Router, Scheduler, PostgreSQL, Redis and the Control Center. If you plan to upgrade to v1.124.0 or later, the Superposition service must be running before that upgrade, so standing it up is a one-time item on the path to that version.
Recurring spend starts once the platform is live and does not stop. Cloud hosting for the application tiers, the database and the cache is billed continuously, and the database and cache need ongoing operation, including backups, patching and capacity changes. Monitoring and alerting on payment flows are a standing cost. Hyperswitch ships roughly monthly minor releases, so monthly upgrade testing against the compatibility matrix for the Control Center and client SDKs recurs as well. Your PCI DSS maintenance is recurring, since the assessment cycle, evidence collection and control upkeep repeat each year, and the in-house model places that work on your team. Staff time to operate the platform and respond to incidents is the largest recurring line for most teams, and it should be estimated in hours per month, not left as a general allowance.
Some costs move between the two groups depending on the vault decision. Choosing the native Hyperswitch Vault shifts more PCI DSS work, and its recurring maintenance, onto your team, while an external PCI vault provider or the SaaS vault carries fees that recur as a service charge. Ask each quote to state the vault fee, if any, as a recurring line, and to name which PCI DSS responsibilities remain with you under that model. The same applies to any support retainer: confirm whether it is a fixed monthly charge, what it covers after go-live, and whether upgrade testing is included or billed separately. When you receive quotes, ask the provider to show the one-time items and the recurring items as separate totals, with the recurring total stated per month or per year and the assumed contract length. Ask which items are fixed in the written scope and which are estimates that change with connector count or environment count. Compare the two groups across the same number of years for each option. Where a figure is not in the quote, ask for it in writing rather than inferring it. Any cost you cannot place in one of the two groups is a question to resolve before you sign.
How the vault model changes the cost of ownership
In this model, your team runs the card vault (locker) inside your own infrastructure, alongside the rest of the Hyperswitch stack. The Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling, so most card data costs stay with you. Vendor fees for a vault do not apply, but internal effort carries the work.
- PCI DSS assessment effort grows because the vault, its database, key management and the network paths around them all fall inside your assessed environment.
- Card data environment hosting grows through isolated networks, dedicated nodes and separate hardening for the vault service and its encryption path.
- Key management grows because you own key generation, storage, rotation and custodian procedures.
- Internal security staffing grows with log review, access reviews, patching and evidence collection handled by your own team.
Before you price this model, ask your assessor and payments team to list every system that stores, processes or transmits card data, including the vault, backups and administrative access paths.
Here, Hyperswitch orchestration stays self-hosted, but card data is tokenized into an external PCI vault such as VGS or Tokenex. Costs move from hosting and key custody toward vendor fees and integration work. How far your scope shrinks depends on the provider's responsibility arrangement, so the provider's terms define much of the result.
- Vendor fees appear as a recurring line item. Ask the provider for pricing basis, volume tiers and minimums in writing.
- PCI DSS assessment effort can shrink for your environment, but only for requirements the provider's responsibility documentation covers. Confirm which requirements stay with you.
- Card data environment hosting shrinks for the vault itself, while the orchestrator still handles tokens and must be scoped correctly.
- Key management for card data moves largely to the provider, but you still own keys for your own encryption service and application secrets.
- Internal security staffing shifts toward vendor management, integration testing and annual review of the provider's compliance evidence.
Ask the provider for its current compliance evidence and fee schedule, then have your assessor confirm the scope reduction against the provider's documented responsibilities. Confirm all fee terms directly with the vault provider.
In this model, orchestration runs in your environment while card data is held in the Hyperswitch SaaS vault. Hosting and key custody for card data move to the service, and recurring vendor fees take their place. The split of PCI DSS responsibility for this option should be confirmed with Juspay in writing, because the public docs leave details to the service terms.
- Vendor fees for the hosted vault are recurring. Confirm the billable unit, the pricing basis and any minimums with Juspay before comparing the figure to the other models.
- Card data environment hosting shrinks inside your network, but the connection from your orchestrator to the hosted vault becomes part of your scope analysis.
- PCI DSS assessment effort depends on the evidence provided. Request the current responsibility matrix and assessment documentation for the service.
- Key management for card data sits with the hosted service. Confirm how key custody, rotation and access logging are performed and reported to you.
- Internal security staffing shifts toward vendor oversight, controls on the outbound path to the vault and review of service changes that affect your scope.
Request the written responsibility matrix and service terms from Juspay so you can compare this line with the other two models on the same basis.
How self-hosted Apache 2.0 compares with Juspay's hosted options
The Hyperswitch core, the card vault, the encryption service, the Control Center dashboard and the client SDKs for web, Android, iOS, React Native and Flutter are all in public repositories under the Apache 2.0 license. The license fee for these components is zero, but the cost of ownership is not. Apache 2.0 lets you run, modify and distribute the code without paying a license fee. It does not cover the cloud infrastructure, the engineers who operate the platform, the PCI DSS assessment, or any support contract you choose to buy. Treat the license as the starting point of the comparison, and price the operating work that sits on top of it.
Juspay also offers hosted options, and you should ask about them before you compare totals. The two to raise are the SaaS Hyperswitch Vault, which can be used with self-hosted orchestration, and a hosted sandbox for testing. The sandbox suits evaluation, connector testing and integration work before production, but it does not replace your own production environment. The public documentation does not settle which hosted services are available to you, what support levels come with them, or what commercial terms apply. Confirm each of these with Juspay directly, and ask for the terms in writing before you put them next to your internal cost estimate.
A hosted component moves part of the work to another party, and the boundary between the two parties must be written down. In the self-hosted, in-house PCI model, the Hyperswitch documentation states that the merchant is fully responsible for PCI DSS certification and data handling. If card data is held in the SaaS Hyperswitch Vault instead, your cardholder data environment may shrink, but your obligations do not disappear. Your orchestration layer still handles tokens, your systems still sit in scope for parts of the assessment, and your assessor will still need evidence. Map each PCI DSS requirement to one of three owners: you, Juspay, or shared. Do this before the vault decision is final, because the mapping sets the assessment effort you will need to fund.
Put these questions to Juspay in writing and file the answers with your vendor records. (1) Which hosted services are available to us, and which of them work with self-hosted orchestration? (2) What support levels are offered, and what response expectations are written into the agreement? (3) Which PCI DSS responsibilities does the provider accept, and what attestation or evidence will it supply for the hosted vault? (4) Where is card data stored and processed, and which regions are covered? (5) What are the commercial terms, including term length, how usage is measured, renewal conditions and exit terms? (6) Does the hosted sandbox have limits that would affect connector testing or integration work?
When the answers arrive, compare them against your internal cost lines: infrastructure, monitoring and on-call coverage, the people who carry upgrades, and the PCI DSS assessment. Ask any implementation partner to show which of these lines a hosted component removes and which ones stay with your team. An illustrative example: a team that moves card storage to a hosted vault may still fund the same assessment, with a narrower scope, and still needs its own on-call rota for the orchestration layer. Keep the assessment line in your budget until your assessor confirms the new scope in writing.
Which recurring costs to model after go-live
This table lists the costs that continue after a self-hosted Hyperswitch deployment goes live, showing who typically pays for each line and what to request in a quote. Read it as a checklist for a monthly or annual model, then confirm each figure with your cloud provider, vendors and partner.
| Recurring cost line | Who pays and how | What to ask for in a quote |
|---|---|---|
| Hosting for router and scheduler replicas | The client pays the cloud or data center provider for Kubernetes nodes running Router and Scheduler Producer and Consumer replicas | Node counts per environment, replica sizing assumptions, and whether non-production and sandbox clusters are priced separately |
| PostgreSQL primary and replica operation | The client pays the database service or infrastructure; a partner may charge for tuning and recovery support | Managed or self-run split, storage growth assumptions, backup retention, and who performs failover tests |
| Redis for caching and the scheduler queue | The client pays the hosting cost; the partner or client engineers handle upgrades and capacity changes | Instance sizing, memory growth driven by queue depth, and the expected effort for version updates |
| Observability tooling | The client pays the monitoring, logging and tracing vendors or runs open-source stacks on its own infrastructure | Log and metric volume assumptions, retention periods, and which dashboards and alerts are included |
| Monthly minor release testing | The client's internal team or a partner performs the work; there is no vendor fee for the open-source release itself | Effort per release, test environment needs, and how the Control Center and web client compatibility matrix is checked before each upgrade |
| Dependency upkeep, including Superposition | The client pays for hosting and operating the Superposition service that v1.124.0 requires; the partner may charge for upgrade work | Confirm which Superposition version each Hyperswitch release needs and who applies database migrations |
| PCI DSS assessment cycles | The client pays a qualified assessor and any scanning vendor; a partner may prepare evidence for the assessment | Assessor scope and fee basis, whether the chosen vault model keeps card data in scope, and how annual and change-driven reviews are handled |
| Vault or hosted service fees, if chosen | The client pays an external PCI vault provider such as VGS or Tokenex, or Juspay for the SaaS Hyperswitch Vault | Per-transaction or per-token pricing, minimum commitments, and contract term and renewal conditions |
| Partner retainer or support, if chosen | The client pays the partner for ongoing support, upgrades and continuous testing under a written retainer | Response coverage, included upgrade cycles, change limits, and what is billed separately |
| Internal staff time for on-call and connector changes | The client pays its own payments, platform and security staff; this time is often the largest unbudgeted line | Estimated on-call rota size, connector change frequency, and the skills each role needs to cover |
Where Hyperswitch cost estimates usually go wrong
Self-hosting Hyperswitch removes the software license cost, but the work around the platform still has to be budgeted in full. The six gaps below are the ones that most often make first estimates too low. Each card names a check to run before the budget is approved.
The license is not the cost
Hyperswitch and the Control Center are both licensed under Apache 2.0, so there is no software fee to pay for using them. The cost sits in Kubernetes environments, PostgreSQL and Redis, the card vault, monitoring, PCI DSS assessment and the people who run and upgrade the platform. Prevention: build the estimate as a list of one-time and recurring components, with a named owner for each, before comparing it with any hosted option.
Upgrade effort from frequent releases
Hyperswitch ships roughly monthly minor releases. The GitHub releases page lists v1.126.0, v1.127.0 and v1.128.0, each with a compatibility matrix for Control Center and web client versions. Every upgrade needs a staging test, a database migration review and a check of SDK and dashboard versions. Prevention: reserve recurring upgrade time each month, pin the versions you run and ask any partner to quote upgrades as a recurring line item.
Superposition missed in upgrade plans
From v1.124.0 onward, Superposition is a required configuration dependency, and the release notes state that a Superposition service must be running before you upgrade. Teams that plan only for the router and scheduler tend to find this during a change window. Prevention: count Superposition in the architecture, hosting, monitoring and on-call scope, and confirm its requirements in the v1.124.0 release notes before scheduling any upgrade.
Identity work assumed to shrink
The Control Center supports single sign-on through OpenID Connect only. SAML is not supported, there is no JIT or SCIM provisioning, and roles are managed in Hyperswitch and not mapped from the identity provider. Every user must be invited first, so joiner, mover and leaver work stays manual. Prevention: budget time for invitations and role changes, and document an offboarding step that removes Control Center access.
PCI scope growing through logs
PCI DSS scope can grow through application logs, error traces, connector integrations, dashboards and support tooling that touch card data. In the self-hosted, in-house PCI model, the Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling. Prevention: map every data flow before go-live, keep card data out of logs, limit integrations to tokens and confirm the scope with your assessor before pricing the assessment.
Staff time budgeted at zero
Internal payments, security and platform staff spend time on connector onboarding, routing changes, reconciliation checks, PCI evidence collection, upgrades and incident response. When that time is not written into the plan, the project looks cheaper than it will run. Prevention: name the roles, the recurring activities and the expected hours, and ask any quote to show which of these it includes and which remain with your team.
What to provide so a Hyperswitch cost model is accurate
A Hyperswitch cost model is only as good as the inputs behind it. Before a quote is written, the client should provide an expected annual payment volume, the average and peak transaction rates, and the split between card, wallet and alternative payment traffic. These numbers drive the size of the Router and Scheduler replicas, the PostgreSQL primary and replica sizing, the Redis capacity for caching and the scheduler queue, and the number of Kubernetes nodes needed in each environment. Ask for peak figures as well as averages, and state the period they cover, because a quote built on averages will understate the infrastructure needed to absorb a busy day.
Next, list the processors and wallets to be connected in the first release, along with the ones planned for later. Hyperswitch documents connectors to more than 100 payment processors and wallets such as Apple Pay and Google Pay, but each connector still needs credentials, certification testing and ongoing maintenance. Name the processors already under contract, any that are in negotiation, and the markets and currencies each one serves. Also confirm whether any existing processor integration will remain in place during the transition, because running parallel paths adds environments and testing effort that belong in the model.
The vault decision changes the cost model more than any other input. Tell DeployOpen whether the organization has chosen, or is shortlisting, the native Hyperswitch Vault with in-house PCI controls, an external PCI vault provider such as VGS or Tokenex, or the SaaS Hyperswitch Vault. Each option changes who carries PCI DSS responsibility, which systems fall in scope and how large the assessment effort will be. Also state the current PCI DSS status, the date and scope of the most recent assessment if one exists, and whether there is an existing relationship with a Qualified Security Assessor. If no assessor relationship exists, say so, because the quote should show that selection as a separate item rather than assume one.
Identity and ownership details shape both the setup effort and the ongoing run cost. Provide the identity provider in use, confirm that it supports OpenID Connect, and note that the Control Center does not support SAML, JIT or SCIM provisioning, so user invitation and Hyperswitch role management will be manual work. Name an internal owner for payments operations and a separate owner for security, with authority to approve changes to routing, vault configuration and access. Finally, describe the hosting standards the organization already runs, including the Kubernetes distribution, cloud accounts or data centers, secrets management, logging and network controls, so that the quote reuses existing platforms instead of pricing new ones.
Any input that is unknown should appear in the quote as a stated assumption, with its effect on cost described. For example, if peak rates are not confirmed, the quote can assume a sizing band and show how the infrastructure line changes once the figure is known. Silent gaps lead to estimates that look precise but fail during budgeting or assessment. Ask DeployOpen to list every assumption, mark which ones the client must confirm before signing, and agree on the date each open item will be closed. This keeps the cost of ownership honest from the first quote through the first year of operation.
Questions buyers ask about Hyperswitch cost of ownership
Does an Apache 2.0 license mean Hyperswitch is free to run?
No license fee applies to the software itself, but running Hyperswitch in production carries other costs. Apache 2.0 lets you use, modify and deploy the code without paying a license fee to the project. The costs that remain are the ones any self-hosted payments stack carries: cloud or data center infrastructure for the router, scheduler, PostgreSQL, Redis and the card vault; staff time to operate and monitor the platform; the PCI DSS assessment and the controls that support it; and upgrades, testing and dependency maintenance. Ask any quote to show these as separate lines so the license line reads zero and the operating lines are visible to your finance team.
How long does a Hyperswitch cost study take?
The timeline depends on how much of your current payments estate must be inventoried: the connectors you need, payment volumes by processor and region, the vault model you are considering, and the Kubernetes and cloud environments you will use. No duration applies in general, so request a timeline in the written scope. A good scope lists the phases, the inputs you must supply, the review points and the date each deliverable is due. Most engagements are fixed-scope, which means scope, deliverables and timelines are agreed in writing before work starts. If a partner gives you a duration before asking about these inputs, ask what that estimate assumes.
Can our finance and payments team model Hyperswitch costs without outside help?
Yes, an internal team with payments, platform and finance knowledge can build a model. The structure matters most. Split every line into one-time costs, such as design, build, connector setup, migration and the first round of PCI DSS assessment preparation, and recurring costs, such as infrastructure, staff, assessments, upgrades and any paid components. Then model the vault decision separately. The native in-house vault, an external PCI vault provider and the SaaS vault place different systems and responsibilities in your PCI DSS scope, so compare them against the same volumes and processor list. Outside help is most useful for checking assumptions and reviewing the model.
What does our team need to provide for a Hyperswitch cost assessment?
Prepare these inputs before the scoping conversation:
- Payment volumes by processor, region, payment method and currency
- The list of processors, wallets and connectors you need now and in the next phase
- A vault decision, or the vault options you want compared
- Your identity model, including how users and services will sign in
- Named owners for payments, security, platform engineering, compliance and finance
- Target Kubernetes and cloud environments, including any data center or air-gapped constraints
- Your current PCI DSS scope, the systems that touch card data, and your relationship with your assessor
Missing inputs usually turn into assumptions in the quote, so record each assumption in the written scope.
How do monthly Hyperswitch upgrades change the recurring budget?
Hyperswitch ships roughly monthly minor releases, so upgrades recur throughout the year. Each cycle needs staff time to read release notes, check the compatibility matrix for Control Center and client SDK versions, test in non-production environments, apply database migrations and roll out changes. Some releases add required dependencies. For example, the v1.124.0 release notes state that Superposition became a required configuration dependency, and a Superposition service must be running before you upgrade to that version. Budget for that effort every cycle. The more your deployment diverges from upstream, the more each upgrade costs. Ask whether the quote includes upgrades and how many are expected each year.
How do Juspay's hosted options differ in cost structure from self-hosting?
Confirm the details with Juspay in writing before you compare. In general, a hosted option may move infrastructure operation to the vendor and bill under the vendor's commercial terms, while self-hosting places those costs in your cloud accounts, your staff time and your assessments. Ask Juspay which components are included, how charges are structured, what is excluded, which PCI DSS responsibilities stay with you under each option, and what support and upgrade handling are included. Model hosted and self-hosted totals over the same volumes and processors, including one-time and recurring costs. DeployOpen does not set or quote Juspay pricing.
Does single sign-on setup add to Hyperswitch ownership costs?
It can, because the identity model affects recurring administration. The Hyperswitch Control Center supports single sign-on through OpenID Connect only. SAML is not supported, there is no JIT or SCIM provisioning, users must be invited first, and roles are managed inside Hyperswitch rather than synced from your identity provider. Without automation, inviting users, changing roles and removing access at offboarding become manual tasks that recur for the life of the platform. Include that effort in the recurring line, ask for the identity integration in the written scope, and confirm current behavior in the Hyperswitch SSO documentation before you finalize the budget.
How DeployOpen scopes and supports a Hyperswitch cost-of-ownership engagement
DeployOpen starts a Hyperswitch cost-of-ownership engagement by agreeing a written scope that separates one-time costs from recurring ones across infrastructure, vault model, PCI DSS assessment, monitoring and people. We then document the model in your own environment so your team can check each assumption before a quote or a build decision is made.
How we scope
- Agree in writing which Hyperswitch components, connectors and vault model the cost model covers before work starts.
- Map the self-hosted deployment target, such as Kubernetes on your cloud accounts or data centers, to the infrastructure line items.
- Confirm which Hyperswitch vault model applies, since in-house PCI, external PCI vault and SaaS vault change who carries PCI DSS work.
How we build
- Build a cost model that lists one-time items such as setup, vault integration and assessment preparation against recurring items such as hosting and upgrades.
- Test the Helm-based deployment and the Hyperswitch configuration in a non-production environment to confirm the infrastructure assumptions.
- Record each cost driver, such as connector count, release cadence and Superposition dependency, with the assumption behind it.
How we hand over
- Deliver the cost-of-ownership model as a document your finance, security and platform teams can review and update.
- Provide a list of questions to put to Juspay or other hosted providers so quotes compare the same scope.
- Hand over the assumptions register, including which items your internal payments and security staff must own after go-live.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer if you want the cost model kept current with monthly releases.
- Confirm with DeployOpen during scoping exactly what support and retainer terms cover for your Hyperswitch environment.
