Why a self-hosted Spreedly alternative changes your PCI DSS scope
If a renewal, per-month platform fees, or a data residency or lock-in concern is pushing you toward self-hosted payment orchestration, the first question to settle is who will hold card data. Hyperswitch is the main open-source option for self-hosting routing and vaulting, and the vault model you choose decides your PCI DSS scope. Hyperswitch documents three self-hosted vault models: the native Hyperswitch Vault run in-house, self-hosted orchestration with an external PCI vault provider such as VGS or Tokenex, and self-hosted orchestration with the SaaS Hyperswitch Vault. Each one places the card data environment in a different place, so the choice is a compliance decision as much as an architecture decision.
Spreedly is also a credible option to weigh. It launched a standalone PCI DSS Level 1 payment vault on July 15, 2026, with credentials portable across 100+ payment providers and network tokenization included, according to the Spreedly blog. Buyers who want a vault without running the orchestration layer can still evaluate that product on its own terms. PCI DSS applies to any entity that stores, processes or transmits cardholder data, or that could affect the security of the cardholder data environment, and that includes merchants, processors, acquirers, issuers and service providers. Moving orchestration in-house therefore moves that obligation with it, whatever vault you pick.
Under the in-house model, Hyperswitch's documentation states that the merchant is fully responsible for PCI DSS certification and data handling. That makes the first practical step a scoping exercise: confirm with your acquirer which self-assessment questionnaire or Report on Compliance applies, and map every system that touches the card vault, the encryption service for key management, and the PostgreSQL and Redis tiers. Ask your Qualified Security Assessor, if you use one, whether an external vault keeps the Hyperswitch application servers out of scope. Confirm that answer against your own network design, because the hosting model and data flows decide it, not the label on the vault.
What PCI DSS requires once card data sits in your environment
Once your own infrastructure stores, processes or transmits cardholder data, PCI DSS applies to your environment and to every system that could affect it. The four cards below cover who the standard applies to, how it is structured, which version is active, and who decides whether you must validate.
Who PCI DSS applies to
PCI DSS covers entities that store, process or transmit cardholder data or sensitive authentication data, and also entities that could affect the security of the cardholder data environment. That list includes merchants, processors, acquirers, issuers and service providers. A self-hosted orchestration layer that handles card numbers puts your organization in scope, and so can the cloud accounts, databases and administrators that touch it. Check with your acquirer which entity type you are before you size the work.
Twelve requirements under six goals
The standard organizes its controls into 12 principal requirements, grouped under six goals. These run from building and maintaining a secure network and systems to maintaining an information security policy. Map each requirement to a named owner in your Hyperswitch deployment, including the vault, the application servers, the database tier and the admin access paths. Gaps often appear in logging, key management and access reviews around self-hosted components.
Active version and retired versions
PCI DSS v4.0.1 is the only active version. It was published on 11 June 2024 as a limited revision of v4.0, with no requirements added or deleted. v4.0 was retired on 31 December 2024, and v3.2.1 was retired on 31 March 2024. Ask your assessor which version the assessment will use, and confirm that your documented controls cite v4.0.1 wording.
Who decides who must validate
The PCI SSC maintains the standard but does not enforce compliance or impose penalties. The individual payment brands decide which entities must comply and validate, and they run any enforcement programs. Your acquirer or card brand instructions set your validation obligation, so request that guidance in writing before you choose a vault model. Validation is documented through a Report on Compliance or a Self-Assessment Questionnaire, each with an Attestation of Compliance, and certificates do not count as validation.
Which Hyperswitch vault model puts you fully in PCI DSS scope
This model runs the Hyperswitch card vault, a separate Rust service, inside your own infrastructure, so your environment stores the cardholder data itself. The Hyperswitch documentation states that the merchant is fully responsible for PCI DSS certification and data handling under this model. Your cardholder data environment therefore includes the vault, the encryption service that manages its keys, the database and cache behind them, the hosts and networks that run them, and the people and processes that administer them.
- Full assessment burden: Your organization must validate every applicable requirement in PCI DSS v4.0.1 for the vault and its surrounding systems.
- Key management: Your team owns the encryption keys and their lifecycle, including generation, storage, rotation and access control.
- Infrastructure in scope: Kubernetes clusters, PostgreSQL, Redis, logging and backup systems that touch card data all fall within scope.
- Operational controls: Access reviews, logging, vulnerability management and penetration testing become recurring obligations you run yourself.
- Assessment type: Your assessor determines whether a Report on Compliance or a Self-Assessment Questionnaire applies to your role.
Before choosing this model, ask your QSA to map the full data flow and confirm the scope boundary in writing.
In this model you keep Hyperswitch as the self-hosted orchestration layer for routing, retries and gateway connections, and send card storage to an external PCI vault provider such as VGS or Tokenex. Hyperswitch then handles tokens rather than raw card numbers in your application flow. The scope question changes because the vault provider's environment, not yours, holds the stored primary account numbers, subject to how the integration is built.
- Vault provider responsibility: The external vault provider carries PCI DSS obligations for the storage environment, and you should obtain its current attestation documents.
- Smaller cardholder data footprint: Your systems may still see card data during capture depending on the integration, so scope depends on the exact data path.
- Contract and due diligence: Review the provider's responsibility matrix, data residency terms and exit provisions.
- Dependency on a third party: Token portability and migration depend on the provider's export terms.
- Integration design: Whether card data passes through your servers or directly from the client determines much of your scope.
Ask your QSA to confirm whether any of your systems still receive or transmit cardholder data under your chosen integration.
In this model Hyperswitch orchestration runs in your infrastructure, while the card vault is the hosted Hyperswitch Vault operated by the vendor. Card storage moves out of your environment, which reduces the systems you must assess for storage. Your scope still includes the self-hosted orchestration components and any path where card data is captured or forwarded, and the vendor's own compliance evidence governs its part of the chain.
- Storage outside your environment: Stored cardholder data sits in the vendor's vault rather than your database.
- Vendor evidence: Request the vendor's current PCI DSS attestation and its responsibility matrix before you rely on it.
- Remaining scope: Your Hyperswitch servers, network paths and client integrations stay in scope wherever card data passes through them.
- Data location: Confirm where the vault stores data and whether that location meets your residency requirements.
- Portability: Ask what export options exist if you later move the vault, referring to the vendor's documented procedures.
Confirm with your QSA which parts of the payment flow remain in your scope when the vault is hosted by a third party.
How pairing self-hosted orchestration with an external vault keeps scope down
Running orchestration in your own infrastructure does not have to put every system in PCI DSS scope. Hyperswitch documents a model in which the Router and Scheduler services, along with routing, retries and reconciliation, run in your environment while card storage moves to an external PCI vault provider such as VGS or Tokenex. In that model, the systems that hold cardholder data are limited to the external vault and the parts of your estate that touch it, which is the main lever for reducing the cardholder data environment. Confirm the exact boundary with your Qualified Security Assessor before you design around it, because scope depends on how data flows through every component, including the PostgreSQL and Redis instances, logs, the Control Center and any systems that receive tokens or decrypted data.
The defined approach is the default under PCI DSS v4.0.1, and it is what most assessments expect to see. Each requirement is met by a stated control, and the evidence is set against the requirement as written. The customized approach is an option for entities with robust security and risk management, where a stated objective is met through a different control design. It requires a documented targeted risk analysis, evidence that the custom control achieves the objective, and assessor testing of that control. Using it to justify a smaller scope is a decision to make with your QSA early, not after the architecture is built. Ask the QSA which requirements in your design would need customized controls and what evidence they would expect for each.
Scope reduction is a conclusion the assessor reaches, not a feature a vendor can promise. Before you commit to a vault model, ask the external vault provider for its own PCI DSS attestation and the responsibility matrix it provides, then map which requirements it covers and which remain with you, such as network segmentation, access control, logging and secure configuration of the orchestration servers. Treat the vault contract as part of your evidence set, and plan for a Report on Compliance or Self-Assessment Questionnaire that reflects the final data flows, not the diagram from the proof of concept.
Hyperswitch vault models and the open-source alternatives compared
This table compares the three Hyperswitch vault models with Spreedly's hosted vault and Primer's hosted vault on who holds card data, who carries PCI DSS responsibility, what you operate, and the main trade-offs. Read each row as a question about your own scope: the more card data your systems store, the more of the PCI DSS assessment is yours to evidence.
| Option | Who holds card data | PCI DSS responsibility | What you operate | Main trade-off |
|---|---|---|---|---|
| Self-hosted Hyperswitch with the native in-house vault | Your own card vault service, inside your environment | Fully yours: the Hyperswitch docs state the merchant is fully responsible for PCI DSS certification and data handling | Router, Scheduler, PostgreSQL, Redis, card vault, encryption service and key management | Lowest third-party dependency, but the widest scope and the largest assessment effort |
| Self-hosted orchestration with an external PCI vault (for example VGS or Tokenex) | The external PCI vault provider, with your orchestration holding tokens | Shared: your environment is reduced to the orchestration layer, while the vault provider's PCI validation covers card storage | Hyperswitch orchestration, routing and retries, plus the integration to the vault provider | Narrower scope, but depends on the vendor's attestation and on how tokens flow through your systems |
| Self-hosted orchestration with the SaaS Hyperswitch Vault | Hyperswitch's hosted vault, with orchestration running in your infrastructure | Shared, and the split should be confirmed in writing against the vault service terms | Self-hosted orchestration and its database and cache layers | Less to run for the vault, but card data leaves your environment and the provider's controls become part of your assessment |
| Spreedly standalone payment vault (hosted) | Spreedly, with credentials portable across 100+ payment providers | Spreedly's own PCI DSS Level 1 validation covers the vault; confirm your share of responsibility in your contract | Integration to Spreedly's API only | Documented export path exists (single card or encrypted batch file), but it is a hosted dependency and export is generally processed within 2 weeks |
| Primer centralized vault (hosted) | Primer, held independently of the processors Primer connects | Primer's PCI DSS Level 1 vault covers storage; confirm the shared responsibility split with Primer | Integration to Primer's hosted platform | Hosted unified payments with fallbacks, but orchestration is no longer self-hosted and tokens need a migration plan |
| Scope questions to confirm before you choose | Which systems store, process or transmit card data, including logs and backups | Which PCI DSS assessment type applies (ROC or SAQ) and which requirement approach you will use | Network segmentation, key management and access controls for the card data environment | Confirm with your acquirer and assessor, since the payment brands decide who must validate |
How to deploy Hyperswitch so the vault model you chose holds
This sequence turns a chosen Hyperswitch vault model into a deployed, segmented and documented environment, so the cardholder data scope you planned on paper matches what runs in production.
Scope the cardholder data environment with a QSA
Before any deployment, your team and a Qualified Security Assessor map every system that stores, processes or transmits cardholder data, plus any system that could affect its security. This includes the Router, Scheduler, PostgreSQL, Redis, the card vault, the encryption service, the Control Center, and the networks and identity tools that reach them. The output is a written scope diagram and data flow map that the assessor agrees with. Confirm with your QSA how they want the scope recorded before you build anything.
Choose and record the vault model
Select one of the three documented Hyperswitch vault models: self-hosted with the native Hyperswitch Vault, self-hosted orchestration with an external PCI vault provider, or self-hosted orchestration with the SaaS Hyperswitch Vault. Record the choice, the reason for it, and who in your organization owns each resulting PCI DSS responsibility. Under the in-house model, the Hyperswitch docs state that you carry full responsibility for PCI DSS certification and data handling. The output is a signed decision record that the QSA reviews against the scope from the previous step.
Deploy Hyperswitch with Helm or Docker
Use the Hyperswitch self-hosting documentation to deploy the stack. For a Kubernetes environment, install the official Helm charts into a non-production cluster first, following the local Minikube guide if you want a dry run. Use the AWS, GCP or Azure guide for the cloud footprint you have chosen. Docker-based local setup is suitable for developer testing only, not for the cardholder data environment. The output is a running Router, Scheduler, PostgreSQL primary and replica, and Redis, verified by a test payment in the hosted sandbox or a non-production gateway account.
Configure the card vault and encryption service
Deploy the card vault service from the separate Hyperswitch card vault repository and the encryption service for key management, in the cluster or account that sits inside your cardholder data environment. Configure the vault and key settings according to the chosen model, and confirm that card data is written only to the vault and never to application logs, the main database or the Control Center. The output is a test card stored through the vault API, with a log search showing no primary account number in any component.
Segment the network and manage keys
Place the vault and encryption service in a restricted network segment, allow inbound traffic only from the Router and approved gateway endpoints, and limit administrative access to named roles. Set up key generation, storage, rotation and access logging in a key management system you control, and document who can initiate a key change. Confirm the segmentation with a firewall rule review and a network test from outside the segment. The output is a segmentation diagram matching the scope from step one and a key custody procedure your QSA can test.
Set up SSO and access roles
Configure single sign-on for the Control Center using OpenID Connect, which is the only supported protocol. SAML is not supported, and the Control Center has no JIT or SCIM provisioning, so users must be invited in Hyperswitch before they can sign in and roles are managed inside Hyperswitch rather than mapped from your identity provider. Plan a manual joiner, mover and leaver process to cover this gap, and confirm the current behavior in the configure SSO guide. The output is a tested OIDC login for each role and a documented access review procedure.
Connect gateways and phase traffic
Connect each payment processor in a non-production configuration first, then route a limited share of live traffic through the new stack while the previous orchestrator stays active. Configure routing rules and retries in the Router, and confirm that each gateway receives tokens or credentials only through the approved vault path. The output is a traffic cutover log showing successful authorizations and declines per gateway, with a rollback path retained until your team signs off.
Document the evidence trail for assessment
Compile the evidence the assessor will request: the scope diagram, vault model decision, configuration baselines, segmentation tests, key management records, access reviews, change logs and backup restore tests. Map each item to the relevant PCI DSS requirement in your own words, and confirm with your QSA whether a Report on Compliance or a Self-Assessment Questionnaire applies to your situation. DeployOpen can prepare this evidence, but independent assessors issue the validation. The output is an assessment folder your QSA accepts as a starting point.
Evidence a QSA or payment brand will ask for
A Qualified Security Assessor or payment brand will judge a self-hosted orchestration deployment by the evidence behind its scope, not by the software name. The cards below cover the documents, tests and records that connect the card data environment to the controls claimed for it. Certificates are not accepted as validation, so each item must be backed by a PCI SSC template, an assessor's work or a dated record.
Scope definition and data flow diagram
Start with a written scope statement that lists every system that stores, processes or transmits cardholder data, including the Hyperswitch Router, Scheduler, PostgreSQL, Redis, the card vault and the Control Center. Pair it with a data flow diagram that shows where a card number enters, where it is tokenized and which components can ever see clear data. Check that the diagram matches the running environment, since the assessor will test the diagram against live configuration. Any system missing from the diagram is a scope gap the assessor will find.
Report on Compliance or SAQ with AOC
The assessment is documented either as a Report on Compliance completed by a Qualified Security Assessor or as a Self-Assessment Questionnaire, and either one ends with an Attestation of Compliance. Confirm with your acquirer or payment brand which of these they accept for your merchant or service provider level, and which PCI DSS version the assessment must cite. Only PCI DSS v4.0.1 is active, so older templates will not be accepted. Ask the QSA how the self-hosted vault and orchestration components are covered.
Network segmentation tests
Segmentation controls limit how far the cardholder data environment reaches into the rest of your network, and assessors test them. Keep evidence of firewall rules between the vault, the orchestration tier and the Kubernetes cluster, along with penetration tests that try to cross those boundaries. If segmentation is weak, the whole cluster and every service that talks to it may fall in scope. Ask your QSA whether the test method and frequency match their expectations for your environment.
Key management and access control records
Encryption keys for the vault and the encryption service need documented generation, storage, rotation, split custody and retirement records. Access records should show who holds administrative rights to the Control Center, the database and the Kubernetes cluster, how those rights were approved and when they were last reviewed. Single sign-on through OpenID Connect does not replace these records, because Hyperswitch manages roles itself. Expect the assessor to sample logs and tickets.
Customized approach documentation
If you meet a requirement through the customized approach instead of the defined approach, the assessor needs a written description of the stated objective, the controls that meet it, the risk analysis behind the choice and the testing that proves the objective is met. Compensating controls are a separate route, so do not mix the two in one file. Confirm with your QSA which requirements they are willing to review under a customized approach before you invest in the write-up.
Vendor responsibility matrix for external vaults
When an external PCI vault such as VGS or Tokenex holds the card data, the responsibility matrix must state which requirements the vault provider covers, which ones remain with you and where the boundary sits. Request the provider's own attestation for the service and keep it with your file. Recheck the matrix whenever the orchestration version or the vault integration changes. A gap in the matrix is a common cause of disputed scope.
Questions buyers ask before self-hosting Spreedly's orchestration
What drives the cost of self-hosting Spreedly's orchestration?
The cost is set mainly by the components you run and who runs them, not by a single license line. Hyperswitch itself is Apache 2.0 licensed, so the recurring items are infrastructure (PostgreSQL with a master and replica, Redis, Kubernetes or cloud compute), staff time for operations and upgrades, and any external vault or assessment fees. One-time items include integration with your gateways, card data migration and a PCI DSS assessment. Ask any implementation partner for a written quote that separates these components, and ask which ones grow with transaction volume.
Is an in-house vault cheaper than an external vault over time?
It depends on how much PCI DSS scope you are willing to carry and what you can staff. Hyperswitch documents an in-house PCI model in which the merchant is fully responsible for PCI DSS certification and data handling, so the cost sits in assessments, controls and ongoing staff effort. An external PCI vault provider, such as VGS or Tokenex as named in Hyperswitch's docs, shifts part of that burden but adds a recurring vendor fee. Compare both over several years in a written quote, and confirm with the vendor what its service covers under PCI DSS.
How long does a self-hosted Spreedly replacement take to deliver?
The timeline depends on scope, gateway count and transaction volume, so no fixed duration applies to every project. Work typically covers platform setup, vault design, gateway re-pointing, phased traffic movement and assessment preparation. Ask for a fixed-scope plan with deliverables and dates agreed in writing before work starts. Also confirm how long the card data migration takes, since Spreedly documents that encrypted batch exports are generally processed within 2 weeks.
Can our own team run Hyperswitch without outside help?
Some teams can, especially those with strong Kubernetes, PostgreSQL and payments engineering skills, but it is a production payments system that holds sensitive data. Hyperswitch offers Docker for local runs and Helm charts for Kubernetes, with guides for AWS, GCP and Azure. Be honest about gaps in payments routing, key management and PCI DSS evidence. Many organizations use an implementation partner for the first deployment and keep internal staff for day-to-day operations, which you can scope as a separate retainer.
What does the work need from our engineering and operations staff?
Plan for named owners across several disciplines. Engineers need to integrate the Router API with checkout flows and gateways. Platform staff must operate PostgreSQL with replicas, Redis, the scheduler and the card vault, and handle upgrades from GitHub releases. Security and compliance staff must own key management, access control and evidence collection. Hyperswitch Control Center supports OpenID Connect single sign-on only, with no SAML, SCIM or JIT provisioning, so identity staff should confirm that fits your IdP before build starts.
Do we need a PCI DSS assessment if we self-host orchestration?
Usually yes, if your environment stores, processes or transmits cardholder data or could affect the cardholder data environment. PCI DSS applies to merchants and service providers, and the PCI SSC does not enforce compliance itself. Your acquirer or payment brands decide which validation applies, typically through a Self-Assessment Questionnaire or a Report on Compliance completed by a Qualified Security Assessor, each with an Attestation of Compliance. Confirm your validation level with your acquirer. DeployOpen prepares systems, controls and evidence for assessment, but independent assessors issue the reports and attestations.
How do we get stored card data out of Spreedly?
Spreedly documents exporting vaulted payment methods to a PCI compliant third party, either as a single card export or as an encrypted batch file export. Each merchant gets one free export per receiving service, and batch exports are generally processed within 2 weeks. Plan the receiving vault before you request the export, confirm the receiver's PCI status in writing, and keep an inventory of which tokens move and which gateways they map to. Ask Spreedly to confirm the current export terms in your contract.
What DeployOpen plans and what your QSA decides
DeployOpen plans, implements, hardens, documents and supports a self-hosted Hyperswitch deployment inside your own cloud accounts, data centers or air-gapped network. For the vault decision, that work covers the deployment model you choose, the network segmentation around the card vault service, the encryption and key management setup, the Control Center access model and the evidence that shows each control operates. DeployOpen also runs security testing against the orchestration layer, the vault and the surrounding services, and prepares the systems and records a Qualified Security Assessor will ask for. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, so the boundary of that work is known before anything is built.
DeployOpen does not issue Reports on Compliance, Self-Assessment Questionnaires, Attestations of Compliance or certifications. Those belong to your Qualified Security Assessor or, for a self-assessment, to you as the entity completing the questionnaire. The QSA decides how your cardholder data environment is defined, which systems fall in scope and whether a customized approach is accepted for a given requirement. Your acquirer and the payment brands decide which validation level applies to you and what enforcement, if any, follows. Before you commit to a model, ask your acquirer which validation route they expect, and ask the QSA to review the in-house vault design and the external vault boundary in writing. Confirm the assessor's view on scope early, because the answer changes the work DeployOpen is asked to deliver.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Hyperswitch. For PCI DSS scope, we start by deciding which vault model fits your risk and card data flows, then build and evidence the controls that model requires. We prepare systems and evidence for assessment, but independent Qualified Security Assessors issue any validation.
How we scope
- Map every system that stores, processes or transmits cardholder data before choosing a Hyperswitch vault model.
- Agree in writing which vault model applies, and which PCI DSS responsibilities stay with your organization.
- Confirm with your acquirer and QSA which validation route (ROC or SAQ) your scope will require.
How we build
- Deploy Hyperswitch on Kubernetes with Helm charts in your cloud account, data center or air-gapped network.
- Configure the card vault or external PCI vault connection, key management and network segmentation around the cardholder data environment.
- Test authentication, access roles and gateway connections, and document the results against the scope agreed in writing.
How we hand over
- Deliver architecture diagrams, data flow maps and scope boundary documentation for your assessor.
- Provide runbooks for upgrades, backups, key rotation and incident response, with the evidence each control produces.
- Train your operations and security teams to run the platform and to keep the scope boundary intact after handover.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous security testing are available as a retainer after handover.
- Request a quote from the written scope, and ask whether it covers penetration testing and assessor preparation separately.
