Open-source alternative to Spreedly Payment Vault: the short answer
If you want card tokens under your own control, the open-source routes are Hyperswitch's own card vault (locker) running in your infrastructure, or self-hosted Hyperswitch orchestration paired with an external PCI vault provider. The choice turns on who carries PCI DSS scope: running the vault in-house makes you fully responsible for PCI DSS certification and data handling, while an external vault keeps raw card data with a provider that carries that burden. Spreedly launched its standalone PCI DSS Level 1 payment vault on July 15, 2026, with credentials portable across 100+ payment providers and network tokenization included, so the comparison is now between a vendor-run vault you can leave and a vault you operate yourself.
Before you pick a route, confirm three things with your team and your acquirer or QSA. First, whether your transaction volume and card flows justify running a PCI DSS Level 1 environment yourself, including the key management and access controls the Hyperswitch encryption service and card vault depend on. Second, whether the network tokenization you rely on today can be provisioned through a self-hosted vault or only through the external provider you would choose. Third, whether your payment brands and acquirer accept the scope you would take on. Hyperswitch documents the self-hosted, in-house PCI model separately from the external vault model, and the difference shapes assessment cost, staffing and the data migration plan.
The practical next step is to map every stored card, token and gateway credential you hold today, then decide which vault model fits that inventory. Spreedly documents exporting vaulted payment methods to a PCI compliant third party, so an export path exists, but you should confirm the receiving vault can accept the file format and that the export timing fits your cutover plan. Treat the vault decision as the first gate: once it is made, the gateway re-pointing and traffic phasing follow from it.
Which Spreedly vault capabilities Hyperswitch covers
This table maps the capabilities Spreedly offers in its standalone card vault to the parts of Hyperswitch that cover them, including the self-hosted vault and external PCI vault options. Read the Hyperswitch column as what the platform documents, and treat each item marked as a thing to confirm as a question to settle with the vendor and your own assessor before you commit.
| Capability | Hyperswitch coverage | Gap or item to confirm |
|---|---|---|
| Card storage | Card data sits in the Hyperswitch card vault (locker), a separate Rust service described as built for PCI DSS requirements | Confirm how the locker is deployed in your environment and who operates its database and keys |
| Credential portability across processors | Connects to more than 100 payment processors, with orchestration routing tokens to the chosen connector | Confirm token formats and whether each target processor accepts vaulted credentials without a fresh customer capture |
| Network tokenization | Not confirmed in the supplied Hyperswitch material as a vault feature | Confirm network token issuance and lifecycle coverage per processor and card network before you plan around it |
| Encrypted export | Spreedly export files come from Spreedly, so exports land in whichever receiver you configure | Confirm the export format and encryption scheme the receiver expects, and whether Hyperswitch can import it |
| Key management | A separate encryption service handles key management for the platform | Ask who holds master keys, how rotation works, and where key custody is audited |
| PCI DSS scope | In the self-hosted in-house model, the merchant is fully responsible for PCI DSS certification and data handling. An external PCI vault such as VGS or Tokenex can hold card data instead | Choose the vault model before scoping. Your assessor's Report on Compliance or Self-Assessment Questionnaire will follow that choice |
Three ways to hold vaulted cards with Hyperswitch
Hyperswitch documents three self-hosted vault models, and each one places a different share of card data handling and PCI DSS responsibility on your organization. Choose the model before you plan the migration, because it decides where card numbers live, who assesses them and how much work the assessment adds.
Self-hosted with the native vault
Hyperswitch runs its own card vault, called the locker, inside your infrastructure, so card data is stored in systems you operate. The Hyperswitch docs state that in this in-house PCI model the merchant is fully responsible for PCI DSS certification and data handling. Before you choose it, confirm with your qualified security assessor which controls, facilities and staff access reviews your own team must evidence, and what that adds to your current scope.
Orchestration with an external PCI vault
Hyperswitch handles routing and orchestration on your servers, while a third-party PCI vault provider such as VGS or Tokenex stores the card data. This keeps raw card storage with a provider that already holds a PCI DSS assessment, which typically narrows the cardholder data environment you must assess. Check the provider's current attestation, the data flow between the two services and the contract terms for exporting tokens later.
Orchestration with the SaaS Hyperswitch Vault
In this model Hyperswitch orchestration stays in your infrastructure, but card storage uses the Hyperswitch Vault delivered as a service. It suits teams that want self-hosted routing and retries without running a PCI-scoped vault. Ask the vendor how the vault is hosted, which PCI DSS evidence it can provide, where tokens are held and what export path exists if you later move to another vault.
Choosing between the three models
The first decision is who will hold raw card numbers: your team, a third-party vault or a hosted vault. The second is how much assessment work your organization can sustain each year, since in-house storage keeps that work in your scope. Map each option against your existing Spreedly export timing and the gateways you must keep connected, and confirm the choice with your acquirer and assessor before you sign.
How PCI DSS scope changes with each vault model
PCI DSS applies to any entity that stores, processes or transmits cardholder data or sensitive authentication data, and to any entity whose systems could affect the security of that data environment. In plain terms, scope follows the data. Every system that touches card numbers, and every system that could reach them, sits inside the cardholder data environment (CDE) and must meet the standard. The PCI Security Standards Council owns the standard, but the payment brands decide which entities must validate compliance. Validation is documented on official PCI SSC templates: a Report on Compliance (ROC) completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire (SAQ), each with an Attestation of Compliance (AOC). Certificates are not accepted as validation.
- Scope follows data flow: map where card data enters, is stored and leaves before you pick a model.
- ROC or SAQ: the level your acquirer or brand requires determines whether a QSA writes a ROC or you complete an SAQ with an AOC.
- Certificates: a vendor or hosting certificate does not replace your own AOC.
- Customized approach: v4.x allows it only for entities with robust security and risk management, and it needs documented evidence for each objective.
- Version: PCI DSS v4.0.1 is the only active version, so assessments should reference it.
Confirm with your acquirer which validation level and template apply to your organization.
In the self-hosted, in-house PCI model, you run the Hyperswitch card vault (locker) yourself inside your own infrastructure. Card data is stored in your environment, so the vault, its encryption keys, the hosts running it and every system with network access to it fall within your CDE. The Hyperswitch documentation states that the merchant is fully responsible for PCI DSS certification and data handling in this model. Scope is the widest of the three models, and the assessment burden sits with your team.
- Full CDE ownership: the vault, key management, databases, hosts and admin paths are all in scope.
- Assessment: expect a full ROC or a broader SAQ path, depending on your validation level, with a QSA or your own qualified staff completing evidence.
- Controls evidence: key custody, access logging, network segmentation and patch records must be produced for each requirement.
- Customized approach: only use it where your risk management is mature enough to document the alternative objective.
- Recurring work: scans, penetration tests and annual assessment repeat each cycle.
Ask Hyperswitch and your QSA to walk through the in-house scope boundary in writing before you commit to this model.
In the self-hosted orchestration model with an external PCI vault, Hyperswitch runs your routing and orchestration, and a third-party PCI vault provider such as VGS or Tokenex stores the card data. Hyperswitch documents this pattern as a way to keep card storage outside your own CDE. Your scope shrinks to the systems that handle tokens and the connections to the vault, but it does not disappear. The provider's own PCI DSS validation becomes an important input, and you must confirm exactly which data paths still pass through your servers.
- Reduced CDE: card numbers are stored by the vault provider, not your Hyperswitch hosts.
- Provider evidence: request the provider's current AOC and the responsibility matrix that states which requirements it covers.
- Residual scope: the orchestration servers, token handling, logs and network paths that touch card data remain in scope.
- Contract terms: confirm data export, deletion and subprocessor terms, since they affect later migration.
- Integration review: each connector must be checked so that no raw card data is logged or cached locally.
Confirm the provider's responsibility matrix and your remaining scope with your QSA before finalizing the architecture.
In the self-hosted orchestration model with the SaaS Hyperswitch Vault, your orchestration runs in your infrastructure and card storage is handled by the hosted Hyperswitch Vault service. This keeps your storage footprint small, but it changes what you must verify. Your assessment depends on the vault operator's attestation and on how your environment connects to it. The Hyperswitch documentation describes this as a distinct deployment model, so confirm its current validation status and data residency terms directly with the vendor rather than assuming them from this page.
- Shared responsibility: the vault operator's controls and your own controls must be documented together.
- Attestation: obtain the operator's current AOC and confirm the services and locations it covers.
- Connectivity: document the API calls, keys and networks linking your orchestration to the vault.
- Residency: confirm where tokens and card data are stored and which jurisdictions apply.
- Exit planning: record how cards would be exported if you later change vault providers.
Ask the vendor for its current validation documents and have your QSA confirm the responsibility split before go-live.
Running Hyperswitch beside Spreedly during the transition
The first decision is whether to keep Spreedly for gateway connections while a self-hosted vault takes over card storage, or to use the new vault only for tokens created after a cut-over date. Both patterns are workable, but they differ in what must be routed where. Under the first, Spreedly keeps forwarding transactions to processors it already connects, and Hyperswitch stores new cards and issues tokens that your own services present to the gateways. Under the second, existing cards remain in Spreedly until they are exported or expire, and only new enrolments land in Hyperswitch. Write down which pattern applies to each gateway before any traffic moves, because the choice drives the routing rules, the reconciliation scope and the PCI DSS scope of the transition period.
Per-gateway routing is the control that keeps the two platforms from contradicting each other. For every gateway, record which system holds the credential, which system sends the authorization, and which system receives the webhook for each outcome. Hyperswitch's routing and retry logic can send traffic to a connector, but a token issued by one vault is generally not usable by another without an agreed export and re-tokenization path, so a misrouted request can fail or, worse, charge a card twice if retries overlap. Test the routing table in a sandbox with known test cards before production traffic is shifted, and keep a documented rollback that returns a gateway to its previous path.
Reconciliation then has to cover two token sets, not one. Map every Spreedly token to its Hyperswitch counterpart, or to the gateway token it resolves to, and track which side each active subscription and stored payment method sits on. Confirm with both vendors, in writing, which credentials and network tokens are portable, since Spreedly's documented export path and Hyperswitch's own onboarding requirements may differ in format, timing and eligibility. Ask Spreedly whether network tokens are included in the export, and ask Hyperswitch how it imports card data and which key material your team must hold. Until those answers are confirmed, do not retire any Spreedly token that still backs a live subscription.
Moving vaulted cards from Spreedly to a self-hosted vault
This sequence moves stored payment credentials from Spreedly into a vault you control, so that gateway traffic can run from your own infrastructure without losing the saved payment methods your customers depend on.
Confirm the receiving vault and PCI scope
Decide whether the destination is the in-house Hyperswitch card vault or an external PCI DSS compliant vault provider, and document who owns the receiving environment. If you choose the in-house model, the Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling, so your assessor should be engaged before any card data moves. The output is a written decision naming the receiver, its PCI status and the internal owner.
Confirm export formats with Spreedly
Ask Spreedly to confirm, in writing, which export path fits your case: a single card export or an encrypted batch file export, the file format and encryption requirements, and the information Spreedly needs about the receiving endpoint. Spreedly's documentation says exports go to a PCI compliant third party and are generally processed within 2 weeks, with one free export per merchant per receiving service. The output is a confirmed export request that names the receiver and the agreed format.
Request the export from Spreedly
Submit the export request through Spreedly's documented process, with the receiving PCI compliant endpoint set up and tested for transport before the request is made. Keep a record of the request date, the scope of payment methods included and the contact who will receive the file. Because the free export is one per merchant per receiving service, confirm that the receiving endpoint is ready before you submit. The output is an acknowledged request and a logged export scope.
Validate the import in a test environment
Load the exported data into a non-production Hyperswitch or external vault environment and check that each record maps to the correct customer and payment method. Run test transactions through sandbox gateway credentials to confirm that the imported credentials are accepted where the processor supports them. Record any records that fail to import and the reason for each failure. The output is a reconciliation report showing successful, failed and excluded records.
Re-point gateways and phase traffic
Configure the Hyperswitch connectors for each processor and route a limited share of production traffic through the new vault before expanding. Monitor authorization rates, decline codes and error logs for each connector during the phase-in. Keep Spreedly running in parallel until the new path has handled the agreed traffic without material issues. The output is a signed-off traffic plan with monitoring evidence for each connector.
Redact or retire Spreedly tokens
Once the new vault is the system of record and Spreedly is no longer used for charges, remove or retire the Spreedly tokens in your systems and confirm with Spreedly how the remaining stored payment methods are handled under your agreement. Retain the export reconciliation report and change records as evidence for your assessor. The output is an inventory showing which tokens were retired, when, and by whom.
Questions buyers ask before replacing the Spreedly vault
What does replacing the Spreedly vault cost, and which parts recur?
Cost splits into one-time work and recurring running costs, and each part is paid to a different party. One-time items include scoping, deploying Hyperswitch on Kubernetes or in a cloud account, configuring the card vault and encryption service, re-pointing gateways, migrating card data, and the first PCI DSS assessment with penetration testing. Hyperswitch is Apache 2.0 licensed, so the software itself carries no licence fee. Recurring items include cloud hosting, PostgreSQL with a replica, Redis, staff time for upgrades and on-call cover, the annual PCI DSS assessment, and any fees from an external PCI vault if you pair Hyperswitch with one. Spreedly's documentation allows one free export per merchant per receiving service, so ask Spreedly how it bills further exports. Ask any quote to price each component separately and show how the figures change with transaction volume.
How long does moving vaulted cards out of Spreedly take?
A vault move runs on Spreedly's export timing and on how ready the receiving side is, and the receiving side usually sets the pace. Spreedly documents that exports to a PCI compliant third party, whether single card or encrypted batch file, are generally processed within 2 weeks. That clock depends on the receiver being ready, so its PCI status, the encryption arrangements for the batch file, and test exports matter most. Other drivers include the number of stored payment methods, how many gateways must be re-pointed, how many payment flows depend on Spreedly tokens, and how many traffic phases you plan. Ask any quote for a schedule that separates receiver setup, test export, production export, gateway cutover and post-migration token clean-up. The Spreedly export documentation sets out the supported formats and steps.
What must our team provide before a vault migration starts?
Your team must supply decisions and access before any deployment starts. The first input is a named owner for PCI DSS scope who can sign off data flows, the cardholder data environment boundary, and the choice between the in-house vault and an external PCI vault. The second is cloud or data center accounts with network segments, Kubernetes capacity, and database and backup storage inside your own environment. The third is key custody: who generates, stores, rotates and recovers the encryption keys that protect the vault, and where any hardware or cloud key service sits. You also need gateway credentials for each processor, a change calendar for cutover, and named staff for incident response. Ask for these inputs to be written into the agreed scope, each with a named owner, before work begins.
Can our internal engineering team run a self-hosted Hyperswitch vault alone?
It is possible, but the answer depends on your skills and on the vault model you choose. Hyperswitch documents three models: a self-hosted native vault that is in-house PCI, self-hosted orchestration with an external PCI vault such as VGS or Tokenex, and self-hosted orchestration with the SaaS Hyperswitch Vault. In the in-house PCI model, the Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling, which is a heavy load for a team without assessment experience. Running the card vault service, PostgreSQL with replicas, Redis, Kubernetes and key management also needs on-call cover for upgrades and incidents. Many teams combine internal platform staff with outside help for design, hardening, backup testing and documentation. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your infrastructure under a fixed scope or a retainer. It does not issue audit reports or attestations.
How does OIDC-only SSO in the Hyperswitch Control Center affect operations?
OIDC-only single sign-on means your identity provider must support OpenID Connect, and every access step for the dashboard has to be finished inside Hyperswitch. The Hyperswitch docs say the Control Center does not support SAML, offers no just-in-time or SCIM provisioning, requires users to be invited first, and expects roles to be assigned inside Hyperswitch. For operations, joiner, mover and leaver steps need a manual or scripted action in the Control Center as well as in your directory. Access reviews must check Hyperswitch roles directly, and offboarding must remove the Control Center user even after the directory account is disabled. Before you commit, confirm the current SSO documentation for your version, test your provider's OIDC claims, and write role assignment and access review steps into your runbook. Ask any implementation quote to include these steps in its scope.
Does a self-hosted vault remove the need for a PCI DSS assessment?
No. A self-hosted vault changes your PCI DSS scope but does not remove the assessment. PCI DSS applies to any entity that stores, processes or transmits cardholder data, or that could affect the security of the cardholder data environment, which includes merchants and service providers. With the in-house vault model, the Hyperswitch docs make the merchant fully responsible for PCI DSS certification and data handling, so the wider environment is in scope. An external PCI vault can narrow the cardholder data environment, but you still need to show how your orchestration and networks connect to it. Assessments are documented through a Report on Compliance from a Qualified Security Assessor, or a Self-Assessment Questionnaire, each with an Attestation of Compliance. Certificates are not accepted as validation. The PCI SSC does not enforce compliance, so your acquirers and payment brands decide who must validate. DeployOpen prepares systems, controls and evidence, but independent assessors issue the reports.
Can the vault controls use the customized approach under PCI DSS v4.x?
Yes, if your organization has robust security and risk management, PCI DSS v4.x allows the customized approach as an alternative to the defined approach for a requirement. Under the customized approach, you meet the stated objective of a requirement in a different way and document how you do it. A separate route, compensating controls, covers cases where a requirement cannot be met as written. Teams consider these options when a self-hosted vault design, such as key handling or network segmentation, does not map neatly onto a defined testing procedure. Agree the approach with your Qualified Security Assessor before the build starts. Document the objective, the risk analysis and the testing evidence, and keep the design under change control. The active version is PCI DSS v4.0.1, which the PCI SSC published on 11 June 2024. Confirm which version your assessor will test against at the start of the engagement.
What makes a self-hosted vault cost more or less than Spreedly's fees
The main cost question is not the software licence, because Hyperswitch is Apache 2.0 licensed. The question is which components you pay for, who runs them, and which of them grow with transaction volume. Spreedly bundles the vault, the PCI DSS Level 1 environment and the operation of the service into one recurring fee. A self-hosted vault splits that bundle into separate lines: infrastructure, key management, implementation, PCI DSS assessment, penetration testing and staff time. Ask your team to list each line before comparing totals, and ask any implementation partner to price them separately in the written scope.
Several items are one-time, and several recur. Implementation of the Hyperswitch card vault and encryption service, the card data migration, and the first PCI DSS assessment are usually one-time or project-based costs. Hosting is recurring: the vault and the Router and Scheduler services need PostgreSQL with a master and replica, and Redis, each deployed highly available in your cloud account or data centre. Key management, including the encryption service and key rotation procedures, recurs through hardware or cloud key services and staff time. Penetration testing and the annual assessment recur. Ongoing operations, upgrades and on-call support recur for as long as you run the platform. Confirm with your assessor whether the self-hosted vault puts you in full PCI DSS scope, since the Hyperswitch docs say the merchant is then fully responsible for PCI DSS certification and data handling.
Costs that grow with volume include database and cache capacity, backup storage, logging and monitoring, and the number of gateway connections you maintain. Costs that grow with the size of your PCI DSS environment include the scope of testing and the evidence you must collect. Spreedly's fees also scale with usage, so the crossover point depends on your own transaction forecast, not on a general rule. For a quote, ask each bidder for separate figures for one-time migration, recurring hosting, key management, assessment, penetration testing and support, and for the assumed transaction volume behind each. Ask Spreedly for its current pricing terms in writing to make the comparison like for like.
Risks to plan for before you take card data in-house
Moving card storage from Spreedly's hosted vault to your own infrastructure changes who holds keys, who answers to PCI DSS, and how cards leave the old vault. The six risks below are the ones to resolve in writing before any card data moves, and each one has a specific check to run with your vendor or assessor.
Key custody and rotation
Once you self-host the Hyperswitch card vault, the encryption keys that protect stored card data sit in your environment, so your team owns key generation, storage, rotation and recovery. Losing or mishandling a key can make vaulted cards unreadable, which is a larger failure than a slow migration. Confirm with Hyperswitch exactly how the encryption service manages keys, what a documented rotation procedure looks like, and whether a key loss can be recovered from backups. Ask your assessor how key custody is evidenced.
PCI DSS version changes
PCI DSS v4.0.1 is the only active version, and the PCI SSC has run a request for comments toward the next iteration without announcing a release date. An in-house vault means you carry the requirements directly, so a future revision could add controls to your scope after you have designed the environment. Plan the architecture so controls can be added without a rebuild, and ask your QSA how they will assess against the current version and handle a transition period. Do not assume the next version will leave your design untouched.
SSO limits in the Control Center
The Hyperswitch Control Center supports single sign-on through OpenID Connect only, with no SAML, no just-in-time or SCIM provisioning, and roles managed inside Hyperswitch rather than mapped from your identity provider. Access to a payments console that can view or move card tokens therefore needs manual user invitations and separate role administration, which adds an audit and offboarding burden. Confirm how your identity provider will supply OIDC, who approves invitations, and how deprovisioning removes access in time. Check that your access reviews include Hyperswitch roles.
Export timing from Spreedly
Spreedly documents encrypted batch exports to a PCI compliant receiver, which are generally processed within 2 weeks, and it allows one free export per merchant per receiving service. Because a single free export is the default allowance, a failed or incomplete batch can cost you the free export and extend the parallel run. Ask Spreedly whether a second export to the same receiver carries a fee, what the processing window is for your volume, and what happens to the vault during the export. Schedule the export so that your cutover date does not depend on the batch arriving on time.
Token portability across processors
Vaulted credentials are only useful if the receiving system can charge them through each processor you use. Spreedly's standalone vault is described as portable across more than 100 payment providers, but your receiving vault and each gateway may handle network tokens, card-on-file flags and recurring credentials differently. Ask Spreedly which credentials and network tokens are included in the export, and ask Hyperswitch and each processor whether they will accept the migrated credentials without a new customer authentication. Test a sample set of each card type before committing to a full transfer.
Gateway onboarding and rerouting
Each processor you connect to Hyperswitch needs its own merchant credentials, configuration and certification before traffic can move. If a gateway is not yet onboarded, cards exported from Spreedly cannot be charged through it, and a partial cutover can split recurring billing across two systems. Build a gateway matrix that lists each processor, its onboarding status, its owner and its test results, and confirm with each processor which requirements apply to a new integration. Phase traffic only for gateways that have passed end-to-end tests.
How DeployOpen scopes and delivers a vault replacement
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a vault replacement starts with a written scope that names the vault model, the cloud or data center, and the systems that will hold or receive card data. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we scope
- Confirm which Hyperswitch vault model fits: in-house PCI, external PCI vault, or SaaS Hyperswitch Vault.
- Inventory every Spreedly gateway credential, payment method type and receiving endpoint that the export must reach.
- Record which teams, systems and networks would fall inside the PCI DSS scope of the self-hosted environment.
How we build
- Deploy Hyperswitch on Kubernetes with Helm charts in your cloud account or data center, following the documented guides.
- Configure the vault, encryption service, PostgreSQL and Redis components, and connect them to your chosen gateways.
- Test tokenization, routing and retries in a staging environment before any live card data is moved.
How we hand over
- Provide written architecture, configuration and runbook documents covering the vault, key management and access model.
- Document the PCI DSS evidence your assessor will request, mapped to the controls in your chosen vault model.
- Walk your operations and security teams through backup, upgrade and incident procedures before cutover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan Hyperswitch version upgrades and test them against your gateway connections before production rollout.
- Coordinate with your Qualified Security Assessor or internal assessor on evidence requests, without issuing any audit report or attestation ourselves.
