Which open-source alternatives to Primer fit your payment stack
If you are weighing a Primer renewal, a routing change or a move away from a single orchestration layer, Hyperswitch is the closest self-hosted option for payment orchestration and card vaulting. It is an Apache 2.0 licensed, Rust-based platform maintained by Juspay, it connects to over 100 payment processors, and it includes a card vault service, so it covers the same two functions Primer sells: routing payments across processors and storing credentials outside any single processor. Teams usually look at alternatives for one of three reasons: they want processor routing decisions and credential storage under their own control, a data residency rule requires the payment data path to stay in their own cloud account, or they expect commercial terms to change at renewal.
Primer states that it stores payment credentials in a PCI-DSS Level 1 centralized vault that is independent of PSPs. That design is the reason vault portability matters in any exit plan. Before you compare platforms, confirm with Primer in writing what your contract says about vault export, the format and timing of any export, any fees attached to it, and whether pricing or packaging terms are changing. Those answers set the real cost of leaving, and they are not in the public materials. Ask Primer for its token migration documentation and ask the receiving platform which card data formats and network tokens it can accept, because a vault export that the new platform cannot ingest leaves you re-collecting card data from customers.
Hyperswitch can run locally with Docker, on Kubernetes with Helm charts, or on AWS, GCP and Azure, so you can keep the payment path in your own environment. Two points need confirmation before a decision. First, check which of the processors you use have connectors in Hyperswitch and at what maturity, since a connector that exists is not the same as one that supports every payment method you need. Second, your own team will carry the PCI DSS scope for any card data that touches your infrastructure, which changes how much of your environment is in assessment. Run a pilot with a single processor and a test vault before you commit to a migration plan.
Which open-source payment orchestration options can replace Primer
Primer combines processor routing, a centralized vault and checkout tooling in one commercial product. Open-source replacements tend to cover the orchestration and vault layers first, while checkout components and SDK features are a separate decision. The cards below set out the primary option and the checks to run before you commit to a migration path.
Hyperswitch for processor routing
Hyperswitch is the primary open-source candidate for replacing Primer's orchestration layer. It is Apache 2.0 licensed, written in Rust, and maintained by Juspay, and it connects to over 100 payment processors. Your main task is confirming that every processor on your current routing list has a connector, and that the connector supports the payment methods, currencies and 3-D Secure flows you use.
Card vault inside your own perimeter
Hyperswitch includes a card vault service, which is the component that would replace Primer's centralized vault. Running the vault yourself moves cardholder data storage into your environment, so your PCI DSS scope, key management and access controls become your responsibility. Ask for a written description of how the vault encrypts data and where keys are held before you plan any token transfer.
Deployment options for your cloud
Hyperswitch can run locally with Docker for evaluation, on Kubernetes with Helm charts, or on AWS, GCP and Azure. Choose the target that matches your existing platform team skills and data residency rules. Production hardening, high availability, backups and upgrades are work your team or a partner must own, so confirm them against the deployment guide for the version you select.
Checkout components need a separate decision
Primer's checkout components and client-side SDK features sit outside the orchestration and vault layers that Hyperswitch addresses. If you rely on prebuilt payment UI, you will need a front-end choice that talks to the new orchestration API. Inventory which screens, wallets and redirect flows depend on Primer's SDK before you size the front-end work.
Other open-source options to confirm
Other open-source payment orchestration projects may fit your processor list or regional needs. Treat any alternative as unverified until you test its connectors against your actual processors, card brands and settlement files. Build a shortlist from your own processor inventory, not from a feature summary, and record gaps before comparing licensing or operating costs.
How each Primer capability maps to self-hosted options
This table compares each main Primer capability with Hyperswitch and the gaps you should expect when self-hosting it. Read the middle column for what the open-source option covers and the last column for what you must confirm or build yourself before you sign or leave.
| Primer capability | Hyperswitch (self-hosted) | Gaps and what to confirm |
|---|---|---|
| Processor routing | Connects to over 100 payment processors and supports routing across them, as documented in its repository | Connector support varies by processor and region. Confirm each processor you use is supported and that your routing rules can be reproduced |
| Centralized vault | Includes a card vault service that you run inside your own infrastructure | You take on PCI DSS scope for the vault and its hosts. Confirm with your QSA how the vault and its keys are assessed |
| Checkout components | Provides payment APIs and orchestration, not a complete checkout UI library | Checkout UI components need a separate front-end library or your own build. Confirm the design, accessibility and 3-D Secure flows you require |
| Token migration | Stored credentials can be moved in only if the source vault exports them and the receiving vault accepts them | Ask Primer for its export process and format before you commit. Confirm that each processor will accept tokens from the new vault or that customers must re-enter cards |
| Deployment and operations | Runs locally with Docker, on Kubernetes with Helm charts, or on AWS, GCP and Azure | Your team owns upgrades, backups, monitoring and key management. Ask for a written scope covering these before work starts |
What you give up when you leave Primer and how teams work around it
Moving from Primer to a self-hosted stack gives you control over data and hosting, but it also moves duties that a managed vendor currently carries. The cards below cover the four areas where teams most often underestimate the work, with the usual workaround and what to confirm before you commit.
Vendor-managed PCI Level 1 scope
Primer stores payment credentials in a PCI-DSS Level 1 centralized vault independent of PSPs, so much of the vaulting burden sits with the vendor. Self-hosting Hyperswitch, including its card vault, moves that obligation into your environment. Plan for an internal PCI program owner, a documented cardholder data environment, and an assessor engaged before go-live. Some teams instead use a partner to manage hosting inside a compliant boundary. Confirm with your QSA which components fall in scope and whether your acquirer accepts the architecture.
Managed uptime and on-call
A managed vault and orchestration layer usually comes with the vendor's operations team, incident response and capacity planning. With self-hosted Hyperswitch on Kubernetes, your platform team owns upgrades, failover between regions, database maintenance and paging for payment-path incidents. The common workaround is a 24/7 managed operations retainer with a partner, combined with runbooks and tested failover. Ask any partner for their written incident response scope and how they handle processor outages that originate upstream of your stack.
Checkout component polish
Primer's prebuilt checkout components are designed to be dropped into a storefront with consistent behavior across payment methods. Hyperswitch is a payments backend, so you should expect to build or adapt the checkout front end yourself. Teams typically assign a front-end squad to build components against the orchestration API, then run usability and accessibility testing on each payment method. Confirm which SDKs and UI components your chosen open-source stack ships, and how much design and accessibility work your team must add.
Out-of-box processor certifications
A managed orchestration vendor often maintains existing integrations, certifications and processor relationships that your team would otherwise negotiate directly. Hyperswitch connects to over 100 payment processors, but a connector being present does not mean it is certified for your acquirer, region or payment method. Teams usually keep a short list of priority processors, validate each connector in a sandbox, and run reconciliation tests before routing live traffic. Ask each processor for its certification requirements and any fees for onboarding your own credentials.
How to move payment routing and vaulted tokens off Primer
This sequence produces a documented, tested path for moving processor routing and stored credentials from Primer to a self-hosted Hyperswitch stack, with each step gated by a check so no live payment depends on an unverified token move.
Inventory processors, flows and stored credentials
Your payments or platform team lists every processor and payment service provider connected through Primer, every checkout flow and payment method that uses them, and every place a stored credential is referenced, including recurring billing, card-on-file and webhook consumers. Map each processor to the routing rules that send traffic to it. The step is done when you have a written inventory that a second engineer can reconcile against Primer's configuration and your transaction logs, with owners named for each flow.
Confirm token export rules with Primer
Before you plan any token movement, ask Primer, in writing, how it exports vaulted payment credentials, which receiving parties it will accept, what its PCI DSS requirements are for the receiver, how long an export takes, and whether any fees or export limits apply. Use Primer's token migration guide as the starting point, then confirm whether it matches your contract. Treat this as a gating item: if Primer will not export to your receiver, or the receiver cannot meet its rules, the token portion of the plan changes. The step is done when you hold a written answer and have recorded it in the migration file.
Map exported tokens to the Hyperswitch vault
Your engineers and your security team define how each exported credential type maps into Hyperswitch's card vault service, including the data fields received, the key management arrangement, the network tokens you already hold, and how payment method identifiers in your application will be re-pointed. Confirm with the Hyperswitch documentation and your own environment which connectors accept migrated credentials without re-collection from cardholders. Where a credential cannot be migrated, record the cardholder re-consent or re-entry path. The step is done when a mapping document covers every credential type in the inventory and has been reviewed by security and compliance.
Pilot on one low-risk processor
Your team connects one lower-volume processor to a Hyperswitch instance running in your own cloud account or data center, routes a limited set of test and then live transactions through it, and checks authorization rates, decline codes, webhook delivery and reconciliation against your processor reports. Use a non-critical flow for the first run and keep Primer routing in place as the fallback. The step is done when the pilot has run through your defined acceptance criteria and each deviation has an owner and a recorded fix.
Run Primer and Hyperswitch in parallel
Your team routes a defined share of production traffic through Hyperswitch while Primer continues to handle the rest, then compares outcomes for each processor, payment method and region. Keep reconciliation daily or at the cadence your finance team requires, and track failed or disputed transactions by path. Do not retire any Primer route until the comparison shows no unexplained variance. The step is done when the finance, operations and risk owners have signed off on the parallel results in writing.
Cut over routing and tokens
Your team moves routing rules flow by flow to Hyperswitch in the order set by the inventory, starting with the lowest-risk flows, and points stored payment method references at the migrated vault entries. Confirm that recurring and card-on-file transactions succeed on the new path before moving the next flow. Keep a rollback procedure documented and rehearsed for each flow. The step is done when every flow in the inventory runs on Hyperswitch and no traffic still depends on a Primer route you have not explicitly kept.
Decommission Primer and close the migration
After the cutover is stable, your team removes Primer's routing and vault dependencies, confirms with Primer how any remaining data is handled under your contract and retention terms, revokes API keys and webhook endpoints, and archives the inventory, mapping documents and reconciliation records. Your compliance lead updates the PCI DSS scope documentation to reflect the new vault and receiver. The step is done when Primer no longer receives traffic, the contract exit steps are completed, and the evidence pack is filed for your assessor.
Which option fits by situation: residency, cost, customization or regulated
When a regulator, a customer contract or an internal policy requires card and payment data to stay in a specific country, region or data center, the deciding question is where the vault and the orchestration layer run. Hyperswitch is designed to be run in your own environment: it can be started locally with Docker, deployed on Kubernetes with Helm charts, or deployed on AWS, GCP and Azure, and it includes a card vault service. That gives you control over the location of the vault and the routing logic.
- Vault location: Confirm which region each vault and its backups sit in, and who holds the encryption keys.
- Processor egress: Map which processors receive card data from which region, since residency applies to outbound calls as well as storage.
- Logs and telemetry: Check where request logs, traces and error payloads are written, because they often contain tokens or metadata.
- Primer's position: Ask Primer where its centralized vault is hosted and whether a region-specific deployment is offered.
Before you choose, answer which data categories are in scope, which jurisdictions apply, and whether your residency obligations cover tokens as well as raw card data. Confirm each point with your legal and compliance teams and with Hyperswitch's own deployment documentation.
Cost comparisons go wrong when a SaaS subscription is set against a software license of zero and nothing else. A self-hosted Hyperswitch deployment moves cost into components you pay for or staff: cloud infrastructure, databases, observability, on-call operations, upgrades, security testing and the engineering time to integrate each processor. Primer's fees are set by contract, so the comparison needs your actual quote and your actual volumes.
- One-time costs: Integration of processors, migration of tokens, design of the checkout flow and the initial security review.
- Recurring costs: Cloud hosting, database and backup storage, monitoring, staff time, certificate and key management, and version upgrades.
- Cost drivers: Transaction volume, number of processors connected, number of regions, and how many environments you run.
- Processor fees: These stay with the acquirer or processor under either model, so exclude them from the platform comparison.
- Exit costs: Budget for token export work and parallel running if you leave Primer later.
Ask any implementation partner for a written scope that lists each component separately, so you can compare the recurring run cost against Primer's contract. Ask Primer for the fee structure in writing, including any charges for token export.
If your product needs unusual routing rules, custom checkout behavior, or a payment flow that a hosted component does not cover, the ability to change code and configuration matters more than the subscription price. Hyperswitch is open source under the Apache 2.0 license, so your engineers can read, modify and extend the orchestration logic. That freedom comes with ownership of the changes, including merging upstream releases.
- Routing rules: Determine whether your routing logic (by currency, geography, card type or cost) can be expressed in configuration or needs code changes.
- Checkout components: Assess whether your front end needs to replace or restyle prebuilt components, and how much of the UI you will own.
- Processor connectors: Confirm that each processor you need is supported, and estimate the work for any that are not.
- Upgrade path: Plan how local modifications survive upstream upgrades.
- Primer's limits: Note which behaviors you cannot change in Primer, since those constraints determine whether a switch is worth the effort.
Before you commit, list the five payment flows that matter most to your business and test each against Hyperswitch in a non-production environment. Confirm the result with your engineering lead and, where possible, with the Hyperswitch project documentation.
In a regulated environment, the question is not only whether the platform works but whether you can show auditors how it is controlled. Primer states that its credentials are stored in a PCI-DSS Level 1 centralized vault independent of PSPs. Keeping Primer is often the right choice when you need that vendor's certification scope and do not want to assume that scope yourself. Self-hosting Hyperswitch moves the PCI DSS responsibilities for the vault and the environment onto your organization, or onto the partner you contract to operate it.
- Scope reduction: Determine whether the platform will receive raw card data or only tokens, since that changes the systems in scope for PCI DSS.
- Evidence: Plan logging, access reviews, key rotation, change management and vulnerability scanning before go-live.
- Shared responsibility: Document which controls the platform vendor provides, which your team operates, and which an assessor will test.
- Assessor input: Ask your Qualified Security Assessor how a self-hosted vault would be scoped before you design it.
- Keep Primer when: Your current certifications depend on Primer's vault, or your team cannot staff continuous operation.
DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue the reports. Confirm your assessor's position on scope before you move any card data.
Planning token portability before you sign or leave Primer
Moving vaulted credentials is a PCI matter as well as an engineering task. Primer states that it stores payment credentials in a PCI-DSS Level 1 centralized vault independent of the processors it routes to. Before you sign, ask Primer in writing what export formats it supports, which receiving systems it has processed exports for, and what it charges or limits for them. Read its token migration guide in full and confirm whether a card-level export, a network token export, or both are available for your account. Those answers decide whether a Hyperswitch deployment can receive your existing payment methods at all, and how long the transfer will take.
Once you self-host, the PCI scope of the vault becomes yours. Hyperswitch includes a card vault service, but running it in your own cloud or data center means your team owns the controls around it: network segmentation, key management, access reviews, logging, and the evidence an assessor will ask for. Your qualified security assessor should confirm the scope boundary before any card data moves, because a vault that holds full primary account numbers pulls the surrounding systems into scope as well. Ask your assessor which of the requirements in the current PCI DSS apply to the receiving environment, and budget for that work separately from the software itself.
Read the export terms as carefully as the technical guide. Primer's documentation for its own export path is the place to confirm the timeline, the file format, the handling of expired or failed tokens, and whether any fee applies to an export. Ask for those terms in writing and keep them with your exit plan. If you plan to leave, run a test export with a small set of tokens into a non-production Hyperswitch environment and confirm that a payment succeeds on each processor you use, before you schedule a cutover.
Questions buyers ask before replacing Primer with Hyperswitch
What drives the cost of moving off Primer to Hyperswitch?
The cost is driven mainly by the work, not the software, because Hyperswitch is Apache 2.0 licensed and free to download. Costs fall into three groups: the infrastructure you run it on (compute, databases, networking, backups, monitoring), the engineering to integrate it with your order flow, processors and fraud tools, and the testing and compliance evidence you need before go-live. Costs that recur include infrastructure, upgrades and on-call support. Costs that are one-time include integration, processor onboarding and migration of stored credentials. The number of processors you connect, the number of payment methods and regions you support, and the complexity of your current Primer routing rules are the main levers. Ask any provider for a quote built from a written scope that lists each of these components separately.
How long does it take to migrate from Primer to Hyperswitch?
No timeline can be given responsibly until the scope is written, because duration depends on how many processors, payment methods and checkout flows are involved and how much of your routing logic must be rebuilt. Factors that lengthen the work include a large set of stored payment methods that must be exported, custom checkout components, regulatory approvals for new processors, and parallel running of old and new routes. Check the Primer token migration guide for its own export constraints before you plan, and confirm any export timing directly with Primer. Ask for a phased plan with milestones and a clear cut-over and rollback step.
What does the internal team need to provide during the migration?
Your team needs to supply knowledge of the current payment flows and the people who can approve changes. Engineers should be able to read the current Primer integration, identify every place where a payment method token or processor reference is stored, and confirm which downstream systems depend on those references. Finance and risk staff need to approve routing rules, reconciliation reports and fraud thresholds. Security and compliance staff need to review hosting, access control and logging. Plan for named owners in each area, a test environment that mirrors production payment paths, and time for them to review test results.
Can our own engineering team do the Primer to Hyperswitch move without a partner?
Some teams can, particularly those with experience running Kubernetes, Rust or Docker services and with payment integrations already in production. The license cost is zero, so the question is capacity and risk. Hyperswitch can be run locally with Docker, deployed on Kubernetes with Helm charts, or deployed on AWS, GCP and Azure, which means your platform team must own uptime, patching, secrets management and backups. A partner can take on part of that work through a fixed-scope engagement, covering planning, integration, hardening, backup design, documentation and handover, or through an ongoing retainer for upgrades and support. Decide which parts your team will own before you ask for quotes.
How does moving off Primer change our PCI DSS scope?
Moving to a self-hosted orchestration layer changes where cardholder data is stored and processed, so it changes your PCI DSS scope and responsibilities. Primer stores payment credentials in its own PCI-DSS Level 1 centralized vault, according to Primer's website. If you run Hyperswitch and its card vault yourself, your organization, or the provider you engage, becomes responsible for the controls covering that environment, including network segmentation, access control, key management, logging and vulnerability management. Ask your QSA to confirm the new scope before you start, and treat any Primer-issued attestation as Primer's evidence, not yours. Only an independent assessor can confirm your compliance status.
How does token export from Primer to a new vault work?
Token export is a question for Primer and your receiving vault together, because moving stored card data requires a PCI-compliant transfer and the receiving environment must be able to accept it. Primer's token migration guide describes how tokens are handled, and you should read it before planning. Confirm with Primer whether export is available, what format it uses, whether it is encrypted, how long it takes, and whether there are fees or limits. Confirm with the receiving system whether it accepts the format and how it maps stored credentials to processor references. Do not start a migration until you have a tested export and import on non-production data.
What should we ask for in a written scope before we replace Primer?
A useful scope lists what is included and excluded, so you can compare offers on equal terms. Ask for the components that run in your environment, the processors and payment methods to be integrated, the checkout components in scope, how stored credentials will be exported and imported, and the test plan with acceptance criteria. Ask who handles monitoring, incident response, backups, upgrades and documentation, and how those are priced. Ask what compliance evidence is prepared and confirm that independent auditors, not the provider, issue any audit reports. Request the rollback plan and the handover deliverables in writing.
How DeployOpen scopes, migrates and supports a Hyperswitch replacement
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Hyperswitch replacement of Primer, we start with a written scope that separates processor routing, checkout components and token portability so each part can be tested and signed off on its own.
How we scope
- Written scope listing which processors, payment methods and checkout flows move to Hyperswitch first
- Inventory of Primer routing rules, webhooks and vault dependencies that must be mapped before build
- Confirmation of the token export path, receiving PCI DSS environment and who owns each step
How we build
- Deploy Hyperswitch in your environment using Docker or Helm charts on Kubernetes, per your infrastructure standards
- Configure processor connectors, routing and the card vault service, with security testing of APIs and integrations
- Integrate checkout components and webhooks with your order, fraud and ledger systems, documented as built
How we hand over
- Runbooks covering deployment, configuration, key management, backup and restore for the payments stack
- Evidence packs for controls and PCI scope decisions, prepared for your assessors who issue any attestation
- Knowledge transfer sessions with your platform and security engineers before the engagement closes
How we support
- Ongoing support, upgrades and continuous security testing are available as a retainer after handover
- Tracking of Hyperswitch releases so your team reviews changes before they reach production
- Ask for a quote built from the written scope, including which parts recur and which are one-time
