Is Primer cost lower than self-hosting Hyperswitch?
Hyperswitch is licensed under Apache 2.0, so self-hosting carries no license fee. The cost moves into infrastructure, integration, PCI DSS work, security testing and the staff who run the platform. Whether that total is lower than Primer's bill depends on your own figures, and Primer's platform fees are not published in the facts available to us, so they must come from your current contract or a written quote from Primer.
Start by pulling the line items from your renewal: the platform fee, any per-transaction or per-processor charges, and anything billed for the vault or for workflow usage. Then price the self-hosted side by component. Hyperswitch's documented architecture uses a Rust router, a scheduler, PostgreSQL with a master and replica, Redis, and a card vault, and the vault documentation states that under the in-house PCI model the merchant is fully responsible for PCI DSS certification and data handling. Those obligations, along with cloud hosting, on-call operations and penetration testing, recur every year. Ask any partner or internal team for a quote split into one-time build work and recurring run work, so the two options compare on the same basis.
The answer shifts with three drivers: transaction volume, the number of processors you must connect, and how much payments engineering and compliance capability you already employ. A high volume business with several processors and an existing security team may find the fixed run costs easier to absorb. A smaller team with a few processors may not. The one-time cost of exporting stored tokens is a separate line item in either direction. Confirm with Primer what export is possible and what must be re-tokenized, because the answer determines whether you pay for a migration project, a re-collection of card data from customers, or both.
Which cost components change when you self-host Hyperswitch
This table compares each cost component of running Primer with the same component under a self-hosted Hyperswitch deployment, and marks whether it is paid once or recurs. Read it as a checklist for a quote request: no figures are given here, so every line needs a number from your own scope, vendor pricing and staffing plan. The main takeaway is that self-hosting moves spend from a platform fee into infrastructure, engineering, PCI DSS work and staff time.
| Cost component | Primer (commercial side) | Self-hosted Hyperswitch | One-time or recurring |
|---|---|---|---|
| Platform subscription or fees | Ongoing platform fees under your Primer contract; confirm the fee structure and any volume tiers in writing | No license fee for the Apache 2.0 software; costs shift to infrastructure, support and staff | Primer: recurring. Hyperswitch: none for software |
| Infrastructure | Included in the hosted service | Kubernetes cluster via Helm, Router and Scheduler services, PostgreSQL with master and replica, Redis, plus environments for sandbox and production | Recurring |
| Implementation and processor integration | Workflow and checkout setup in Primer, plus connector configuration | Connector setup for each processor, routing rules, checkout SDKs and merchant dashboard configuration | One-time, with later changes recurring |
| Card vault and PCI DSS scope | Centralized vault operated by Primer under its PCI DSS Level 1 posture | Choose the vault model: in-house PCI vault (you carry full PCI DSS responsibility), external PCI vault provider, or SaaS Hyperswitch Vault | Assessment and controls recurring; vault model decision one-time |
| Security testing | Usually covered by the provider's own assurance; confirm what evidence you receive for your own assessment | Application, API and infrastructure testing of your deployment, including the card vault and key management | Recurring, at minimum on each major change |
| Migration and token export | Export of vaulted data is requested through Primer support; confirm which token types can leave and any fees or timelines | Receiving vault must accept imported credentials; re-tokenization is needed for any token that cannot be exported | One-time |
| Support | Included in your Primer agreement; confirm response terms | Vendor support is optional; otherwise internal on-call or a retainer for incident response | Recurring |
| Upgrades and operations | Handled by Primer | You plan, test and apply Hyperswitch releases, database changes and Redis and PostgreSQL maintenance, backups and monitoring | Recurring |
| Internal skills | Primer administrators, with lower operational depth required | Staff with Rust-based service operations, Kubernetes, PostgreSQL, payments and PCI DSS knowledge; confirm headcount needs in your own plan | Recurring, plus one-time hiring or training |
What moves the Primer versus Hyperswitch comparison
Primer's platform fees and a self-hosted Hyperswitch deployment scale with different things. The six drivers below decide which side of the comparison carries more cost, and each one should be fixed in writing before a quote is compared against Primer's invoice.
Transaction and processor volume
Self-hosted cost grows with peak throughput, not with a per-month platform fee, so the sizing question is how many authorizations, retries and webhooks the router must absorb at peak. Ask Primer for the fee basis in your contract and map it against your own volume forecast. Then size the Hyperswitch database, Redis and compute tier for the peak hour, not the monthly average, and include retry traffic in that estimate.
Processors and wallets to integrate
Hyperswitch connects to more than 100 payment processors, but each connector you enable still needs credential setup, routing rules, test cases and reconciliation mapping. Count the processors you use today, the ones on your roadmap, and the wallets such as Apple Pay and Google Pay that your checkout must support. Each connector is ongoing maintenance work, so budget for it as a recurring cost rather than a one-time integration task.
Hyperswitch vault model chosen
The vault model sets your PCI DSS scope and therefore your largest compliance cost. The in-house PCI model leaves full PCI DSS certification and data handling with you. An external PCI vault provider such as VGS or Tokenex shifts part of the vault burden, while the SaaS Hyperswitch Vault keeps orchestration self-hosted. Confirm which model fits your scope before you price assessment work, because the choice changes the assessor's audit boundary.
Router and scheduler availability
The Router handles authorization traffic and the Scheduler runs retries and background jobs, both depending on PostgreSQL with a master and replica setup and on Redis. A payments outage is an incident that your team owns, so on-call coverage, database failover testing and Redis high availability all become recurring costs. Ask what availability target your card programs require, then cost the on-call rota and the replica and failover tooling needed to meet it.
Deployment edition and cloud target
Hyperswitch can run locally with Docker, on Kubernetes with Helm charts, or on AWS, GCP and Azure. The choice of cloud target and whether you use the hosted sandbox for testing determines your infrastructure bill, your managed database spend and your environment count. Compare the cost of a multi-zone production cluster, staging and disaster recovery copies against Primer's hosted model, and confirm which cloud regions your data residency rules allow.
Existing Kubernetes and PCI skills
Staffing is often the largest variable. If your platform team already runs Kubernetes, Helm, PostgreSQL and secrets handling, the operating load is incremental. If not, you will pay for hires, training or a partner for the first year and for upgrades afterward. Document which skills exist in-house, which are missing for PCI DSS evidence collection and vault key management, and what a fixed-scope implementation partner would cover before you compare totals.
How to build the cost model with your own numbers
This sequence turns a Primer invoice and a self-hosted estimate into a three-year comparison that separates one-time migration costs from recurring run costs. Each step produces a figure you can defend in a budget review.
Pull the current Primer contract and invoices
Finance and the payments owner collect the signed order form, any amendments, and the last twelve months of invoices. Record each line item separately: platform fee, any per-transaction or volume charges, add-on modules such as vault or checkout, and overage terms. Confirm with Primer in writing which items are contractual minimums and which are usage-based. The step is done when every recurring charge has a source document and a named owner.
List processors, payment methods and volumes
The payments team lists every acquirer and processor connected today, the payment methods offered in each market (cards, wallets, local methods), and the monthly transaction counts and values per route. Note which routes exist only for failover or retries, because Hyperswitch will need the same connectors to keep that behavior. The output is a connector inventory with volume figures that you can later use to size infrastructure and to check connector coverage in Hyperswitch's documented list of more than 100 processors.
Map the target hosting environment
Platform engineering documents where the workload would run: which cloud accounts or data centers, whether Kubernetes is already operated, the Helm-based deployment path, and the data residency constraints that apply to cardholder data and logs. Include PostgreSQL with a replica, Redis, and the card vault service in the diagram. The step ends with a written environment map that the labor and assessment estimates can reference, so every later cost line points to a specific component.
Price internal and external labor by component
Split labor into deployment, connector integration, checkout and SDK work, observability, backup and upgrades, on-call operations, and security testing. For each component, state who performs it (your staff, a systems integrator, or DeployOpen under a written scope) and the hours or rates you expect. Ask any implementation partner for a fixed-scope quote with deliverables listed per component. The output is a labor table with one-time build lines and recurring operations lines, which keeps the comparison honest when vendor fees are compared with staff time.
Estimate PCI DSS scope with the assessor
Ask your Qualified Security Assessor, or the assessor you already use, to define the cardholder data environment for each vault model: keeping the in-house Hyperswitch vault, using an external PCI vault provider, or using the SaaS Hyperswitch Vault. Hyperswitch's documentation states that with the in-house model the merchant carries full responsibility for PCI DSS certification and data handling, so that model usually carries the largest assessment line. Add the cost of the assessment itself, penetration testing, segmentation testing, and remediation time, and confirm each figure with the assessor's written proposal. The step is done when each vault option has its own assessment estimate.
Add token export and re-tokenization costs
Plan the one-time cost of moving stored credentials out of Primer. Ask Primer, in writing, which token types and card fields can be exported, under what process and on what schedule, and what the receiving provider must supply. Anything that cannot leave, such as certain wallet or network tokens, must be re-collected from customers or re-issued, which adds customer contact, checkout friction and temporary payment-decline risk to the model. Price the export support, the receiving vault setup, and the re-tokenization campaign. Treat this as a one-time line that is separate from run costs.
Compare one-time and recurring costs over three years
Build a three-year table with one-time costs (build, migration, export, assessment, initial testing) in year one and recurring costs (infrastructure, licenses for any paid components, operations staff, security testing retainers, upgrades) in each year. Run it against the Primer invoice baseline, with a range for volume growth. Label any example figures as illustrative. Review the result with finance, security and the payments owner, and record the assumptions that move it most. The output is a single model with a sensitivity note showing which inputs change the outcome.
What exporting and re-tokenizing cards costs once
The one-time cost of leaving Primer comes from moving stored credentials out of its centralized vault and re-tokenizing whatever cannot leave. Start by reading Primer's token migration guide to see which token types can be exported and which must be re-created. Export is not a self-service download. The receiving side must be a PCI DSS compliant provider that can accept card data, and that provider's onboarding, attestation and data-transfer steps are a cost you carry on top of Primer's own export work. Under a self-hosted Hyperswitch design, the target is usually the Hyperswitch card vault running in your own environment, which means your team owns the PCI DSS obligations for the receiving side as well.
The cost that tends to surprise teams is the tokens that do not move. Wallet tokens and network tokens are typically bound to a specific merchant, processor or card network enrollment, so they may need re-enrollment with the networks or processors before they work again. Each re-enrollment is a cardholder or processor interaction, and it recurs for every credential type that cannot be exported. Ask Primer, in writing, which token types are exportable, whether export files are encrypted and how they are delivered, what the lead time is, and whether there is a fee or a limit on the number of exports. For a sense of how a different vendor schedules this work, Spreedly documents export timing generally within 2 weeks and one free export per merchant per receiving service, but those terms belong to Spreedly, not Primer, so treat them only as a reference point for planning. Confirm Primer's export terms before you budget.
Questions buyers ask before comparing Primer and Hyperswitch costs
How much does a self-hosted Hyperswitch cost?
Hyperswitch is licensed under Apache 2.0, so the software itself carries no license fee. The cost is what you pay to run it: cloud or data center infrastructure for the Router, Scheduler, PostgreSQL with a master and replica, Redis and the card vault, plus the people who deploy, operate and secure it. Infrastructure is recurring and scales with transaction volume and high availability requirements. Labor is the larger and less predictable item: platform engineering time, database administration, on-call coverage and PCI DSS work. Ask any implementation partner for a quote that separates one-time setup from recurring run costs, and for the assumptions behind each line.
How long does a Primer to Hyperswitch migration take?
No duration can be stated from the research behind this page, so confirm it against your own scope. The timeline depends on how many processors and payment methods you connect, how many routing workflows and checkout components you rebuild, whether stored cards can be exported from Primer, and how much testing and cutover planning your environment needs. Ask the vendor or partner for a written schedule tied to named deliverables, and check which steps depend on Primer's export process, since that process has its own timing and request steps.
Can our team run a Hyperswitch migration without outside help?
It depends on the skills you already have. A self-hosted deployment needs working knowledge of Kubernetes or Docker, using the Helm charts Hyperswitch documents, PostgreSQL administration with replication, Redis operations, and secure key management for the encryption service. The payments side needs engineers who understand processor APIs, tokenization and webhooks. PCI DSS scoping and evidence are a separate skill set. Assess each area honestly against your staff, and decide early whether gaps will be filled by hiring, training or a fixed-scope engagement.
What do we need to provide for a Hyperswitch engagement?
Expect to provide four things. First, access to the target cloud accounts, clusters or data center environments where the platform will run. Second, processor and wallet credentials for each payment provider you connect, handled through your own secret management. Third, decisions on PCI DSS scope, including which vault model you choose: the native in-house vault, an external PCI vault provider such as VGS or Tokenex, or the SaaS Hyperswitch Vault. Fourth, named owners for approvals, change windows and sign-off on test results. Ask for these requirements in writing before work starts.
Does a self-hosted Hyperswitch deployment include PCI DSS certification?
No. Deploying Hyperswitch does not give you PCI DSS certification. Hyperswitch documents that in the self-hosted, in-house PCI model the merchant is fully responsible for PCI DSS certification and data handling. A qualified assessor or certification body issues the assessment result, and DeployOpen does not issue audit reports, attestations or certifications. DeployOpen can prepare systems, controls and evidence for that assessment, and security testing can be scoped alongside it. Confirm the assessor you will use and their requirements before you choose the vault model, because that choice sets how much of the cardholder environment you own.
What drives the total cost of Hyperswitch up or down?
Several factors move the total:
- Vault model: an in-house vault brings the most PCI DSS work, while an external or SaaS vault shifts some of it to a provider with its own fees.
- Transaction volume and availability targets, which set infrastructure size and the replica and failover design.
- Number of processors, wallets and payment methods connected, and how many routing rules you maintain.
- Existing Kubernetes, PostgreSQL and security tooling you can reuse.
- Migration of stored cards, including how many token types cannot be exported and must be re-collected from customers.
Ask for each of these as a separate line in any quote so you can change one assumption and see its effect.
Which parts of the Primer comparison are one-time and which recur?
One-time costs include the design of routing and checkout, integration with each processor, the export of stored tokens and any re-tokenization of cards that cannot be exported, PCI DSS readiness work, security testing and initial hardening. Recurring costs include infrastructure, platform upkeep and upgrades, monitoring and on-call labor, periodic security testing, and the assessment cycle. Primer's own fees are recurring, so compare them against your recurring self-hosted line items over the same period. Ask Primer for its current fee terms in writing, since this page does not publish them.
How the cost shifts by deployment choice
In this model you self-host Hyperswitch with its native card vault (locker) inside your own environment. Juspay's documentation states that the merchant is fully responsible for PCI DSS certification and data handling, so your organization carries the full scope: the vault, the hosts and network around it, the key management service, and the staff with access to them. Cost lines that grow include assessment work by a qualified assessor, hardening and segmentation of the cardholder data environment, key management and rotation, logging and monitoring, and penetration testing of the vault. Platform engineering time and security staff time recur every year, because the evidence must be kept current. Primer's hosted centralized vault removes some of this work, so this model moves that cost onto your own payroll and infrastructure.
- Scope ownership: Your organization is the sole party responsible for the cardholder data environment and its controls.
- Growing lines: Assessor fees, segmentation work, key management, and recurring penetration tests.
- Shrinking lines: Per-month platform fees for the vault, since the vault runs on your own infrastructure.
- One-time work: Building the environment, defining the data flows, and producing the first set of compliance evidence.
- Ask Juspay: Which vault components are in scope for your version, and what evidence they provide for your own assessment.
Confirm the staffing and assessor requirements with your qualified security assessor before you compare any totals.
Here Hyperswitch handles orchestration in your infrastructure while card data is stored with an external PCI vault provider. Juspay's documentation names VGS and Tokenex as examples of this class of provider. Scope shrinks for your environment because the orchestration layer no longer stores primary account numbers, but it does not disappear. Your systems still transmit card data and handle tokens, so the integration, network paths and access controls remain in scope, and the vault provider's own attestation becomes a cost input you must review. Costs move from building and running a vault to paying the external provider and integrating with its APIs, which is a commercial relationship with a different fee structure from Primer's platform fees.
- Scope ownership: Split between your organization for the orchestration and transmission path and the vault provider for storage, subject to its contract and attestation.
- Growing lines: Integration engineering for the provider's APIs, contract review, and assessment of the data flow.
- Shrinking lines: Internal vault build and maintenance, and most in-house key management for card data.
- Recurring fees: The provider's own fees, which you must obtain in writing rather than assume.
- Ask the provider: Its current attestation, how tokens are exchanged with Hyperswitch, and whether card data can be exported to you later.
Confirm the provider's responsibility matrix in writing before you assign scope in your own assessment.
In this model you run the Hyperswitch orchestration yourself while the card vault is the SaaS Hyperswitch Vault operated by Juspay. This is the closest of the three to Primer's arrangement, because card storage sits with a vendor, but your own orchestration, network paths and integrations still need to be assessed and maintained. The vault's compliance responsibilities and attestation must be confirmed directly with Juspay, since the documentation supplied for this page does not set out that split in full. Costs shift toward Juspay's commercial terms for the vault and toward your own infrastructure and operations staff for the orchestration layer, so the total is not simply the sum of Primer's fees minus your servers.
- Scope ownership: Shared, with Juspay responsible for the SaaS vault according to its documentation and contract, and your organization responsible for the orchestration.
- Growing lines: Operations staff for Router, Scheduler, PostgreSQL and Redis, plus upgrades and monitoring.
- Shrinking lines: Internal vault build and key management for card storage.
- Recurring fees: Juspay's commercial terms for the SaaS vault, which you should request as a written quote.
- Ask Juspay: The exact responsibility split, the attestation it holds, and the export path for tokens if you later move away.
Confirm the responsibility matrix and the export terms in writing before you rely on this model for scope reduction.
How DeployOpen works on this
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Primer cost vs self-hosted Hyperswitch decision, we start with a written scope that separates recurring platform fees from one-time migration, PCI DSS readiness and testing work.
How we scope
- Inventory current Primer processors, checkout surfaces, workflows and stored credential types before any cost comparison
- Agree which Hyperswitch vault model fits your PCI DSS responsibilities, with the in-house option carrying the merchant's full certification duty
- Put deliverables, timelines and exclusions in writing, since most engagements are fixed-scope and quoted from that scope
How we build
- Deploy the Hyperswitch router, card vault, encryption service and Control Center on Kubernetes using the supported Helm charts in your cloud or data center
- Rebuild routing rules and processor connectors, then test them against sandbox credentials before any live traffic moves
- Run security testing of the application, APIs and infrastructure, and document the controls that your assessor will request
How we hand over
- Deliver architecture, runbooks, backup and restore procedures and an operating cost model that lists each recurring component
- Document the token export and re-tokenization plan, including which credentials must be re-collected from customers
- Walk your operations and security staff through monitoring, key management and access roles before the engagement closes
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover Hyperswitch version upgrades, PostgreSQL and Redis maintenance and periodic security testing
- DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications
