Can Hyperswitch replace Spreedly and keep your card data in your own infrastructure?
Yes, Hyperswitch covers payment orchestration and a card vault, but the PCI scope moves to you. Hyperswitch, maintained by Juspay, is an Apache 2.0 licensed, Rust-based payments infrastructure that connects to over 100 payment processors and includes a card vault service. Running it in your own cloud account or data center keeps stored card data under your control, but it also means your team, not a vendor, carries the PCI DSS obligations for the environment that stores, processes or transmits cardholder data. Teams usually look for an alternative for one of four reasons: a renewal or pricing change, a licensing change, a data residency requirement, or lock-in to one vendor's vault and processor connections. Spreedly now positions a standalone PCI DSS Level 1 vault that is portable across more than 100 payment providers, and it documents exporting vaulted payment methods to a PCI compliant third party through single card export or encrypted batch file export, generally processed within 2 weeks, with one free export per merchant per receiving service. Those documented export paths are what make a move feasible. Check your own Spreedly contract for pricing, export fees and licensing terms, because no figures for these are included here and the terms that apply to you are the ones in your agreement.
Before you commit, confirm three things. First, ask Spreedly and your receiving provider which export format and encryption they support, and whether the receiver is willing to accept a batch file. Second, confirm that Hyperswitch's vault and connector set cover the processors and card networks you actually use, since the 100-plus processor figure is the project's own count and your gateways may not all be connected. Third, map the controls you would own: key management for the vault, network segmentation, access logging and the evidence an assessor will ask for. DeployOpen can plan and document that scope, but it does not issue PCI DSS attestations; a Qualified Security Assessor does. If the contract, residency rule or lock-in problem is urgent, run the export and the Hyperswitch deployment as a parallel track rather than a single cutover. Start with a test merchant, confirm that exported credentials are accepted by your processors, and only then move production traffic. The exact timeline depends on your processor list, your receiving service and the size of your vault, so ask for it in writing as part of a fixed-scope plan.
Which open-source options fit a Spreedly replacement
Spreedly bundles payment orchestration, a vault and token portability into one hosted service. An open-source replacement splits those jobs across components you run yourself, so the choice starts with which job you need covered and who carries the PCI scope for each one. The cards below cover the primary option, the ledger complement and the decisions that follow from running them.
Hyperswitch as the primary option
Hyperswitch is an Apache 2.0 licensed, Rust-based payments infrastructure maintained by Juspay. It connects to over 100 payment processors and includes a card vault service, so it covers routing and tokenization in one self-hosted stack. You can run it locally with Docker, deploy it on Kubernetes with Helm charts, or host it on AWS, GCP or Azure. Confirm which processors you need are supported and which connector features, such as network tokenization, your processors expose.
The vault becomes your PCI scope
When Hyperswitch holds the card data, your environment falls under PCI DSS obligations that Spreedly carries as a PCI DSS Level 1 service today. Plan for the hosting, network segmentation, key management and access logging around the vault, and decide whether the vault sits in a cardholder data environment you already assess. Ask your QSA how the component changes your scope before any cardholder data moves.
Operating a payments stack yourself
The trade-off is that your team owns upgrades, processor connector maintenance, uptime and incident response for the orchestration layer. Fees for the software are zero, but engineering time, cloud spend, on-call coverage and security testing recur every year. Ask any implementation partner for a written scope that separates one-time build work from ongoing support, and for the upgrade process they will follow when processor APIs change.
Exporting vaulted cards out of Spreedly
Moving away from Spreedly depends on its documented export of vaulted payment methods to a PCI compliant third party, either as a single card export or an encrypted batch file. Spreedly's documentation says exports are generally processed within 2 weeks and that each merchant gets one free export per receiving service. Confirm the receiving service can accept the format, and test the import into a non-production vault before the production export.
Apache Fineract as a ledger complement
Apache Fineract is Apache 2.0 licensed core banking software, not a payment orchestration or vault replacement. It can record the financial postings that result from payments in a ledger you run, which helps when a bank or lender needs its own books. Do not expect it to route transactions or store card data. Its Docker images are not production-ready according to the project, so budget for hardening and testing.
How Spreedly's core capabilities map to open-source coverage
This table maps each core Spreedly capability to Hyperswitch and to in-house or managed components, with a coverage note and the items to confirm. Read it as a starting checklist: where Hyperswitch is marked as partial or unconfirmed, the gap has to be closed by configuration, a separate component, or a vendor answer before you commit.
| Capability | Hyperswitch (open source) | In-house or managed components |
|---|---|---|
| Card vaulting | Includes a card vault service per its public repository. Confirm vault encryption design, key management options and where the vault database sits in your network. | Needs a PCI-scoped vault service or a managed tokenization provider. Scope and key custody decisions stay with your team. |
| Multi-processor routing | Connects to over 100 payment processors. Confirm which of your acquirers and processors have connectors, their maturity and the routing rules you need. | Routing logic usually lives in your payment service layer. Expect to build and test retry and failover rules yourself. |
| Credential portability | Portability depends on each processor and export path. Confirm, per processor, whether stored credentials can be exported, in what format, and under which agreements. | Portability is usually negotiated with each provider and vault. Plan for a re-collection path for any credential that cannot move. |
| Network tokenization | Confirm which network tokenization programs and card networks Hyperswitch supports, and whether token lifecycle updates are handled automatically. | Often sourced from a network or token service provider under a separate contract. Verify update handling and eligibility in writing. |
| Card export to a PCI compliant receiver | Export is a migration path you design. Use Spreedly's documented single card or encrypted batch export to a receiver you have validated, and confirm the receiver's PCI status first. | Receiving systems must be assessed for PCI DSS scope. Spreedly documents its own export process, including a timeframe and one free export per receiving service. |
| PCI DSS Level 1 hosting | Self-hosting makes your environment the cardholder data environment. Hyperswitch does not give you a PCI DSS Level 1 attestation. Your assessor reviews your hardening, network and key management. | A managed vault can carry its own attestation, which may reduce your scope. Ask for the current attestation of responsibility and the shared responsibility matrix. |
What PCI scope you take on when you host the vault yourself
Hosting a card vault yourself means the cardholder data store becomes part of your PCI DSS assessment scope, along with everything that can reach it. When you run the vault, you own the storage of primary account numbers, the network segmentation that isolates the cardholder data environment, the access control model for administrators and services, the logging that records who touched card data, and the key management that protects encryption keys. Each of these areas needs a documented design, an owner and evidence that the control operates. Spreedly's hosted vault carries much of that burden for you today, so this is the scope change that matters most when you weigh self-hosting.
DeployOpen plans, implements, hardens and documents these systems inside your own infrastructure, and prepares the controls and evidence an assessment will examine. DeployOpen does not issue PCI DSS attestations or certifications. Those come from a qualified security assessor (QSA) and, for merchants, are shaped by your acquirer and card brands. Plan for the assessor to test the controls you deploy, not the controls described in a proposal. Ask early whether your Hyperswitch vault would sit in a separate cardholder data environment, whether tokenization would reduce the systems in scope, and what evidence the QSA expects for key custodianship, role separation and log review.
Before any export is requested, confirm with your acquirer and your QSA which scope applies to the planned architecture. Ask them to confirm in writing whether the receiving environment is in scope, which network paths must be segmented, and how the export and the receiving vault will be documented. Spreedly's documentation describes single card and encrypted batch exports to a PCI compliant third party, and the receiving party must meet those obligations on its own. Treat the scope decision as a gating item in the project plan, because a design that the QSA rejects after build will cost more to change than one agreed at the start. A written scope decision also gives your procurement and security teams a shared basis for comparing options.
What a self-hosted payment vault costs over several years
This table sets Spreedly's subscription against the cost components of running Hyperswitch and its vault yourself, marking each line as one-time or recurring. Read it as a checklist of who is paid for what, then request quotes for the items that depend on your volume and processor count.
| Cost component | One-time or recurring | What drives it up or down |
|---|---|---|
| Spreedly subscription and fees | Recurring | Your contract terms, transaction volume and the number of payment methods you vault. Ask for the full fee schedule in writing, including any export charges. |
| Hyperswitch licensing | None (Apache 2.0) | No license fee applies under Apache 2.0. Confirm whether any commercial support or hosted offering from Juspay is needed for your environment. |
| Infrastructure (Kubernetes, databases, networking, HSM or KMS) | Recurring | Transaction peaks, redundancy targets, regions and key management choices. Right-sizing and reserved capacity usually keep this down. |
| Implementation and integration with your processors | One-time | Number of processors and connectors, custom routing rules, and existing checkout integrations. Ask for a fixed-scope written proposal per processor. |
| Vault migration and card export receiver | One-time | Spreedly's export is a single card export or encrypted batch file, generally processed within 2 weeks and with one free export per merchant per receiving service (per Spreedly documentation). Your receiver's build, testing and key exchange drive the work. |
| PCI DSS assessment preparation | One-time, then recurring annual effort | Size of the cardholder data environment, network segmentation and the assessor's scope decisions. Self-hosting a vault usually widens the scope you must evidence. |
| Ongoing operations, patching and monitoring | Recurring | Upgrade frequency, on-call coverage, and how much testing each release needs. Retainers and internal staffing are the two common models. |
| Internal skills and staffing | Recurring | Existing Rust, Kubernetes and payments expertise on your team. Gaps are usually filled by training, a partner or a longer hiring period. |
What you give up when you leave Spreedly and the usual workarounds
Moving payment orchestration and vaulting into your own infrastructure moves operational responsibilities with it. The cards below cover what Spreedly handles for you today, where that work lands when you self-host, and the contracts, test plans and hosting arrangements that usually close the gap.
Loss of a managed vault
A managed vault keeps card data inside a provider's PCI DSS Level 1 environment, and Spreedly announced a standalone PCI DSS Level 1 vault on July 15, 2026. When you self-host Hyperswitch and its card vault, you own the encryption keys, storage, backups, access logging and the evidence an assessor will ask for. Ask who in your team or partner's team operates the vault day to day, and where its keys are held.
Hosted PCI operation
Spreedly's hosted operation covers patching, monitoring and segmentation of the card data environment. Self-hosting means your cloud account, cluster and network controls fall inside the cardholder data environment, so the scope of your assessment grows. Plan for a named owner of each control, and confirm with your assessor whether a managed hosting arrangement inside your own cloud account reduces the in-scope surface.
Processor connector upkeep
Each processor connector needs updates when a provider changes its API, authentication or error codes. Hyperswitch connects to over 100 processors, but coverage for your specific processors and payment methods must be confirmed, not assumed. Budget for a retainer that covers connector upgrades and release testing, and require a changelog review before each Hyperswitch upgrade.
Documented test plan per processor
Before you switch traffic, each processor needs a written test plan covering authorizations, captures, refunds, declines, 3-D Secure flows and webhook handling. Test cases should run in a sandbox and in a controlled production pilot. Keep the results as evidence, because a failed or undocumented path becomes a payment outage rather than a reporting issue.
Network tokenization and credential portability
Spreedly's launch notes say network tokenization is included and credentials are portable across 100+ providers, but whether your processors accept your existing network tokens is a per-processor question. Ask each processor and your card brands whether tokens can be migrated or re-issued. Ask Spreedly for its export terms as well, since its documented export is limited to one free export per merchant per receiving service.
Vendor support response
A commercial provider carries a support contract with response commitments. An open-source platform has community support, and your internal team or implementation partner becomes the first responder for incidents. Agree on severity levels, on-call coverage and escalation paths in writing before go-live, and confirm which upstream fixes your partner will backport and how quickly.
How to move vaulted payment methods off Spreedly
This sequence moves stored card credentials from Spreedly into a self-hosted Hyperswitch vault without losing the ability to charge customers. It ends with verified tokens in your own environment, a tested cutover and documented evidence before Spreedly access is removed.
Inventory vaulted methods and connected processors
Your team, with DeployOpen if engaged, lists every stored payment method, the processor or gateway each one is tied to, the merchant accounts that depend on them and any network tokens in use. Record which records are active, which are dormant and which belong to customers who must be notified. The output is a signed-off inventory with counts per processor and per receiving service, which becomes the baseline for every later check. Confirm the processor list against your current contracts, since some credentials may only work through specific gateways.
Request and confirm the Spreedly export
Ask Spreedly in writing for a card export or encrypted batch file export to the receiving service you have chosen, following the process in its developer documentation. Confirm the file format, encryption method, field list, the receiving party's requirements and the expected processing window, which Spreedly documents as generally within 2 weeks. Also confirm that one free export per merchant per receiving service applies and what any further export costs. The step closes when you hold written confirmation of the format and receiving service, and your PCI-compliant receiver has agreed to accept the file.
Map exported fields to the Hyperswitch vault
Build a field mapping that links each exported attribute to the Hyperswitch card vault schema, covering card tokens, expiry data, cardholder identifiers, network tokens and the processor reference for each credential. Decide how the vault keys are generated, how duplicates are merged and how records that fail validation are quarantined rather than imported. Keep the mapping under version control and review it with your security and compliance owners. The step is complete when a sample of exported records converts without loss and the mapping document is approved.
Pilot with test cards and sandbox processors
Load the mapped records into a non-production Hyperswitch environment and run charges, refunds and recurring payments using test cards and sandbox accounts at each processor you connect. Confirm that routing rules select the expected processor for each credential and that failures return the errors your team has documented. Test access controls, logging and key rotation for the vault in the same environment. The pilot is finished when every processor path has passed the agreed test cases and the results are recorded with dates and owners.
Run a parallel period with limited live traffic
Route a small, agreed share of live transactions through Hyperswitch while the remaining traffic stays on Spreedly. Compare approval rates, decline reasons, latency and reconciliation totals between the two paths each day, and investigate any mismatch before increasing the share. Agree in advance the thresholds that would stop the rollout and who has authority to halt it. The step closes when the live results match the expected behaviour across the agreed observation window and the stakeholders have signed the go decision.
Cut over and retire Spreedly for new payments
Move all new payment traffic to Hyperswitch, confirm that stored credentials are charged from the new vault, and keep a documented rollback path to Spreedly until the cutover is stable. Notify affected customers if your terms or payment descriptors change, and update internal runbooks, on-call contacts and reconciliation jobs. The output is a cutover record showing the time, the scope and the people who approved it, along with confirmation that no new payment methods are being added to Spreedly.
Decommission Spreedly access and keep evidence
After the stabilization period set in your plan, revoke Spreedly API keys and integrations, confirm the export files are deleted or stored under your retention rules, and obtain written confirmation from Spreedly of the account status you require. Keep the inventory, export confirmations, mapping, test results, parallel run reports, cutover approval and deletion records in an evidence store that your compliance team can review. The step closes when the evidence set is complete and a named owner signs off that Spreedly no longer holds or processes your payment data.
Which option fits your situation
This path fits organizations that must keep cardholder data and vault records inside their own cloud account, data center or network segment. Hyperswitch is distributed under the Apache 2.0 license and can run locally with Docker, on Kubernetes with Helm charts, or on AWS, GCP and Azure, so the deployment location is a choice you make rather than a vendor setting.
- Deployment target: Confirm whether you need a single cloud region, a private data center, or an air-gapped segment, since each changes the hosting and networking work.
- Vault placement: Establish where the card vault database, encryption keys and backups physically reside.
- Processor egress: List which payment processors must be reached from your network and which data leaves for each one.
- Operator access: Define who in your staff and in any partner can reach production data and the hosts that hold it.
- Upgrade path: Ask how new Hyperswitch releases will be tested and applied inside your change process.
First question to resolve: which jurisdiction and network boundary must contain the card data, and does that boundary also include the processors you need?
This path fits teams comparing a Spreedly subscription against the internal cost of running an orchestration and vault platform. The commercial side is recurring and scales with usage and features, while the open-source side moves cost into infrastructure, staff time and support, and most of it recurs as long as the platform runs.
- Software cost: Hyperswitch itself carries no license fee under Apache 2.0, so the cost sits in hosting, engineering and support.
- Infrastructure: Compute, storage, managed databases, observability and backups recur monthly and grow with transaction volume.
- Staff time: Platform engineering, security operations and on-call coverage are the largest hidden cost and recur every year.
- One-time work: Initial deployment, integration with your checkout, and PCI evidence preparation are project costs.
- Quote request: Ask any implementation partner for a written scope covering each of these components, separately.
First question to resolve: what is your current transaction volume and processor count, and what internal headcount would you commit to operating the platform after launch?
This path fits teams whose main concern is being unable to move stored payment credentials or routing logic to another provider. Lock-in risk sits mostly in the vault, because exported credentials are the most expensive thing to recreate, so portability planning matters before any contract is signed or any migration starts.
- Export rights: Read your current provider's export terms, including format, delivery method, timing and any fees for exports.
- Receiving service: Confirm that the receiving platform you plan to use accepts the export and can store the data in a PCI compliant way.
- Token mapping: Plan how existing tokens or references will map to the new vault, since some providers issue tokens that cannot be reused elsewhere.
- Routing rules: Document processor routing logic as code or configuration so it can be rebuilt without vendor-specific features.
- Parallel running: Decide how long both systems will process traffic and how you will reconcile results.
First question to resolve: which of your stored payment methods can be exported in full, and which would require customers to re-enter details?
This path fits organizations under card scheme and regulatory oversight, where the first decision is how much PCI DSS scope the self-hosted platform brings into your environment. Running your own vault and orchestration layer expands the systems you must secure, document and evidence, and that work comes before any choice of product.
- Scope definition: Map every system that stores, processes or transmits cardholder data, including hosts, networks, logs and backups.
- Control ownership: Assign responsibility for each applicable requirement to your team, the platform vendor, or the hosting provider, in writing.
- Evidence trail: Plan how configuration, access reviews, patching and change records will be captured for assessment.
- Assessor engagement: Confirm early with your qualified security assessor how they will treat the self-hosted platform.
- Independent assessment: DeployOpen prepares systems and evidence for assessment but does not issue attestations, which come from your assessor.
First question to resolve: will your qualified security assessor accept a self-hosted vault in your environment, and what scope reduction, if any, do you expect to achieve?
How much work and cost does moving from Spreedly involve?
What drives the cost of moving off Spreedly to Hyperswitch?
The cost depends mostly on how many payment methods you export, how many processors and connectors you must reconnect, and how much routing, webhook and reconciliation logic your applications already depend on. Hyperswitch is free to download under Apache 2.0, so the spend is in the components around it: the infrastructure to run it, the engineering to integrate and test it, the security work to keep the cardholder data environment defined, and ongoing operations. Ask any implementation partner for a fixed-scope quote that lists each of these as a separate line, with the processors in scope named explicitly. DeployOpen scopes engagements in writing before work starts, so the quote follows from that agreed scope.
How long does the export from Spreedly take?
Spreedly documents that exports of vaulted payment methods are generally processed within 2 weeks, whether you request a single card export or an encrypted batch file export, according to its developer documentation. That window is Spreedly's processing time, so plan for it before you set a cutover date. Your own timeline will also depend on how long it takes to stand up and test the receiving vault and to confirm that the receiving party is a PCI compliant service. Confirm the current export terms directly with Spreedly, including any conditions tied to the receiving service.
How many free exports does Spreedly allow per merchant?
Spreedly documents one free export per merchant per receiving service. If you plan a test export to one destination and a production export to another, or need a second attempt, confirm with Spreedly whether additional exports carry a charge before you schedule them. Treat this as a planning constraint: a failed or incomplete export to the same receiver may consume your free allowance, so validate the receiving environment with non-production data first where your process allows it.
What does the team need to provide during the migration?
You need named owners in payments engineering, security, compliance, and finance operations, plus access to the Spreedly account, the processor accounts behind it, and the non-production environments where Hyperswitch will run. Engineering must map every Spreedly API call your applications make, including tokenization, purchases, refunds, webhooks and 3-D Secure flows, to its Hyperswitch equivalent. Your team also needs to decide who approves the export request and who signs off on cutover. Gather these inputs before requesting a quote, because they determine how much of the work is discovery and how much is build.
Can our own engineers do the migration without a partner?
Yes, a capable payments engineering team can deploy Hyperswitch from its GitHub repository, using the Docker, Helm or cloud deployment paths it documents, and connect it to your processors. The harder parts are usually not the installation. They are the PCI scope analysis, the vault and export handling, the reconciliation of settlement data, and the operational runbooks for failure modes. Decide early which of these your team will own alone and which will benefit from outside review, and staff the project for the months of operation that follow cutover, not only the build.
How does moving off Spreedly change our PCI scope?
Moving the vault changes where cardholder data is stored and who handles it, so your PCI DSS scope must be redrawn rather than assumed to shrink or grow. If you run Hyperswitch and its vault inside your own environment, that environment and its connected systems typically fall within your assessment, which increases the controls you own. If you use an external PCI compliant receiver, your assessor will need evidence of that provider's attestation and of your responsibility matrix. Give your Qualified Security Assessor the data-flow diagram, the list of systems that touch card data, and the export and import procedures early. DeployOpen prepares systems and evidence for assessments but does not issue attestations; the assessor determines your scope and conclusions.
What recurring costs should we expect after cutover?
Recurring costs include the cloud or data center capacity that runs Hyperswitch, its databases and messaging components, monitoring and logging, on-call coverage, security patching and upgrades, and the processor fees you already pay directly. Spreedly's own subscription charges end once you stop using it, but you take on the operating responsibilities it previously carried. Ask any partner to quote ongoing support, upgrades and testing separately from the initial build, since these are commonly offered as retainers, and to state which responsibilities transfer to your team.
How DeployOpen scopes, migrates and supports a Spreedly 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 Spreedly replacement, that means a fixed scope agreed in writing before work starts, a Hyperswitch deployment and card export path built and tested in your environment, and a handover your team can run.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Scope should name each processor you route to, the vault and export design, and which environments are in play.
- Ask for a written breakdown of PCI scope before a quote, showing which systems store, process or transmit card data.
How we build
- Hyperswitch is deployed in your infrastructure using Docker for local testing or Helm charts on Kubernetes.
- Card export from Spreedly and import into the vault or receiver is planned, built and tested as a documented workflow.
- Security testing of the application, APIs and cloud configuration is scoped alongside the build, not after go-live.
How we hand over
- Deliverables include architecture documentation, configuration records, runbooks and evidence for your compliance assessment.
- DeployOpen prepares controls and evidence for assessments but does not issue audit reports or certifications.
- Your team receives walkthroughs of deployment, key handling, processor onboarding and incident steps before handover closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Hyperswitch version upgrades, backup testing and periodic security testing of the payment flows.
- Ask for the support hours, response expectations and escalation path to be written into the retainer before you sign.
