Why open source payment orchestration for financial services carries more regulatory weight
When a payment service provider or acquirer decides to run Hyperswitch in-house, the routing logic is the smaller part of the job. Self-hosting makes the operator the party responsible for PCI DSS and third-party risk. A merchant that calls a hosted gateway hands much of its card handling to that provider. A processor that runs the orchestration layer, the card vault and the connectors itself owns those controls, and its customers and card brands will expect it to show how they work. Hyperswitch is the platform covered on this page, and its docs state that in the self-hosted, in-house PCI model the merchant is fully responsible for PCI DSS certification and data handling.
The processor's position changes the build in three ways. First, its own environment is likely to sit inside the cardholder data environment, so the assessment covers the Router, Scheduler, PostgreSQL, Redis and the card vault, not only the checkout flow. Second, it may act as a service provider to merchants, which means its customers will ask for its responsibility matrix and Attestation of Compliance. Third, as a payment institution it falls within DORA, so every connector, cloud host and key management provider becomes an ICT third party with a register entry, contract terms on data location and an exit plan. Confirm with your qualified security assessor which of your components are in scope before you commit to a design.
Before any other design choice, decide which vault model you will run, because it sets the PCI boundary and the size of your third-party register. Hyperswitch documents three options: the native in-house vault, an external PCI vault provider, or the SaaS vault. Each one moves responsibility differently, so the sections that follow assume you have made this decision first. Ask your team to write it down with the PCI and DORA consequences beside it.
What regulators and card rules require from open source payment orchestration
This table maps each requirement that applies to a self-hosted payment orchestration layer to its source and to what it means for the build. Read it by first confirming which regulator and card rules cover your licence and processor contracts, then checking each row against your architecture. The main takeaway is that self-hosting Hyperswitch moves PCI DSS, contract and third-party evidence onto your own team, so those obligations must be scoped before the build starts.
| Requirement | Source | What it means for the build |
|---|---|---|
| PCI DSS applies to processors and service providers that store, process or transmit cardholder data, or could affect the cardholder data environment | PCI SSC, PCI Data Security Standard | An orchestrator with a card vault, or one that routes card data, is in scope. Confirm with your acquirer or payment brands whether you must validate, and at what level. |
| PCI DSS v4.0.1 is the only active version | PCI SSC blog on v4.0.1 (published 11 June 2024) | Assess against v4.0.1 and track the future-dated v4.x requirements that became effective on 31 March 2025. Do not plan against retired v4.0. |
| Assessment is a Report on Compliance by a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance | PCI SSC FAQs 1004, 1015 and 1220 | The payment brands decide which route applies to you. Ask your acquirer which route it expects and who signs the Attestation of Compliance. |
| Self-hosted in-house PCI model places full PCI DSS responsibility on the merchant or operator | Hyperswitch docs, self-hosted and in-house PCI | If you run the native vault yourself, you own certification, key handling and card data controls. Budget for that assessment and its evidence in the design phase. |
| Register of information on all ICT contractual arrangements | DORA Article 28(3), Regulation (EU) 2022/2554 | For EU payment institutions, every cloud host, Hyperswitch support contract, HSM vendor and processor interface must appear in the register. Confirm your entity's status under DORA with your national competent authority. |
| ICT contracts must state service locations, data processing locations, advance notice of changes and data return on termination or insolvency | DORA Article 30(2) | Write these terms into hosting, HSM and support contracts. Data location for the vault and transaction logs must match the locations you declared. |
| Documented, tested exit strategies for ICT services supporting critical or important functions | DORA Article 28(8) | Payment routing is usually a critical or important function. Keep a tested plan to move tokens, routing rules and processor connections to another orchestrator or vault. |
| Multi-factor authentication for any individual accessing any information system, unless an equivalent control is approved in writing | FTC Safeguards Rule, 16 CFR 314.4(c)(5) | Applies if you are a non-bank under FTC jurisdiction. Cover Control Center and infrastructure access. Note that Hyperswitch Control Center SSO uses OpenID Connect only, with roles managed in Hyperswitch. |
| Annual penetration testing and vulnerability assessments at least every six months, absent effective continuous monitoring | FTC Safeguards Rule, 16 CFR 314.4(d)(2) | Schedule external and internal tests of the orchestrator, vault and Kubernetes cluster. Confirm with counsel whether your monitoring meets the continuous monitoring exception. |
| Customer Security Controls Framework controls, with independent assessment and annual attestation | Swift Customer Security Controls Framework v2026 (32 controls, 26 mandatory and 6 advisory) | Applies only if your operator uses Swift messaging. Map the orchestrator, vault and admin paths to the mandatory controls and attest annually in KYC-SA. |
Which Hyperswitch vault model fits a payment institution
The vault model decides how much of the cardholder data environment your institution runs, and who signs the Attestation of Compliance. Each option below changes scope, key custody and third-party risk in a different way, so the choice should be made before the connector and routing design starts.
Self-hosted in-house Hyperswitch Vault
The native Hyperswitch Vault runs inside your own infrastructure, so card storage, encryption and key handling sit within your environment. The Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling in this model. Your institution would carry the full assessment, and your Qualified Security Assessor or self-assessment would cover the vault, the HSM-backed key management and the surrounding segmentation. Confirm with Hyperswitch and your assessor which vault components fall in scope and who signs your Attestation of Compliance.
Self-hosted orchestration with external PCI vault
Hyperswitch still runs your routing and orchestration, while an external PCI vault provider such as VGS or Tokenex stores the card data. Cardholder data stays out of your core environment, which usually reduces the systems that fall inside the cardholder data environment. Your institution still signs its own Attestation of Compliance for the orchestration layer, and the vault provider's attestation covers its part. Ask the vendor for its current Attestation of Compliance and the responsibility matrix, and confirm how tokens flow back to Hyperswitch.
Self-hosted orchestration with SaaS vault
In this model Hyperswitch runs in your environment while card storage uses the SaaS Hyperswitch Vault. Your scope shrinks for card data, but the vault is a third-party service that your DORA register and exit planning must cover. Ask where the vault stores data, which regions it uses, how keys are managed, and how stored tokens can be exported if you leave. Review the provider's attestation and the contract terms for data location and return on termination.
Least cost routing support
Least cost routing depends on how far Hyperswitch's routing features reach for your processor mix, fee data and rule logic. Routing decisions also change which processors receive cardholder data, so each route adds a third party to your scope and to your DORA register. Before you commit to a vault model, confirm with Hyperswitch whether least cost routing is supported for your processors and how fee data is fed into rules. Test routing changes in a non-production environment before going live.
Kill Bill as adjacent option
Kill Bill is an open source subscription billing platform licensed under Apache-2.0, and it only belongs in this decision if your institution bills its own merchants on recurring terms. It sits beside the vault choice rather than replacing it, and it adds its own data flows, retention needs and audit scope. If you use it, confirm how billing records link to tokens in the vault and which system holds the authoritative transaction record. Leave it out of scope if you only route payments for others.
How open source payment orchestration rollouts reach processor go-live
The sequence runs from a signed PCI DSS scope statement through vault, environment, connector, access and reconciliation work to a phased go-live that keeps a tested fallback to existing processors. Each phase closes with a document or test result that the next phase depends on.
Confirm scope and PCI DSS boundary
Before any build starts, the organization and its implementation partner map every system that will store, process or transmit cardholder data, including the Hyperswitch core, the card vault, the Control Center, checkout SDKs, logs, backups and each processor connection. Compliance, security and payments owners then agree which entity is responsible for PCI DSS validation under the applicable payment brand rules. The output is a signed scope statement with a network diagram that shows the cardholder data environment and its segmentation boundary. The step is done when every data flow in the diagram is traced to a named owner and no unlisted system touches card data.
Decide the vault model
The team chooses between the native Hyperswitch Vault in an in-house PCI model, self-hosted orchestration with an external PCI vault provider, or self-hosted orchestration with the SaaS Hyperswitch Vault. The choice sets how much PCI DSS work stays in-house, so it is taken with the assessor and the risk owner, not by engineering alone. The output is an architecture decision record covering the vault model, key custody, the data retained after authorization and the provider responsibility matrix. The step is done when the record is approved and each PCI DSS requirement has a named owner under the chosen model.
Build the environment on Kubernetes with Helm
The partner deploys the Router, Scheduler, PostgreSQL with a master and replica, Redis, the card vault and the Control Center using the Hyperswitch Helm charts on the organization's chosen Kubernetes platform, inside its own cloud account or data center. Key management, HSM connectivity and network policies are configured to match the scope statement. The output is a versioned infrastructure-as-code repository, a deployment runbook and a hardening baseline checked against the agreed controls. The step is done when the non-production environment passes health checks and the security baseline review, and every change is recorded in change management.
Configure connectors and routing rules
The team connects each processor and payment method in scope, sets routing, retry and fallback rules by market, currency and entity, and documents which processor owns each contract and settlement account. Connector credentials are held in the secrets store and never in configuration files. The output is a tested routing rule set with a version history and a connector inventory that lists each processor's data location. The step is done when test transactions for every rule path produce the expected route, and the rule set is approved by the payments owner.
Design SSO and access control
The 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 the identity provider. The partner documents how users are invited, how privileged roles are approved and reviewed, and how multi-factor authentication applies at the identity provider. Access to the vault, keys and production configuration is kept separate from routine dashboard access. The output is an access design record and a role matrix reviewed by the security team. The step is done when a sample of accounts shows each role matches the matrix and every administrative action is logged.
Test routing, vaulting and reconciliation
Testing covers authorization, refunds, voids, tokenization, failover between processors and the migration or import of any stored tokens, run against sandbox processors before any live traffic. Reconciliation is tested by matching processor settlement files against Hyperswitch records and ledger entries, with exceptions routed to a named queue. Penetration testing and vulnerability assessment of the cardholder data environment run before go-live. The output is a test report, a reconciliation report showing match rates and exception handling, and a penetration test summary with closed findings. The step is done when unresolved high-severity findings are either fixed or formally accepted by the risk owner.
Run a phased go-live with a tested fallback
Traffic moves in stages, starting with a small share of one market or entity, while the existing processor path stays active and tested as the fallback. The team sets go and no-go criteria for authorization rates, reconciliation breaks and error levels before each stage, and records who can halt the switchover. Rollback to the previous path is rehearsed before live traffic moves. The output is a go-live record with stage approvals, the rollback test result and a post-stage reconciliation report. The step is done when the full traffic share runs on Hyperswitch for an agreed period, the fallback has been exercised successfully, and the scope statement is updated to reflect the production state.
Which components a processor must secure and operate
A self-hosted Hyperswitch deployment is several services, not one application. Each component below holds, moves or controls access to payment data or payment availability, so each one shifts part of the PCI DSS, DORA and operational burden onto the processor that runs it.
Router and Scheduler app services
Router handles the payment API, routing, retries and vaulting calls, while Scheduler runs asynchronous work through its Producer and Consumer roles. Both sit on the authorization path, so a fault in either one can stop or delay payments. Confirm how many replicas each runs, how the Scheduler queue behaves during a Router outage, and which team owns on-call for each.
PostgreSQL with master and replica
PostgreSQL holds transaction records, merchant configuration and routing state, so it is the primary store for reconciliation and audit evidence. The documented master and replica setup helps with availability, but replica lag can affect reads used for status checks. Confirm backup, point-in-time recovery, encryption at rest and which data, if any, lands in the card vault rather than in this database.
Redis for cache and scheduler queue
Redis serves as the cache and as the queue backing the Scheduler. Because it carries in-flight work, a loss of Redis can drop or duplicate scheduled operations such as retries and reconciliation tasks. Confirm persistence settings, failover behavior, network access controls and whether any payment-related values are written to it.
Card vault as a separate Rust service
The card vault, also called the locker, is a separate Rust service that stores card data, and the architecture docs describe it as built for PCI DSS requirements. Isolating it lets a processor limit the cardholder data environment to this service and its network paths. Ask for the vault's network segmentation, who can reach its API, and how its own deployment is tested for PCI DSS scope.
Encryption service for key management
The encryption service handles key management for data Hyperswitch encrypts. Key custody decides who can decrypt stored card data, so this component belongs in the key management design review. The supplied facts do not confirm whether keys can be held in an HSM. Confirm with Hyperswitch and your HSM vendor how keys are generated, wrapped, rotated and backed up, and who holds key ceremony duties.
Control Center access controls
The Control Center is the merchant dashboard for configuration and operations. It supports single sign-on through OpenID Connect only, with no SAML, no just-in-time or SCIM provisioning, and users must be invited first. Roles are managed in Hyperswitch rather than mapped from your identity provider, so each joiner, mover and leaver needs a manual step. Plan access reviews and multi-factor enforcement at the identity provider.
What auditors and card brands ask a processor to produce
This table maps each evidence item an assessor, card brand or regulator typically requests from a processor running self-hosted Hyperswitch to the party that asks for it and the component that generates it. Read it as a preparation list: DeployOpen prepares the evidence, while independent assessors and certification bodies issue the reports and attestations. Most gaps appear in scope statements, change logs and the register of information, so start those early.
| Evidence item | Who asks for it | Component that produces it |
|---|---|---|
| PCI DSS scope statement and segmentation test results | QSA, acquirer and card brands | Network diagrams, cardholder data environment inventory and segmentation test records for the Hyperswitch Router, Scheduler and card vault |
| Report on Compliance or Self-Assessment Questionnaire with Attestation of Compliance | Acquirer, payment brands and the processor's own board | Issued by a Qualified Security Assessor (Report on Compliance) or the merchant's own self-assessment, using evidence from the vault and key management records |
| DORA register of information entry for the orchestration provider | Competent authority and internal risk function under DORA Article 28(3) | Contract register maintained by the processor, listing the Hyperswitch deployment, hosting locations and any external vault or connector providers |
| Vault access and change logs | QSA, internal audit and FTC Safeguards reviewers | Card vault and encryption service audit trails, plus access approvals for PostgreSQL and Redis administrators |
| Routing rule change records | Internal audit, SOX reviewers and acquirer risk teams | Change tickets and version-controlled routing configuration in the Control Center, with approval and rollback history |
| Reconciliation reports across processors | Finance controllers, external auditors and processors | Reconciliation module output comparing orchestrator transaction logs with processor settlement files, with exceptions and sign-off |
| Penetration test and vulnerability assessment reports | FTC Safeguards reviewers and card brands | External testing firm reports, at least every six months where continuous monitoring is not in effect under 16 CFR 314.4(d)(2), tracked with remediation dates |
| Swift Customer Security Controls Framework attestation (where the processor uses Swift) | Swift via the KYC-SA application and correspondent banks | Independent assessor's assessment of the 32 Swift controls, with evidence produced from the deployment |
How DORA third-party risk applies to a processor's own orchestration stack
A processor running Hyperswitch in-house has to treat its ICT suppliers as third-party providers under DORA. Regulation (EU) 2022/2554 has applied since 17 January 2025 to a wide list of financial entities, including payment and e-money institutions, and it applies directly without national transposition. The Hyperswitch core, the card vault, the PostgreSQL and Redis tiers, the Kubernetes platform, the HSM or key service behind the encryption service, and any external PCI vault or connector API all sit in the chain of ICT services. Start by listing each of them as a contractual arrangement. Article 28(3) requires a register of information covering all such arrangements, and the register should name the service, the provider, the functions it supports and the locations where data is processed. Confirm with counsel whether any Hyperswitch component is supplied under a commercial support contract, since that changes what must appear in the register.
Article 28(8) asks for more than a list. For ICT services that support critical or important functions, the entity must hold documented exit strategies and transition plans, and those plans should be tested. For an orchestration layer, the practical question is how routing, stored tokens and connector credentials would move to another orchestrator or back to direct processor integrations if the self-hosted stack had to be replaced. Article 30(2) adds contract terms: every ICT services contract must state where services are provided and data processed, require advance notice of location changes, and cover data return on insolvency or termination of the provider. Review each support, managed hosting and vault contract against these points before go-live.
On testing, DORA does not offer a certification scheme. The only attestation it names is that a threat-led penetration test met the requirements of Article 26(7), and the ECB states that the core requirements of DORA TLPT and TIBER-EU are identical. Confirm with your competent authority whether a TLPT obligation applies to your entity and which framework the authority expects you to follow, since that determines how a test of the card vault and routing layer is scoped and evidenced. A test that covers only the public checkout API will not satisfy either framework if the vault and key management services are left out.
What financial services teams ask before they run Hyperswitch in-house
What drives the cost of running Hyperswitch in-house?
The cost depends mostly on the vault model, the size of your PCI DSS assessment scope, the number of processor connectors, how you hold keys, and who operates the platform day to day. Self-hosting moves costs into your own budget: Kubernetes infrastructure, database and cache operations, the card vault, any hardware security modules, connector setup, and your PCI DSS assessment. The Hyperswitch docs state that with the self-hosted, in-house PCI model the merchant is fully responsible for PCI DSS certification and data handling, so that work is yours to fund. Ask any partner for a quote that lists each component separately, with who pays for it and whether it recurs.
Which costs are one-time and which recur?
One-time costs usually include the initial architecture, connector and routing setup, vault migration or import, integration with checkout and reconciliation, and the first PCI DSS assessment of your environment. Recurring costs include infrastructure, licenses or support for any third-party components, HSM service fees, annual PCI DSS validation, platform upgrades, monitoring, on-call operations, and processor-side changes as you add markets or methods. Ask the quote to split these into a one-time block and a recurring block so finance can plan both. Where a SaaS vault is involved, check whether its platform fees are charged per transaction, per stored card, or as a flat amount.
Does a SaaS vault change the PCI DSS assessment?
It can. Hyperswitch documents three vault models: self-hosted with the native Hyperswitch Vault (in-house PCI), self-hosted orchestration with an external PCI vault provider such as VGS or Tokenex, and self-hosted orchestration with the SaaS Hyperswitch Vault. The first model keeps the card vault inside your cardholder data environment, which widens your assessment. The other two can reduce the data your systems hold, but they do not remove your obligations: you still need to manage the service providers involved and confirm how cardholder data flows through your environment. Ask your assessor to confirm the scope under each model before choosing one.
How long does a Hyperswitch rollout take?
Duration depends on the number of processors, payment methods and markets, how many checkout flows and systems depend on the payment layer, the chosen vault model, and how fast your processors and assessors respond. No fixed duration applies to every institution, so ask for a timeline in the written scope, with phases for architecture, connector build, testing, vault migration, parallel running and cutover. Routing changes and PCI DSS evidence usually take longer than the software setup itself. Engagements are typically fixed-scope, so agree the timeline and deliverables in writing before work starts.
Can an internal team run Hyperswitch alone?
An internal team can run it alone if it has skills across Kubernetes, PostgreSQL and Redis operations, Rust-based services, payments engineering, security engineering and on-call support, plus time for PCI DSS evidence work. Many institutions find that gap in the first year, especially around upgrades and key custody. A common middle path is to keep day-to-day operations in-house while a partner handles implementation, hardening, testing and documentation. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted open-source platforms in your own infrastructure, and offers ongoing support as a retainer. Ask any partner which parts they would run and which stay with you.
What does the work need from our side?
The work needs named owners on your side before it starts. Typically that means:
- Processor contract owners who can confirm connector terms, data location and change notice
- A scope owner who can define which systems join the cardholder data environment
- Security and compliance staff who can review segmentation, key custody and the PCI DSS evidence
- Platform engineers who can provide Kubernetes, network and database access in your environment
DORA Article 30(2) requires ICT contracts to state where services are provided and data processed, so processor and provider contracts need to be checked early.
How do HSMs and key custody change the cost?
Key custody affects both cost and risk because the Hyperswitch encryption service handles key management, and card data sits in the card vault. Hardware security modules add purchase or service fees, rack space or cloud service charges, and specialist administration for key ceremonies, backup and rotation. Keys held in software reduce that spend but shift more assurance work to your own controls. Ask the quote to state which keys sit in an HSM, who administers it, how backups are held, and what a key rotation costs in effort. Confirm the HSM requirements with your assessor and your own risk team.
What should we check for connectors and routing before we sign?
Check each processor connector against the markets and payment methods you need, then confirm how routing rules are changed, tested and approved. Hyperswitch documents more than 100 payment processors, but coverage is not the same as a working connector for your account, currency or region, so confirm each one with the processor. Ask how cost per connector is priced, how routing changes are tested before release, and how failover is tested. For least cost routing, ask for a written routing policy and reconciliation output that show the results.
What to ask a payment orchestration partner before signing
Ask for the written scope before any quote. DeployOpen does not publish a price list, so the scope document is what makes two proposals comparable. Ask the partner to list every Hyperswitch component in scope, including the Router, the Scheduler, the card vault service, the encryption service, the Control Center and the client SDKs, and every processor connector to be configured. Then ask how each routing rule is written, who approves changes to it, and how a change is tested in a non-production environment against sandbox or test credentials before it reaches live traffic. A good answer names the test evidence kept for each routing change, not only the general method.
Ask who holds the keys before anyone talks about architecture. Ask where the encryption service keys are generated, where they are stored (a hardware security module or a cloud key service), who holds administrative rights over the card vault database and the key store, and whether those roles are separated. Ask how Control Center access is handled: the Hyperswitch docs describe OpenID Connect single sign-on only, with no SAML, no just-in-time or SCIM provisioning, and roles managed inside Hyperswitch, so ask how joiners and leavers are removed from the platform in practice. Request the PCI DSS responsibility split in writing, with each party's duties listed by requirement area, because the Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling in the in-house model.
For DORA, ask how the register of information entry for the orchestration platform and each processor contract will be produced, which fields the partner fills in, and who keeps the register current. Ask for the exit strategy and transition plan that DORA Article 28(8) expects for services supporting critical or important functions, including how stored tokens and processor connections would move to another platform. Ask how reconciliation across processors is evidenced: which reports are produced per processor, how unmatched transactions are handled, and how the output is retained. Finally, ask how Hyperswitch upgrades are rolled out without payment downtime, including the staging environment used, the rollback path and the test scripts run before cutover. Confirm each answer against the signed scope, not a sales call.
How DeployOpen scopes, builds and supports payment orchestration for regulated processors
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For payment orchestration, that means a written scope that separates Hyperswitch configuration, card vault isolation and PCI DSS responsibility before any connector is switched on. Engagements are fixed-scope, with ongoing support available as a retainer.
How we scope
- Written scope lists the processors, payment methods and markets to connect, agreed before work starts.
- Scope records which vault model applies, in-house PCI or an external PCI vault, and who holds each PCI DSS responsibility.
- Scope names the evidence the client needs for its assessor, including the Attestation of Compliance path and DORA register entries.
How we build
- Hyperswitch is deployed on Kubernetes in the client's own cloud account, data center or air-gapped network.
- Connectors, routing rules and retry logic are configured and tested against sandbox processors before any live traffic.
- Card vault, encryption service, PostgreSQL and Redis are hardened, with key management integrated to the client's HSM design.
How we hand over
- Deliverables include architecture documentation, runbooks for routing changes, and records of how each control was tested.
- Reconciliation and reporting flows are documented so finance and operations teams can trace each transaction across processors.
- Client teams receive written procedures for upgrades, backups and exit from each processor, aligned to DORA exit strategy expectations.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers, scoped in writing.
- Security testing covers applications, APIs and infrastructure around the orchestration layer, with findings tracked to closure.
- Each Hyperswitch release is reviewed for impact on connectors, the vault and PCI scope before it is rolled out to production.
