Primer or Hyperswitch: which fits your payments team
Primer fits teams that want a managed, PCI DSS Level 1 centralized vault and no-code workflows for routing and checkout, with the vault operated by the vendor. Hyperswitch fits teams with engineering capacity to run orchestration inside their own infrastructure, and with a PCI scope they are prepared to own. If your renewal, a data residency requirement or a wish to hold card tokens yourself is driving the review, the answer usually turns on who must hold the card data and who will operate it afterward.
Start with PCI DSS ownership. Hyperswitch documents three vault models: self-hosted with the native Hyperswitch Vault, self-hosted orchestration with an external PCI vault provider, and self-hosted orchestration with the SaaS Hyperswitch Vault. In the in-house model, the merchant is fully responsible for PCI DSS certification and data handling, so your assessor scope grows with the vault you run. Next, list the processors and wallets you must reach on day one and check them against Hyperswitch's connector list, then confirm how routing rules, retries and checkout components would be rebuilt in your environment. Ask Primer for the same mapping so the comparison is like for like.
Finally, weigh in-house operations capacity. Running the Router, Scheduler, PostgreSQL with replicas, Redis, the card vault and the Control Center means on-call ownership, upgrades and backups that your staff or an implementation partner must carry. Also check identity requirements: the Control Center supports single sign-on through OpenID Connect only, without SAML, JIT or SCIM provisioning, so confirm that fits your identity provider before you commit. If you cannot staff those tasks, a managed vault may be the safer choice, and the sibling pages on migration and cost describe what moving would involve.
Which option fits which scenario
This table maps common team situations to the platform that usually fits better, with the reason behind each choice. Read each row against your own staffing, data residency rules and identity setup, since the right answer changes once those constraints are fixed.
| Scenario | Better fit | Reason |
|---|---|---|
| Small team that needs a fast launch with no-code routing | Primer | Primer offers no-code workflows, checkout and processor fallbacks as a hosted service, so the team does not run its own router, vault or database. Hyperswitch requires Docker or Kubernetes knowledge and ongoing operations. |
| Regulated team that must keep card data inside its own cloud account | Hyperswitch (self-hosted, in-house PCI model) | Hyperswitch runs its card vault (locker) in the organization's infrastructure, so card data stays under its control. The merchant then carries PCI DSS certification and data handling responsibility, which must be budgeted and staffed. |
| Regulated team that wants card data held by a PCI vault provider it already uses | Hyperswitch (self-hosted orchestration with an external PCI vault) | Hyperswitch can route to an external PCI vault such as VGS or Tokenex, which narrows what the team must certify. Confirm the vault provider's contract, export terms and supported processors before committing. |
| Strong platform engineering team that wants to modify routing logic | Hyperswitch | Hyperswitch is open source under Apache 2.0 and its core app server handles routing, retries and vaulting, so engineers can read and change the logic. Primer's routing is configured through its hosted no-code workflows. |
| Team that needs SSO through SAML for the admin console | Depends on the Control Center limits, so confirm before choosing Hyperswitch | The Hyperswitch Control Center supports OpenID Connect only, not SAML, and has no JIT or SCIM provisioning. Teams that require SAML must use an OIDC bridge or accept manual user invitations, and should confirm this with Primer if it is the alternative under review. |
| Team that wants wallet and network tokens to move with its cards | Confirm with each vendor before deciding | Migration of stored credentials depends on each platform's export rules and network token support. Ask both vendors which token types they export and how long delivery takes. |
| Team that wants processor coverage tested against its own stack | Hyperswitch, after a proof of concept | Hyperswitch lists more than 100 processors in its README, including Stripe, Adyen and PayPal. Confirm that each processor your business uses is supported and certified for your region before relying on it. |
Who holds the card data in each model
The vault model you choose decides who holds the card data, and therefore which PCI DSS obligations sit with your organization. Primer stores payment credentials in its own PCI-DSS Level 1 centralized vault, independent of the payment service providers it routes to. That vault is Primer's responsibility as a hosted service, so your own environment mainly needs to avoid touching raw card data while you integrate with its checkout and workflows. Hyperswitch does not offer one answer. Its documentation describes three self-hosted vault models: the native Hyperswitch Vault run in your own environment, self-hosted orchestration with an external PCI vault provider such as VGS or Tokenex, and self-hosted orchestration with the SaaS Hyperswitch Vault.
In the in-house model, the card vault (locker) is a separate Rust service from the juspay/hyperswitch-card-vault repository, and it runs in your infrastructure. The Hyperswitch documentation states that the merchant is fully responsible for PCI DSS certification and data handling in this model. That covers the vault, the database and key management behind it, the network paths between the router and the vault, the hosts and admin access, and the logs and backups that might capture card numbers. Before choosing this path, ask Juspay and your qualified assessor to confirm in writing which components fall inside your cardholder data environment, and whether your key management design satisfies the requirements you will be assessed against.
The consequence for audit is that a self-hosted vault moves scope and evidence work onto your team. You will need documented network segmentation, access control and key custody records, change and patch evidence, logging, and a data flow diagram showing where card data enters and leaves. DeployOpen can plan, configure, harden and document these controls and prepare the evidence pack for your assessor. DeployOpen does not issue audit reports, attestations or certifications; a qualified security assessor or certification body makes that determination. If you choose an external vault or the SaaS Hyperswitch Vault, the scope shifts, so get your assessor to review the chosen model before you commit to it.
Hosting models, data location and identity implications
Primer is a hosted service, while Hyperswitch can be deployed in several ways inside your own environment. The choice of hosting model determines where card tokens sit, who runs the database and cache tier, and how staff sign in to the merchant console. The cards below cover the decisions to make before comparing either product on price.
Hosted service versus self-deployed router
Primer runs as a hosted platform, so the vendor operates the application tiers and the payment credential vault on its side. Hyperswitch is deployed by you: Docker for local work, Kubernetes with Helm charts, or Azure, AWS and GCP guides. Each option moves patching, scaling, failover and incident response onto a different party. Confirm which of these the security and operations teams are prepared to own before selecting a deployment target.
Confirm production readiness first
Hyperswitch's own documentation positions the self-hosted Docker setup for local testing and offers a hosted sandbox for trial work. Treat that as a signal, not a finished production blueprint. Ask Juspay which release line and deployment pattern it supports for production, then validate high availability, backup, upgrade paths and disaster recovery in your own environment before any live card traffic is routed.
Where card data sits
With Primer, card credentials are held in its centralized vault, which is independent of the processors you connect. With self-hosted Hyperswitch, the card vault is a separate service in its own repository, and the merchant's PCI DSS scope depends on the vault model chosen. Under the in-house PCI model the merchant is fully responsible for certification and data handling. Under an external PCI vault or the SaaS vault, the scope and evidence trail shift. Map each option to your data residency rules before deciding.
Operating the Router and Scheduler tiers
Hyperswitch runs two application services, Router and Scheduler (Producer and Consumer), on PostgreSQL with a master and replica pair and Redis for caching and the scheduler queue. Your team will own database failover, replica lag, Redis availability and queue backlogs in addition to the application itself. Primer removes this layer from your staff. Ask for a runbook covering each component, its recovery objectives and the people on call before comparing run costs.
Control Center sign-in limits
The Hyperswitch Control Center supports single sign-on through OpenID Connect only, with no SAML support and no just-in-time or SCIM provisioning. Users must be invited before they can sign in, and roles are managed inside Hyperswitch rather than mapped from your identity provider. Access reviews, joiner and leaver processes, and role recertification therefore need a manual or scripted procedure. Check whether your identity platform and audit requirements accept this model.
How Hyperswitch components fit together in your environment
The Hyperswitch core app server is a Rust service that handles routing, retries, vaulting and observability, and it is the component your applications call. Hyperswitch splits its runtime into two app services, Router and Scheduler (Producer and Consumer). Router serves payment requests, while Scheduler handles deferred work such as retries and recovery jobs. Both depend on PostgreSQL, which the architecture docs describe with a master and replica setup, and on Redis, which serves as cache and scheduler queue. Before sizing a deployment, confirm with the architecture documentation how many replicas each service needs and which PostgreSQL and Redis topologies your availability targets require. The Control Center, the merchant dashboard, is a separate front end that calls these same back-end services.
Card data does not sit in the core database. It is held by the separate card vault, which the architecture docs describe as a distinct Rust service built for PCI DSS requirements, and the encryption service manages the keys that protect what it stores. This separation is what defines your trust boundary. The vault and key service should run in a network segment with the strictest access controls, with only the core app server allowed to reach them, and the Control Center and application servers should never see raw card numbers. Hyperswitch's self-hosting docs describe three vault models, and the choice determines where that boundary sits. In the self-hosted, in-house PCI model, your organization owns PCI DSS scope for the vault and its hosts. Confirm with your QSA and the Hyperswitch documentation which model fits your scope before you draw the network diagram.
The outbound edge is the last boundary to plan. Each connector sends card or token data to a processor such as Stripe, Adyen or Worldpay, so egress from the core app server must be restricted to the endpoints each configured processor requires. Log lines, traces and Control Center views must be checked for accidental card data, since observability is part of the core server's job. Review the Hyperswitch architecture documentation with your security and platform teams, and use it as the source for component-level detail, failure modes and scaling guidance that this summary does not cover.
What drives the cost of each option
What does Primer charge for, and how is it billed?
Primer's platform fees are a recurring cost set by the contract you sign, so the answer depends on the terms in that document rather than on any figure in this page. Ask Primer to state in writing the platform fee structure, what volume or usage it is tied to, which features (vault, no-code workflows, checkout, processor fallbacks) are included, and what happens to fees if you export tokens or end the contract. Also ask for the notice period and any exit or export charges. Compare those terms against the full annual run cost of the alternative, not only the license line.
Does Hyperswitch have a software license cost?
The Hyperswitch repository is licensed under Apache 2.0, so using the open-source code carries no license fee. The costs that remain are the infrastructure, engineering and compliance work to run it. Confirm before you commit whether any hosted, enterprise or support terms apply to the version you plan to use, including the Hyperswitch SaaS vault if you consider the hybrid model, and whether the Control Center features you need are included in the open-source distribution. Get those terms in writing from the vendor.
What infrastructure costs come with running Hyperswitch?
Infrastructure is a recurring cost that scales with transaction volume, availability targets and the number of environments. Hyperswitch's architecture uses a Rust core app server with Router and Scheduler services, backed by PostgreSQL with a primary and replica, and Redis for caching and the scheduler queue. You also need a Kubernetes cluster if you follow the Helm deployment path, plus separate capacity for the card vault and encryption service. Ask your cloud provider or data center team to model production, disaster recovery and non-production environments separately, because each one multiplies the baseline.
How much does integration engineering cost for a payments platform?
Integration engineering is a one-time cost that covers connecting processors, rebuilding routing rules, configuring checkout components, and testing payment flows end to end. Its size depends on how many processors and wallets you connect, how many routing workflows your current Primer setup uses, and how many client SDKs your apps need (web, Android, iOS, React Native or Flutter). Request a written scope from any implementation partner that lists each processor, each workflow and each SDK, with the test cases you expect to pass before cutover. Hyperswitch's own documentation covers the setup steps, but your team will still own the business rules.
What do PCI DSS compliance work and assessor fees add to the cost?
PCI DSS compliance work is a recurring cost, and it grows substantially under the self-hosted, in-house PCI model. Hyperswitch's documentation states that in that model the merchant is fully responsible for PCI DSS certification and data handling. With an external PCI vault provider such as VGS or Tokenex, part of that scope moves to the provider, which changes the assessor's work and the vendor's contract terms. Ask your qualified security assessor to quote the scope for each model, and ask the vault provider for its attestation package. DeployOpen prepares systems, controls and evidence for assessment but does not issue audit reports or certifications; the assessor and the card brands determine your validation level.
Should security testing be budgeted for a self-hosted payment stack?
Yes. Security testing is a recurring cost when you run your own payment stack, because you own the attack surface that a hosted provider would otherwise carry. Budget for application and API testing of the Router, the Control Center and the SDK integrations, cloud and infrastructure testing of the Kubernetes and database layers, and retesting after each upgrade. DeployOpen runs application, API, cloud and infrastructure testing, and most engagements are fixed-scope with deliverables agreed in writing before work starts. Ongoing testing is available as a retainer, so ask for a quote that separates the one-off assessment from the recurring program.
How many operations staff does a self-hosted orchestration platform need?
Operations staff are a recurring cost, and the headcount depends on your availability target, the number of environments, your on-call model and how many upgrades you take each year. Typical responsibilities include patching Kubernetes and PostgreSQL, monitoring queues and the scheduler, rotating encryption keys, managing the card vault, handling processor incidents, and supporting merchant operations. Estimate this with your own staffing model rather than a generic figure, and factor in the cost of the skills gap if your team has not run Rust services or a PCI-scoped database before. Support retainers can cover some of this work, but the internal ownership stays with you.
What does it cost to export and re-tokenize stored cards from Primer?
Token export and re-tokenization are one-time costs, and they carry the most migration risk. The cost depends on how many stored payment methods you hold, which token types can be exported (wallet and network tokens may not be), the receiving vault's intake requirements, and the effort needed to ask cardholders to re-enter cards that cannot move. Ask Primer in writing which fields and token types it will release, what the export request must include, and how long delivery takes. For comparison, Spreedly's documentation describes an encrypted batch export that is generally processed within 2 weeks and includes one free export per merchant per receiving service, which shows the kind of terms to request from any provider you export to.
What a move from Primer to Hyperswitch involves
The sequence moves routing, checkout and stored credentials from Primer to a self-hosted Hyperswitch deployment in stages, so each step ends with a check you can verify before the next one starts. Card data moves only through a documented export path, and wallet and network tokens may need to be re-collected from customers.
Inventory processors, workflows and stored credentials
List every payment service provider connected to Primer, each no-code workflow with its routing and fallback logic, every checkout surface, and every stored payment method with its token type. Record which tokens are card tokens and which are wallet or network tokens, because the export path treats them differently. Your payments and finance leads own this list, and the output is a signed inventory that becomes the scope for the rest of the move. Confirm with Primer which fields and token types its current export supports before you finalize the stored-credential count.
Choose the vault model before any build work
Hyperswitch documents three self-hosted vault models: the native in-house PCI vault, orchestration with an external PCI vault provider, and orchestration with the SaaS Hyperswitch Vault. With the in-house model, the merchant carries full responsibility for PCI DSS certification and data handling, so the choice drives the compliance scope, the staffing and the evidence you will need. Record the decision with your security and compliance leads, and confirm the choice with your assessor. The output is a written vault decision that the architecture and PCI work both reference.
Stand up Hyperswitch in a test environment
Deploy the Hyperswitch router, card vault, encryption service and Control Center in a non-production environment inside your own cloud account or data center. Hyperswitch documents Docker for local runs and Helm charts on Kubernetes, with guides for Minikube, AWS, GCP and Azure. Its architecture uses PostgreSQL with a master and replica setup and Redis, so your database and cache operations need owners before go-live. Confirm the Control Center single sign-on limits, which support OpenID Connect only, with your identity team. The output is a running test stack with its backups and monitoring configured.
Rebuild routing rules as code
Translate each Primer no-code workflow into Hyperswitch routing configuration, covering processor selection, retries, fallback order and any intelligent routing you choose to enable. Primer workflows are not exported as logic, so this step is a manual rebuild from your inventory, and it should be reviewed by someone who owns the business rules. Test each rule against sandbox processor accounts and record the expected outcome for every decline and fallback path. The output is a versioned routing configuration with test results for each rule.
Swap checkout components and client SDKs
Replace Primer's checkout components with the Hyperswitch client SDKs for web, Android, iOS, React Native or Flutter, whichever apply to your channels. Wallet buttons such as Apple Pay and Google Pay need to be re-enabled and tested against the new setup, and your front-end team should verify every payment entry point in a staging build. The output is a staging checkout where each supported payment method completes a test transaction and the results are logged.
Request the token export from Primer over SFTP
Submit a support request to Primer for the export of vaulted payment methods, and confirm the receiving provider details, delivery method and encryption requirements in writing. Primer's token migration guide describes the process, and the exact steps, supported fields and any fees must be confirmed with Primer before you commit to a date. Wallet and network tokens may not export, so list those customers separately for re-collection. The output is a received export file, a reconciliation of record counts against your inventory, and a list of credentials that must be re-tokenized.
Import tokens and re-collect what cannot move
Load the exported card records into the Hyperswitch vault in the test environment and confirm that each record decrypts and maps to the correct customer and processor. Ask customers to re-enter any wallet or network-tokenized methods that did not export, and plan these prompts into the checkout flow. Keep an audit trail of every import, error and re-collection. The output is a test vault where a sample of stored payments can be charged successfully in sandbox.
Run parallel traffic and cut over
Send a controlled share of live traffic through Hyperswitch while Primer continues to handle the rest, and compare authorization rates, declines and fallback outcomes between the two. Keep Primer active until reconciliation matches and the rollback path is tested. Once the results meet the thresholds your payments leadership sets, switch the remaining traffic and decommission Primer connections after the export and retention obligations are met. The output is a signed cutover record and a closed Primer integration.
Questions buyers ask before switching from Primer
How much work does switching from Primer to Hyperswitch take?
The effort depends mainly on how many payment flows, processors and checkout surfaces you run today, and how much of your routing logic lives in Primer's no-code workflows. Hyperswitch is configured through its Rust core app server, its Control Center dashboard and its client SDKs, so each Primer workflow must be re-expressed as connector setup, routing rules and retry logic. Teams with a few processors and a single checkout usually face a smaller rebuild than teams with many regional rules. Ask for a written inventory of workflows, connectors and checkout components before anyone commits to a timeline.
Can our own team run this migration without outside help?
A team with strong payments engineering, PostgreSQL and Kubernetes skills can attempt it, but the work spans several areas at once: service deployment, connector integration, vault handling, dashboard access and testing. Hyperswitch documents self-hosting with Helm charts and guides for Minikube, AWS, GCP and Azure, which helps, but those guides do not replace a design review for your environment. Assess your internal skills against each area, and decide whether to bring in a partner for a fixed-scope engagement with written deliverables. DeployOpen plans, implements, integrates and documents self-hosted platforms in your own infrastructure, and quotes follow from the agreed scope.
What must our team supply before a switch can start?
You will need to supply processor and gateway credentials for each connector you keep, decisions on PCI DSS scope, and engineering time from payments, security and platform teams. Credentials should be inventoried per environment, with owners named for each merchant account. PCI DSS scope decisions determine whether you run Hyperswitch's native in-house vault, an external PCI vault provider, or the SaaS Hyperswitch Vault, and each option changes which controls you must evidence. Plan for review time from your QSA or internal assessors, plus staff time for testing and cutover. Ask any implementation partner to list these inputs in the written scope.
Can Hyperswitch match Primer's no-code workflows?
Not in the same form, so confirm this before you plan around it. Hyperswitch is primarily code and configuration led: routing, retries and vault behavior are set through its core app server, its documented intelligent routing features and its dashboard. Primer's no-code workflow builder lets non-engineers change flows directly, and you should test whether your operations staff need that capability. Ask Hyperswitch and any partner to demonstrate the exact rule changes your business makes each month, and decide which ones will require an engineer. Some teams keep a small set of routing rules in code and give operators a narrower dashboard role.
Can we move stored card tokens from Primer, and what cannot move?
Whether card tokens can move depends on Primer's export process and on the receiving vault accepting them, so confirm both before planning. Primer documents a token migration path in its migration guides, but token types differ, and wallet or network tokens are often not exportable and may need re-tokenization with the customer. Hyperswitch stores card data in its own card vault service, which means the receiving side must be prepared to accept the export format and PCI handling. Ask Primer which fields and token types leave, ask your receiving provider what they require, and map each stored credential to either export or customer re-entry.
How does PCI DSS responsibility change when we self-host Hyperswitch?
Responsibility moves toward you, and the size of that shift depends on the vault model you choose. Hyperswitch's documentation states that in the self-hosted, in-house PCI model the merchant is fully responsible for PCI DSS certification and data handling. With an external PCI vault provider, part of the card data handling sits with that provider, and your scope narrows around the integration. Primer currently holds credentials in its own centralized vault, so you should compare your existing attestation with the one you would need after the move. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; a QSA or assessor does.
What should we check in Hyperswitch's identity and access setup before go-live?
Check how operators will sign in to the Control Center, because the current setup limits options. The Control Center supports single sign-on through OpenID Connect only, SAML is not supported, and it has no just-in-time or SCIM provisioning. Users must be invited first, and roles are managed inside Hyperswitch rather than mapped from your identity provider. Confirm whether these limits fit your access reviews and joiner-mover-leaver process, and document any compensating controls. Check the current configuration guide in the Hyperswitch docs before you finalize the design, since this area can change between releases.
Official sources for this comparison
Start with the Hyperswitch GitHub repository, because it is the only primary source for what the open-source router, card vault, encryption service and Control Center actually contain at the version you plan to run. Check the license file, the component list and the release notes against your own requirements before any scoping call. The Hyperswitch architecture document then shows how the Router, the Scheduler, PostgreSQL and Redis fit together, which tells your platform team what they will operate, back up and monitor. Pair it with the Hyperswitch self-hosting docs to confirm the Helm and Kubernetes path and which cloud guides are current for your target environment.
Next, read the vault and identity material as decision documents, not marketing. The three self-hosted vault models in the Hyperswitch docs differ in who carries PCI DSS responsibility, and the in-house model places full certification and data handling duties on your organization. Ask your QSA or compliance lead to review that page before anyone chooses a model. If your operators will sign in to the Control Center with corporate identity, read the Control Center SSO docs and confirm the OpenID Connect-only limit, the invite-first user model and the fact that roles are managed in Hyperswitch, not mapped from your identity provider.
Finally, get Primer's side of the comparison in writing. Its centralized vault page describes how credentials are held independently of processors, and the token migration guide sets out what Primer will and will not move. Treat both as vendor statements to verify in a contract or a written export specification. Ask Primer which token types it can export, in what format and under what conditions, and ask Hyperswitch which of your existing processor tokens it can accept. Those answers determine whether your migration is a data move or a re-tokenization project.
How DeployOpen helps evaluate, implement or migrate Hyperswitch
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Primer vs Hyperswitch, we start by settling who holds the card data and which processors, checkout paths and vault model your organization needs before any work begins.
How we scope
- We write down which processors, wallets and checkout paths the Hyperswitch deployment must cover before build starts.
- The written scope names the vault model, whether in-house PCI or an external vault provider, and who owns each PCI DSS responsibility.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing; a quote follows from that scope.
How we build
- We deploy the Router, Scheduler, PostgreSQL, Redis and card vault in your environment using the Helm or Docker paths the project documents.
- We rebuild routing rules and retry logic in Hyperswitch and test each processor connection against your sandbox credentials.
- We configure Control Center access, including the OpenID Connect single sign-on limits, and run security testing on the payment APIs before go-live.
How we hand over
- You receive architecture diagrams, runbooks, configuration records and the evidence set that your assessors or auditors will request.
- We walk your operations and security staff through routing changes, key management and vault access procedures.
- We document backup and restore tests for the database and vault so recovery steps are verified rather than assumed.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, covering Hyperswitch release changes.
- Retainer scope can include processor onboarding, routing updates and periodic security testing of the payment APIs and vault.
- We prepare systems and evidence for compliance assessments; independent auditors and certification bodies issue any attestation.
