When does self-hosted Hyperswitch cost less than Spreedly?
Self-hosting Hyperswitch costs less than Spreedly only when the recurring platform fees you avoid exceed what you add in infrastructure, one-time implementation and card data migration, PCI DSS assessment and penetration testing, and ongoing engineering and operations staff. The answer depends on your transaction volumes and on whether your team can run a payments stack in-house. Spreedly's pricing is not part of the material available for this page, so start by pulling your own contract: the platform fee, per-transaction and per-gateway charges, any minimums, and what the renewal or fee change actually moves. Those figures are the baseline for every comparison that follows.
Build the self-hosted side as separate lines, and note which ones recur. Hyperswitch is Apache 2.0 licensed, so there is no software licence line, but the Hyperswitch docs describe a Rust core app server, a Scheduler, PostgreSQL with a master and replica, Redis and a separate card vault service. Cloud or data center compute, database and cache operations, key management, monitoring, and on-call staff recur. Implementation, the export and import of stored cards, and the PCI DSS assessment are mostly one-time, though re-assessment recurs. Under the in-house vault model, the Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification, so price that work explicitly. Ask any implementation partner for a quote that splits these lines and names who carries each one.
Plan the migration input carefully. Spreedly documents exporting vaulted payment methods to a PCI compliant third party through a single card export or an encrypted batch file export, which is generally processed within 2 weeks, and it allows one free export per merchant per receiving service. Count that free export as the only export you get without an extra charge, and confirm with Spreedly whether any further exports or file handling carry fees before you commit to a timeline. Also confirm the receiving endpoint's PCI status, because a receiver that is not compliant changes both the export and your assessment scope.
Which cost components sit on each side, and which recur
This table sets Spreedly's commercial charges against the components you would fund when self-hosting Hyperswitch, and marks each as one-time or recurring. Read it as a checklist for building a like-for-like comparison, since most of the self-hosted cost is labor and assurance rather than software licences. Fees and export charges are quoted only where a supplied source states them, so confirm current commercial terms in writing.
| Cost component | Commercial side (Spreedly) | Self-hosted side (Hyperswitch) | One-time or recurring |
|---|---|---|---|
| Subscription or platform fees | Spreedly platform and vault subscription, confirmed in the written order form | No licence fee for the Apache 2.0 code; you fund the staff and infrastructure that run it | Spreedly: recurring. Hyperswitch: none for software |
| Infrastructure | Included in the Spreedly service | Kubernetes or cloud compute, PostgreSQL with master and replica, Redis, and the separate card vault service | Recurring, scales with environments and traffic |
| Implementation | Spreedly onboarding and gateway connection work, confirm what is included | Helm or cloud deployment, configuration of connectors, routing and retries, and Control Center setup | One-time, with later changes recurring |
| Gateway contracts and connectors | Spreedly connects to gateways under its own integrations | Your direct or existing contracts with each processor, plus connector maintenance as processor APIs change | Recurring, driven by processor agreements |
| Card data migration | Spreedly documents export of vaulted payment methods to a PCI compliant third party, by single card or encrypted batch file, generally within 2 weeks, with one free export per merchant per receiving service | Receiving the export, validating tokens, loading the Hyperswitch vault and reconciling records | One-time, with a second export or re-run cost if the target changes |
| PCI DSS assessment and scope | Spreedly carries the vault's PCI DSS Level 1 posture as a service provider, confirm its attestation documents | The in-house vault model makes you fully responsible for PCI DSS certification and data handling; an external vault keeps scope smaller | Assessment recurring each cycle; scoping work one-time |
| Penetration testing | Generally covered by the provider's own testing, confirm the scope you may test | Your own testing of the Hyperswitch deployment, vault and network paths, repeated after material change | Recurring, usually at least annually and after changes |
| Upgrades and patching | Handled by Spreedly as a service | Tracking Hyperswitch releases, testing, and rolling out upgrades in your environment | Recurring |
| Support and on-call | Spreedly support under your contract, confirm response terms | Internal on-call, or a retainer with an implementation partner for ongoing support | Recurring |
| Internal skills | Integration engineers for API calls and webhooks | Staff with Rust-based service, PostgreSQL, Kubernetes and PCI DSS skills to operate the platform | Recurring, the largest ongoing item |
How Spreedly's fees and the self-hosted stack are structured
When you buy from Spreedly, you pay a platform relationship that bundles several things: hosted orchestration, the vault that holds your payment methods, and the gateway connections that let one integration reach many processors. The standalone PCI DSS Level 1 payment vault, launched on July 15, 2026, adds network tokenization and credentials portable across 100+ payment providers. Your contract and order form define how these are priced, so ask Spreedly to itemize which of these components sit under each line, and whether vault, gateway and tokenization charges are billed separately or as one platform fee. Those line items decide which costs you can move in-house later.
Self-hosting Hyperswitch removes the licence line, because Hyperswitch is Apache 2.0 licensed. The costs move to infrastructure and operations: the Rust core app server with its Router and Scheduler services, PostgreSQL with a master and replica, Redis for caching and the scheduler queue, the card vault service, and the encryption service for key management. Each of these is compute, storage, backup and on-call effort that you or your implementation partner must size, monitor and patch. The Hyperswitch docs describe three vault models, and the choice matters most for cost. In the self-hosted, in-house PCI model, the docs state that the merchant is fully responsible for PCI DSS certification and data handling, so assessment and testing costs sit with you. Pairing self-hosted orchestration with an external PCI vault, such as VGS or Tokenex as the docs name, shifts card storage and part of that assessment scope to the vault provider, at the cost of a separate vendor contract. Confirm each vault model's fees and scope terms directly with the provider.
Before comparing totals, write down which Spreedly components you actually use and which vault model you would run. A quote from an implementation partner should separate one-time work (design, integration, card data migration, initial PCI DSS assessment and penetration testing) from recurring work (hosting, upgrades, monitoring, assessments and retesting). Ask for the cost of each Hyperswitch component, the vault model assumed, and who signs the PCI DSS responsibility matrix. The Hyperswitch self-hosting documentation is the natural starting point for sizing the components.
What moves the comparison as volume and scope change
Spreedly's fees and a self-hosted Hyperswitch stack scale on different inputs. The cards below show which inputs grow each side, so you can model your own volume, connector count, vault choice and resilience needs before comparing totals.
Transaction volume
Volume is the first input to model. On the Spreedly side, ask how platform fees and any per-transaction charges change at your projected monthly volume and whether tiers apply. On the self-hosted side, volume mostly grows compute, PostgreSQL storage and Redis capacity for the Router and Scheduler, plus gateway transaction fees, which you pay under either option. Model peak month, not average month, and confirm how your processors bill per call.
Number of gateways connected
Hyperswitch's README states it connects to more than 100 payment processors, including Stripe, Adyen, PayPal, Worldpay and Checkout.com. Connector count changes integration effort, certification and testing time per processor, and reconciliation work, but not the software license. Count the processors you need today and the ones you expect within two years, then confirm each connector's status and coverage in your target region with the Hyperswitch team before you assume it.
Vault model and PCI DSS scope
Hyperswitch documents three vault models. In the self-hosted, in-house PCI model, the merchant is fully responsible for PCI DSS certification and data handling, which adds assessment, scoping and penetration testing costs that recur every year. Pairing self-hosted orchestration with an external PCI vault narrows that scope but adds vendor fees. Your choice here moves the largest recurring compliance line, so decide it before you price the assessment.
Availability and failover for Router and Scheduler
The Router handles payment requests, and the Scheduler handles queued work, both backed by PostgreSQL with a master and replica and by Redis. Running these in high availability across zones adds infrastructure, monitoring and on-call hours that Spreedly's hosted service otherwise absorbs. Ask Spreedly for its uptime history and incident process, then define the recovery targets your payments team requires before you size the self-hosted cluster.
Team skills and operating model
A self-hosted stack needs staff who can run Rust services on Kubernetes or cloud, manage PostgreSQL and Redis, rotate encryption keys and respond to incidents. Those skills are a recurring internal cost unless you buy them through a retainer or fixed-scope implementation. Spreedly's hosted model moves much of this to the vendor. Estimate the hours your team can commit each month, and treat any gap as a line item.
Editions, add-ons and SSO requirements
Commercial pricing often depends on plan tier, add-on modules and features such as SSO or support levels, so ask Spreedly for the exact items in a quote. On the Hyperswitch side, the Control Center supports single sign-on through OpenID Connect only, with no SAML, no JIT or SCIM provisioning, and roles managed in Hyperswitch. If your identity provider requires SAML or automated provisioning, budget for integration work or a gateway layer, and confirm whether any hosted feature you use is available in the self-hosted build.
How to build the comparison with your own numbers
This sequence turns Spreedly's fees and your own volumes into a cost model for self-hosted Hyperswitch, so the break-even point rests on contract terms, quotes and internal figures rather than on published estimates. Each step names the input it produces and who must supply it.
Collect Spreedly contract terms and invoices
Finance or procurement pulls the current Spreedly order form, the fee schedule and at least three to twelve months of invoices. Record every recurring platform fee, per-transaction or per-API-call charge, vault or storage fee, add-on and overage line, and note which items the contract lets Spreedly change at renewal. Ask Spreedly in writing to confirm any fee that is unclear. The step is done when each invoice line maps to a named contract term.
Inventory gateways, volumes and card counts
Payments engineering lists every gateway and processor connected through Spreedly, the monthly transaction count by payment type, the stored payment method count, and the peak transactions per second. Include wallets and network tokenization in use. Projected volumes for the next budget cycle belong in a separate column. The output is a single table that every later cost line references, so no cost is modeled against a guessed volume.
Choose the Hyperswitch vault model
Architecture and security leads select one of Hyperswitch's three documented vault models: self-hosted with the native in-house PCI vault, self-hosted orchestration with an external PCI vault provider, or self-hosted orchestration with the SaaS Hyperswitch Vault. The choice drives the scope of the PCI DSS assessment, the migration path for stored cards and the vault hosting line. Document the decision with its reason, because the in-house model makes the merchant fully responsible for PCI DSS certification and data handling.
Price cloud infrastructure from your provider
The infrastructure owner runs the expected workload through the provider's own pricing calculator for the chosen cloud, covering Kubernetes nodes, PostgreSQL with a master and replica, Redis, load balancers, backups, logging and the vault hosting. Price production, staging and disaster recovery separately. Hyperswitch can run on Kubernetes with Helm charts on AWS, GCP and Azure, so compare at least the target cloud and note any data residency constraints. The output is a monthly infrastructure figure at current and projected volume.
Estimate implementation and migration from written scope
Request written quotes from implementation partners and internal engineering leads based on one agreed scope: gateway connections, routing rules, retry logic, reconciliation, Control Center configuration, single sign-on and cutover. Migration of stored credentials depends on Spreedly's documented export, which is generally processed within 2 weeks and includes one free export per merchant per receiving service, so confirm the receiving endpoint and any export fees with Spreedly. The output is a one-time cost line with its assumptions listed.
Add PCI DSS assessment and penetration testing quotes
Compliance leads request quotes from a qualified assessor for the PCI DSS assessment scoped to the chosen vault model, and from a testing firm for penetration testing of the payment environment. Ask each provider to state what is in scope, what evidence is delivered and whether reassessment is priced separately. Assessment reports come from independent assessors, not from the implementation partner. The output is recurring and one-time compliance lines that the model can compare with Spreedly's own compliance coverage.
Model staff time for upgrades and on-call
Engineering management estimates the internal hours for Hyperswitch upgrades, dependency patching, database maintenance, on-call rotation, incident response and quarterly vault key handling, using the release history in the project's GitHub releases page as a guide to upgrade frequency. Convert hours to loaded cost using internal finance figures. Include any retainer for ongoing support or upgrades as an alternative line. The output is a recurring staffing cost, which is usually the largest item to challenge.
Run the model and find the break-even point
Finance builds one spreadsheet that places Spreedly's recurring fees beside the sum of recurring infrastructure, compliance and staffing costs, and amortizes one-time implementation and migration costs over the period chosen. Run it at current volume and at projected volume, then calculate the transaction count where the self-hosted total equals the Spreedly total. Test sensitivity to staffing hours and infrastructure size. The check is complete when the reviewer can trace every figure to a contract, quote, invoice or internal assumption.
How the comparison differs by vault model
In the self-hosted model with the native Hyperswitch Vault, your organization runs the card vault service inside its own infrastructure. The Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling, so this model carries the largest scope. Cost shifts toward your own staff and infrastructure, and the vault cost line is effectively yours to build and run.
- Cost lines that appear: infrastructure for the vault and its encryption and key management components, hardened hosting, key custody procedures, and internal engineering time for vault operations.
- Cost lines that disappear: the per-vault or per-token fee that a hosted vault would charge.
- PCI DSS scope: your environment is in scope end to end, including the vault, the hosts, the network segments and the people with access to them.
- Recurring work: annual assessment support, patching, key rotation and access reviews recur as volume grows.
- Quote question: if you use an assessor or consultant, ask for the scope of controls covered, the evidence they will need, and whether re-assessment after each major change is included.
Confirm with your qualified security assessor how the assessment treats your vault, your key management and your hosting before you commit to this model.
In self-hosted orchestration with an external PCI vault provider, Hyperswitch runs your routing and orchestration while a third-party vault, such as VGS or Tokenex as named in the Hyperswitch docs, stores card data. This is a split model: the orchestration layer stays under your control and the card data sits with a provider that holds its own PCI DSS responsibilities. Cost moves from building a vault to paying a provider for vaulting.
- Cost lines that appear: the provider's vault subscription or usage fees, integration work to connect Hyperswitch to the provider, and vendor management effort.
- Cost lines that disappear: much of the internal vault infrastructure and the hardening work for card storage.
- PCI DSS scope: your scope is reduced for stored card data, but your systems that transmit or route card data remain in scope, so the reduction depends on the design.
- Recurring work: the provider's fees recur with volume, and you still maintain the orchestration stack.
- Quote question: ask the provider for its current attestation package, its data flow diagram, its fee units, export terms and the process for returning card data if you leave.
Have your assessor confirm the scope reduction against your actual data flows before you rely on it.
In self-hosted orchestration with the SaaS Hyperswitch Vault, your orchestration runs in your infrastructure while card storage uses the hosted Hyperswitch Vault. This keeps the orchestration layer under your control and moves card storage to a vendor-operated service. The cost profile is closest to a hosted vault, with the orchestration hosting still yours.
- Cost lines that appear: the vault subscription or usage charges from the SaaS vault, and integration work between your deployment and the hosted vault.
- Cost lines that disappear: the internal vault build and most vault-specific operations work.
- PCI DSS scope: the vault's own compliance posture sits with the service operator, but your integration and any systems handling card data in transit remain your responsibility.
- Recurring work: service charges recur with transaction volume, and integration changes follow each vault update.
- Quote question: ask for the service's current compliance documentation, the regions where card data is stored, the data export and deletion process, and how availability is measured.
Confirm with Hyperswitch which vault service version and deployment terms apply to your region before you plan around them.
Questions buyers ask before comparing cost
How much does self-hosted Hyperswitch cost compared with Spreedly?
The answer depends on which cost lines you count, because the two models price different things. Spreedly bills you for its platform, so its fees recur with your agreement and, in part, with your activity. Self-hosted Hyperswitch has no license fee because it is Apache 2.0 licensed, but you pay for the infrastructure it runs on, the staff or partner who operate it, the one-time build and migration, and the PCI DSS work if you hold card data yourself. Build a side-by-side model with each line as a separate row, then ask Spreedly for your current contract terms and fee schedule before comparing totals.
How long does a migration from Spreedly to Hyperswitch take?
The duration depends mainly on scope: how many gateways you re-point, whether you move stored cards, and how much traffic you phase across. Spreedly documents that exports to a receiving third party are generally processed within 2 weeks, so plan that wait into any card data move. Hyperswitch deployment itself is documented through Helm charts and cloud guides, but your own integration, testing and certification work sets the real timeline. Ask any implementation partner for a timeline tied to a written scope rather than a generic figure.
Can our internal team run self-hosted Hyperswitch without a partner?
Possibly, if you already operate Kubernetes, PostgreSQL with replicas, Redis and key management in production. Hyperswitch's architecture includes a Rust router, a scheduler, a card vault and an encryption service, so the skills you need span application operations, database administration and security. Check whether your team can handle upgrades, backups, incident response and sign-off on PCI DSS responsibilities. Many organizations split the work: internal staff own operations while an outside team handles the initial build, hardening and evidence.
Which costs grow as transaction volume increases?
Most of the cost growth comes from the components that scale with activity. With Spreedly, any per-transaction or usage-based charges in your agreement rise with volume, so confirm exactly which fees are fixed and which vary. With self-hosted Hyperswitch, compute, database capacity, Redis, logging and the processing fees charged by your gateways grow with traffic. Fixed items such as the initial build and the PCI DSS assessment largely do not change with volume. Ask your team to model each line against projected transactions at several volume levels.
Does a self-hosted vault put us in PCI DSS scope?
Yes, if you store card data yourself. Hyperswitch documents three vault models, and in the self-hosted, in-house PCI model the merchant is fully responsible for PCI DSS certification and data handling. If you pair self-hosted orchestration with an external PCI vault provider, such as VGS or Tokenex as named in the docs, your scope is typically reduced, but you still need to confirm with a qualified assessor which requirements apply to your architecture. Read the self-hosted and in-house PCI documentation before deciding the model.
What should we ask a consultant for in a fixed-scope quote?
Ask for a written scope that lists each deliverable, the environments covered, the gateways and processors connected, and the vault model chosen. The quote should separate one-time work from recurring work, such as upgrades, monitoring and support. Request the assumptions behind the effort, including who performs card data migration, who runs the penetration test and who prepares compliance evidence. DeployOpen plans, implements, hardens and documents self-hosted platforms in your infrastructure and works from fixed-scope agreements, so confirm each boundary in writing before work starts. DeployOpen does not issue audit reports or certifications.
Do we need ongoing support after the migration?
Most teams need some ongoing operational capacity, because Hyperswitch releases new versions and your gateways change their APIs. Decide whether your internal staff will handle upgrades, security patches, backup testing and vulnerability follow-up, or whether you want a retainer. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which can be scoped separately from the initial build. Check the current Hyperswitch releases page to estimate how often you would need to apply updates.
What the migration adds to the cost model
The one-time work is where the cost model shifts most, and it is the part finance teams most often underestimate. Four workstreams carry it: requesting Spreedly's documented export of vaulted payment methods to a PCI compliant receiver, standing up the Hyperswitch vault, re-pointing each gateway connection, and running old and new paths in parallel before traffic is phased over. Spreedly documents two export routes, a single card export or an encrypted batch file export, and states that batch exports are generally processed within 2 weeks, with one free export per merchant per receiving service. Confirm with Spreedly whether a second export to a different receiver carries a fee, because that decision changes the one-time line before any engineering starts.
Each workstream has a different payer. Your internal engineering and payments teams own the export request, the receiver's PCI scope and the gateway re-pointing. If you use Hyperswitch's self-hosted in-house vault, you carry the PCI DSS assessment and its evidence. If you choose an external PCI vault provider, that provider's onboarding and per-token charges enter the model instead. DeployOpen, if engaged, would be paid under a written fixed scope for the implementation, vault configuration, data handling and parallel-run support. Ask each party for a separate line item and a named deliverable so the quote can be compared with your own internal effort.
Parallel running is the cost most often omitted. For a period, you pay for two payment paths: Spreedly's recurring platform fees on traffic still routed there, and the hosting and operations of Hyperswitch on traffic already moved. Ask your team to define the traffic phasing plan, the exit criteria for each phase and the date the Spreedly contract ends, since notice terms in your agreement will decide how long the overlap lasts. For the step-by-step sequence, including export requests and gateway cutover, see the sibling topic on migrating from Spreedly to Hyperswitch.
How DeployOpen scopes a fixed-price Hyperswitch implementation
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 exit or a self-hosted Hyperswitch build, we start with a written scope that separates the orchestration tier from the card vault, so you can see exactly which components and controls are in your hands.
How we scope
- Inventory every Spreedly gateway connection, payment method type and downstream system that consumes tokens today.
- Agree which Hyperswitch vault model applies, since the in-house PCI model makes your organization fully responsible for PCI DSS.
- Record the written scope, deliverables and timeline before any work starts, because most engagements are fixed-scope.
How we build
- Deploy Hyperswitch on Kubernetes with Helm charts, or on AWS, GCP or Azure, inside your own accounts and network boundaries.
- Configure processor connections, routing and retries, and test each connector in a sandbox before live traffic reaches it.
- Set up PostgreSQL with a master and replica, Redis, key management and the card vault, then test failover and recovery paths.
How we hand over
- Document the architecture, configuration, runbooks and the responsibility split between your team and the platform.
- Prepare the control and evidence set your assessor will ask for, without issuing any audit report or certification ourselves.
- Walk your engineers through upgrades, backups, key rotation and incident response before the engagement closes.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover, scoped in writing.
- Plan Hyperswitch version upgrades and test them against your gateway connections before they reach production.
- Ask for a quote built from your written scope, since DeployOpen does not publish a price list.
