Why self-hosted payment orchestration is an EU data sovereignty decision
Self-hosting Hyperswitch in EU infrastructure can keep the card vault, transaction data and routing logic on EU soil, but processor choice and remote access decide whether that holds. An EU payment business or merchant that runs its own orchestration layer still sends card and payer data to every processor, acquirer, fraud tool and support vendor in the route. Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions, and the EDPB's Guidelines 05/2021 treat storage in a cloud outside the EEA and remote access from a third country, even only viewing data on a screen for support, as transfers. The first audit question is therefore not where the software runs, but where each copy of the data is held and who can see it.
This differs from a generic orchestration project because the sovereignty question is decided at three points that a standard integration plan may not cover: the vault, the processor list and the operator access model. Hyperswitch documents three vault models, and in the self-hosted, in-house PCI model the merchant carries full PCI DSS responsibility for the card vault, while the external vault options move card storage to a third party with its own location and access terms. Confirm with the vendor, in writing, which vault model fits your data map, where the encryption service keys are generated and stored, and whether any vendor support can reach production data. Hyperswitch fits as the orchestration core, with its Rust router, card vault and encryption service in your own cluster. The surrounding tools, such as PostgreSQL, Redis and your identity provider, are supporting components, and each needs its own location check.
Processor selection is where many EU deployments lose their sovereignty position. Hyperswitch connects to more than 100 processors, but a processor headquartered outside the EU may still receive data under third-country law. The EDPB's Example 12 notes that an EU processor subject to extraterritorial third-country law is not itself a transfer, but compliance with a third-country authority request would be, so you should assess that exposure before engaging it. Relevant instruments include the US CLOUD Act provision at 18 U.S.C. 2713 and the EU-US Data Privacy Framework, whose adequacy decision is under appeal as Case C-703/25 P. Ask each processor for its data location commitments, its government access policy and the standard contractual clauses under Commission Implementing Decision (EU) 2021/914 that it will sign, and record the answers before routing a single live payment.
Which EU rules set the data location requirements
This table maps each EU rule to what it asks of card vault placement, support access and processor contracts in a self-hosted orchestration stack. Read each row as a question to answer before choosing hosting, support model and contract terms. The main takeaway is that location is only one factor: who can access data, under which foreign law, and how you can leave a provider all shape the design.
| Rule | What it requires for payment data | What to confirm or evidence |
|---|---|---|
| GDPR Article 44 and Chapter V | Every transfer of personal data to a third country, including onward transfers, needs a Chapter V basis. Fines for Articles 44 to 49 infringements reach EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c). | Map every flow of payer data, including logs, support tickets and backups, and record the transfer basis for each third-country destination. |
| EDPB Guidelines 05/2021 | Remote access from a third country, even only viewing data on screen for support, counts as a transfer. Storing data in a cloud outside the EEA also counts. | Confirm where vendor and integrator support staff sit, and whether remote sessions can display vault or transaction data. |
| GDPR Article 48 and third-country orders | A foreign court or authority order to disclose personal data is enforceable only if based on an international agreement in force with the Union or a Member State. | Ask each processor how it handles foreign authority requests and whether it commits to challenging or notifying you of them. |
| Schrems II and EDPB Recommendations 01/2020 | Standard contractual clauses remain valid, but where a provider must access data in the clear and foreign powers go beyond what is necessary, the EDPB cannot envision an effective technical measure. | Assess the destination's surveillance law before choosing a processor, and document the transfer impact assessment. |
| EU-US Data Privacy Framework status | Adequacy under Implementing Decision (EU) 2023/1795 applies only to US organizations on the Data Privacy Framework List, and an appeal in Case C-703/25 P is pending. | Check the list entry of each US provider, and plan a fallback transfer basis in case the framework is changed by the appeal. |
| US CLOUD Act reach | 18 U.S.C. 2713 requires US providers to preserve or disclose data in their control, wherever it is stored, so a US-parented vendor may face orders for EU-hosted vaults. | Ask whether the vendor or operator is US-controlled, and who holds the keys to decrypt stored card data. |
| DORA concentration risk | Financial entities must manage third-party ICT concentration risk, so reliance on one orchestration, vault or processor provider needs assessed exit and substitution options. | Document the exit plan, alternative processors per market and where the vault data could be moved. |
| Data Act Article 32 and switching rights | Providers must take measures against third-country governmental access to non-personal data held in the Union. Customers may switch to another provider or on-premises infrastructure, with switching charges banned from 12 January 2027. | Write switching assistance, data export formats and transition periods into contracts, and confirm the provider's Article 32 measures in writing. |
Which open-source platforms fit an EU-hosted orchestration layer
An EU-hosted orchestration layer depends on three decisions: which orchestration platform runs the payment routing, where the card vault and its keys sit, and whether the billing and processor tools around it stay inside the same jurisdiction. The cards below cover each choice and what to verify before committing.
Hyperswitch as the orchestration core
Hyperswitch is an Apache-2.0 composable payments platform with a Rust core app server that handles routing, retries, vaulting and observability. It connects to more than 100 processors, and its Helm charts run on Kubernetes, so the whole stack can be deployed in EU cloud accounts or data centers. Check which processors and payment methods your markets need, and confirm the version you deploy, since the latest supplied release is v1.128.0.
Self-hosted in-house PCI vault
The native Hyperswitch Vault runs in your infrastructure, so primary account numbers are stored in EU systems that you control. This keeps the card vault location inside your jurisdiction, but the Hyperswitch docs state the merchant is fully responsible for PCI DSS certification and data handling. Ask who operates the vault, where its encryption keys are held and how access to the vault is logged.
External PCI vault provider
In this model, Hyperswitch orchestrates while an external PCI vault provider, such as VGS or Tokenex, holds the card data. The location question moves to the vault vendor, so you must confirm where that provider stores and processes PAN, whether it has EU hosting, and whether any of its support or administrative access occurs from a third country. Put those terms into the contract before go-live.
SaaS Hyperswitch Vault
Self-hosted orchestration can also use the SaaS Hyperswitch Vault while your routing logic stays on your own infrastructure. Card data then sits in a hosted service, so you need the vault's hosting region, subprocessors and access locations written down before any payer data is sent. This option reduces the in-house PCI burden but makes the vault a third-party location that your sovereignty position must cover.
Encryption service and key management
The Hyperswitch repository lists a separate encryption service for key management alongside the card vault. Where those keys are generated, stored and rotated decides whether a foreign authority or a hosted provider could read stored PAN. Confirm that key custody sits in EU infrastructure, that the key service is isolated from the orchestration app servers, and that a hardware security module option is available for your environment.
Control Center access and Kill Bill adjacency
The Hyperswitch Control Center is the merchant dashboard, and it supports single sign-on through OpenID Connect only, with no SAML, JIT or SCIM provisioning. Users must be invited and roles are managed inside Hyperswitch. If recurring billing is needed, Kill Bill (Apache-2.0, killbill-0.24.22) can run alongside it for subscription logic, but it adds a second system with its own data location to assess.
Choosing a vault model for EU data location
In the self-hosted model with the native Hyperswitch Vault, card data is stored in the card vault that runs in your own infrastructure, alongside the orchestration services. The Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling in this model. Data location is the easiest to control here because your cloud account, cluster and database sit where you choose, including within the EU.
- Storage location: Card data, the encryption service keys and the vault database remain in the environment you operate, so you can confine them to EU regions.
- PCI DSS responsibility: Your organization owns the assessment, the key management design and the controls around the vault, and you cannot hand these to the vendor.
- Transfer analysis: Remote access by support staff or a partner located outside the EEA, even only viewing a screen, can count as a transfer under EDPB guidance, so access paths need the same scrutiny as storage.
- Operational load: Patching, backups, key rotation and monitoring of the vault become your recurring tasks.
- Cost drivers: Assessment effort, infrastructure and staff time scale with the size of the cardholder environment.
Confirm with your QSA and your own environment which teams can reach the vault, from which countries, and how that access is logged before you commit to this model.
In the self-hosted orchestration model with an external PCI vault, such as VGS or Tokenex, Hyperswitch runs in your infrastructure but card data is stored by the external provider. Your orchestration layer then handles tokens rather than primary account numbers in most flows. The vault provider's processing location, subcontractors and access model now determine much of the transfer analysis, so the contract is part of the architecture.
- Storage location: Card data sits with the vault provider, so the question becomes whether that provider stores and processes in the EU, and whether any backup or disaster recovery copy leaves the EEA.
- PCI DSS responsibility: The vault provider takes on a share of the cardholder data environment, but you still need written evidence of its attestation and the responsibility split for each requirement.
- Transfer analysis: Where the provider is a non-EU entity or is subject to third-country law with extraterritorial reach, EDPB guidance says you should assess exposure to third-country authority requests before engaging it.
- Contract terms: Processing locations, sub-processor lists, notice of location changes and audit rights should be written into the agreement.
- Cost drivers: Per-token or platform fees from the provider recur, and they scale with transaction volume and stored credentials.
Confirm in writing the processing and storage location of every vault region, backup site and support path before the provider is approved.
In the self-hosted orchestration model with the SaaS Hyperswitch Vault, your orchestration runs in your environment but card storage is handled by the vault service operated by the vendor. This model reduces the infrastructure you run for the vault, but it moves card data out of your direct control. Whether the stored data remains in the EU is a fact to establish with the vendor, not one to assume from the self-hosted deployment.
- Storage location: The card data resides in the vendor-operated service, so you need the hosting region, replication targets and backup locations in writing.
- PCI DSS responsibility: Responsibility is shared, and you must map which controls the vendor covers and which remain on your side, including the orchestration environment.
- Transfer analysis: Vendor support staff, sub-processors and any remote administration from outside the EEA may each create a transfer that you must document and cover with appropriate safeguards.
- Exit planning: The Data Act gives customers switching rights for data processing services, which is relevant when you plan an exit from a vault service, so confirm the vendor's export format and timing.
- Cost drivers: Platform fees and volume charges recur, and they depend on the vault features and regions you select.
Confirm the storage region, sub-processors and support access locations with the vendor in writing before you route live card data to it.
Where payer data moves and where transfers happen
Every hop that touches payer data is either inside the EU or a potential transfer, and the question for each one is who can read the data in the clear from where. Start from the checkout page and follow the request through the Hyperswitch Router, the card vault, the encryption service, the processor, the webhook back into your systems, the reconciliation jobs and finally support access. The Router and scheduler, PostgreSQL and Redis are the components that hold or cache payment state, so their hosting region matters as much as the vault. Mark each hop on a diagram before you pick any processor, because the answer depends on where you run the cluster, not on the vendor's brand.
Checkout and the Router sit inside your EU cluster if you deploy there, but the browser SDK, any third-party script on the checkout page and any log shipper can send card or payer fields to other regions. The card vault (locker) and the encryption service are the highest-value hops: confirm that their keys, backups and replicas stay in the EU. Outbound calls to the processor are transfers whenever the processor or its support function sits outside the EEA. Webhooks and reconciliation exports are often overlooked; they move transaction records into finance and analytics tools that may run in a third country.
Support access is the hop most teams misclassify. The EDPB's Guidelines 05/2021 (version 2.0) state that remote access from a third country is a transfer even when the person only views data on a screen for support or administration. So a support engineer in another region who opens a masked transaction, a log line or a vault record through a remote session counts, regardless of whether the data is ever downloaded. The same guidelines treat storage in a cloud outside the EEA as a transfer, which covers managed databases, object-storage backups and SaaS observability tools. Ask your team to list every person and tool with a route to each hop, including vendor engineers during incidents, and to record the location of each.
Choosing EU acquirers and processors without hidden transfers
Each processor in the payment route can move payer data outside the EU, through storage, remote access or a legal obligation to disclose. The four cards below cover the decisions that expose those transfers and the evidence to collect before contracts are signed. Work through them for every acquirer, processor and vault in the route, including the ones that look European.
Acquirer and processor location
Start by mapping where each acquirer and processor stores, processes and accesses payer data, not only where its legal entity is registered. A European entity can run its platform in a non-EU region, keep backups abroad or route support through staff in another country. Ask each provider for the data center regions for storage, backups, logs and fraud scoring, and for the locations from which its staff can view live transaction records. Record the answers against each connector in your orchestration layer.
Processors under third-country law
Under EDPB Guidelines 05/2021 (Example 12), an EU processor subject to a third-country law with extraterritorial reach is not itself a transfer. Complying with a request from that country's authority, however, would be one, so the exposure has to be assessed before you engage the processor. Ask whether the provider receives foreign access requests, how it responds to them, and whether it has committed to challenge overbroad requests. Ask counsel to document the assessment for each such processor.
Standard contractual clauses under Decision 2021/914
Where a processor or sub-processor sends data to a third country, the transfer needs a valid transfer mechanism. Standard contractual clauses adopted under Commission Implementing Decision (EU) 2021/914 are the usual mechanism, and the Schrems II judgment held that they remained valid while requiring a case-by-case assessment of the destination. Confirm that the correct module applies to each party's role, that the annexes list the actual data categories and locations, and that the provider commits to supplementary measures where local law conflicts with the clauses.
Data Privacy Framework reliance
Some US processors rely on the EU-US Data Privacy Framework rather than standard contractual clauses. Commission Implementing Decision (EU) 2023/1795 covers only organizations on the Data Privacy Framework List, and an appeal against the General Court's September 2025 judgment upholding it is pending as Case C-703/25 P. Check whether the specific legal entity you contract with is listed, and treat DPF-only reliance as a provisional basis. Keep standard contractual clauses signed as a fallback so the route can continue if the adequacy decision changes.
Sub-processor chains and fallback routes
A processor that passes the first four checks can still move data through sub-processors such as cloud hosts, fraud engines, tokenization services or customer support tools. Request the full sub-processor list with locations, the notice period for changes, and the right to object. Map each sub-processor to the connectors in your route, then test the failover path so that a processor exit does not force payer data into a non-EU route. Record the switching plan as part of the DORA third-party register.
How DORA concentration risk applies to the orchestration layer
What does DORA require for ICT third-party risk and concentration?
DORA, Regulation (EU) 2022/2554, requires financial entities in its scope to manage ICT third-party risk as part of their ICT risk framework, including due diligence before contracting, contractual provisions, a register of information on ICT third-party arrangements, and assessment of concentration risk where several functions depend on the same provider. The regulation asks entities to consider whether a critical or important function relies on a single provider or on providers that are hard to substitute. Whether your entity is in scope, and which obligations apply to your licence type, is a question for your regulator or counsel. Read the text of Regulation (EU) 2022/2554 and confirm your classification before designing controls.
Why does one orchestrator in front of many processors create concentration risk?
A single orchestrator becomes a shared dependency for every payment route, even when the acquirers behind it are diverse. If the orchestration service, its database or its network path fails, traffic to all processors can stop at once, so the provider count looks higher than the real point of failure. Concentration can also arise from one cloud region, one Kubernetes cluster, one identity provider or one key management service underneath the layer. Map each of these as a dependency, not only the processors. Ask your team which component, if it failed, would stop payments for every merchant and market at the same time.
How does self-hosting change the third-party provider picture?
Self-hosting moves the orchestration software from a vendor-run service into your own infrastructure, so the open-source project becomes a software component you operate rather than a contracted service. You still depend on the infrastructure provider, the database and cache technology, the container platform and any external vault or processor. In practice, the register of information lists each cloud, data center, managed service and processor used in the route, with its role and substitutability. For Hyperswitch, the open-source core is Apache-2.0 licensed, but the Control Center also depends on OpenID Connect identity providers and your chosen vault model, so each of these needs its own entry and exit assessment.
Can multi-processor failover reduce dependence on one acquirer?
Multi-processor routing can reduce dependence on a single acquirer or processor, but it reduces only that layer of risk. Failover works when each route is connected, tested and holds the tokens and merchant credentials needed to transact, and when routing rules move volume without manual steps. Confirm the following in your design:
- Each acquirer or processor is onboarded and tested in the markets you serve.
- Stored tokens can be used through the alternate route, or the vault dependency is also covered.
- Failover decisions and their triggers are documented and rehearsed.
- Reconciliation works across all routes so that settlement is traced to the processor that actually settled it.
Failover does not remove dependence on the orchestrator itself, so it should be tested together with the orchestration layer's own resilience plan.
What should go into the register of information and exit plan?
The register of information should record each ICT third-party arrangement that supports payments, including the provider, the service, the function it supports, the location of data processing, the sub-providers involved and whether the function is critical or important. For a self-hosted orchestration layer, include the open-source project and version line, the infrastructure and managed services, each processor and vault provider, and the identity provider. The exit plan should describe how each dependency could be replaced, how tokens and transaction data would be exported in a usable form, and the order of steps for moving traffic. Confirm the required fields and format with your regulator, since supervisory expectations for the register are set nationally and in the regulatory technical standards.
Who is responsible for DORA scope and the register of information?
The regulated entity remains responsible for its DORA obligations, its scope decision and the accuracy of its register, whether or not an implementation partner is involved. A partner such as DeployOpen can help prepare the system inventory, dependency maps, configuration evidence and exit documentation, and can run security testing of the orchestration layer. A partner does not decide your classification, issue assessments or act as your regulator-facing owner. Ask any partner to document which artifacts they produce, who signs off on them, and how changes after go-live are reflected in the register. Confirm your own obligations with counsel or your supervisor before engaging on scope.
How should a team test concentration risk before go-live?
Test concentration risk by simulating the failure of each shared dependency and observing whether payments continue through another route. Useful exercises include taking one acquirer offline in a test environment, degrading the database replica, failing one Kubernetes zone and revoking access to the identity provider for operators. Record how long each failure takes to detect and what manual steps are needed, then compare the results with the impact tolerances your entity has set. Include the outcomes in your ICT risk documentation. Confirm the testing expectations for your entity with your regulator, since the testing requirements in DORA depend on your classification.
How an EU sovereign orchestration rollout runs in phases
The sequence moves from mapping where payer data goes to a handover package that lets your team run the orchestration layer, with each phase closing on a written output that the next phase depends on.
Map data location and transfers
Your privacy, legal and payments leads, with DeployOpen, list every place card data, tokens, transaction records, logs and support access would sit, including any third-country remote access for support or administration. The output is a data flow inventory marking each element as EU-only, EU-hosted with a documented transfer basis, or out of scope. Remote access from outside the EEA is treated as a transfer under EDPB Guidelines 05/2021, so support paths are mapped with the same care as storage. The step closes when the privacy lead signs off the inventory.
Decide the vault model
Choose between the self-hosted in-house vault, a self-hosted orchestrator with an external PCI vault provider, or a self-hosted orchestrator with a SaaS vault. Each model shifts PCI DSS responsibility differently, and Hyperswitch documentation states that under the in-house model the merchant is fully responsible for PCI DSS certification and data handling. Confirm with your QSA and your vault provider where the vault data physically sits and who holds the keys. The output is a signed decision record that names the vault location and the responsible party for each control.
Design the EU cluster and network
DeployOpen's platform engineers deploy the Hyperswitch components in EU regions or data centers you control, using the Helm-based self-hosting approach on Kubernetes, with the Router, Scheduler, PostgreSQL and Redis components placed in segregated network zones. Egress rules are set so only approved processor and sub-processor endpoints are reachable from the payment path. Backups and logs are kept in the same jurisdiction. The output is an architecture diagram and firewall rule set that the security team reviews before any build starts.
Review processors and sub-processors
Your procurement, legal and third-party risk teams review each acquirer and processor in the route for EU hosting, the law they are subject to, and their sub-processor chain. Standard contractual clauses under Commission Implementing Decision (EU) 2021/914 are checked where a transfer remains, and any processor subject to third-country law with extraterritorial reach is assessed against possible government access requests. Contract clauses covering DORA register information, audit rights and exit assistance are confirmed with each provider. The output is a processor register with a transfer basis and a contract clause check for each entry.
Configure connectors and admin access
DeployOpen configures the approved processor connectors and routing rules in the Hyperswitch Control Center, then sets up administrator access. Control Center single sign-on works through OpenID Connect only, with no SAML, no JIT or SCIM provisioning, and roles managed inside Hyperswitch rather than mapped from your identity provider. Users are invited first, so your team confirms the access list and role assignments against your access review process. The output is a connector inventory, a role matrix and a signed-off list of named administrators with multi-factor authentication enabled at the identity provider.
Test failover and routing
Test transactions run against sandbox processor accounts and the approved failover targets, covering authorization, decline handling, retries, refunds and the fallback order if a primary processor is unavailable. Vault tokenization is tested end to end so that no clear card data appears in logs or in the reporting store. The output is a test report that records each routing scenario, the expected and actual result, and the owner who accepted it. Changes to routing rules are gated on this report.
Cut over traffic in stages
Live traffic moves to the EU cluster in controlled stages, starting with a limited share of transactions and a rollback path to the previous setup. Reconciliation runs against each processor's settlement files from the first live day, and the operations team watches authorization rates, latency and error codes. Cutover proceeds only when the reconciliation difference is explained and the rollback has been rehearsed. The output is a cutover log with the go and no-go decisions recorded by named owners.
Hand over with runbooks
DeployOpen delivers runbooks for deployment, upgrades, key rotation, backup and restore, incident handling, processor onboarding and access reviews, and trains your operations staff to run them. Records of the data location inventory, vault decision, processor register and test reports are assembled as compliance evidence. Ongoing support or upgrade retainers are agreed separately in writing. The step closes when your team runs a documented drill of a routine change and the handover pack is accepted in writing.
Evidence a regulator or auditor will ask for
This table maps each piece of evidence a supervisor or auditor is likely to request to the component that produces it and the obligation it supports. Read it as a checklist to set up before go-live, not after. DeployOpen prepares this evidence, but auditors, supervisory authorities and regulators assess it and decide whether it is sufficient.
| Evidence item | Which component produces it | Obligation it supports |
|---|---|---|
| Data-flow and location register | Architecture documentation, Hyperswitch Router and connector configuration, and the cloud region inventory | GDPR Article 44 (transfers to third countries, including onward transfers) |
| Transfer impact assessments for any non-EEA access or processor | Your legal and privacy team, informed by processor access statements and the destination's public authority powers | GDPR Chapter V and EDPB Recommendations 01/2020 on supplementary measures |
| Standard contractual clauses (Decision 2021/914) with copies on file | Contract management records for each processor and sub-processor in the route | GDPR Chapter V transfer tools for any non-EEA recipient |
| Processor and sub-processor list with hosting locations | Vendor register, mapped against each connector and vault provider in the payment route | GDPR Article 28 processor oversight and Article 44 onward transfer controls |
| Encryption service key management and access logs | Encryption service and key management records, plus the card vault audit trail | PCI DSS key management expectations and GDPR Article 32 security of processing |
| Control Center access and role change logs | Hyperswitch Control Center user activity, with SSO events recorded in your identity provider | Access accountability under GDPR Article 32 and PCI DSS access control requirements |
| Change records for routing rules and connector settings | Version control and approval tickets for routing configuration, plus Hyperswitch release notes | Change management under 16 CFR 314.4 where the FTC Safeguards Rule applies, and DORA ICT change control |
| DORA register of information entries for ICT third-party providers | Your third-party register, populated with each orchestration, vault, cloud and processor dependency | DORA Regulation (EU) 2022/2554 register of information and concentration risk review |
Questions to ask an implementation partner about EU data location
Start with the boundary. Ask the partner to list every component of the Hyperswitch deployment (the Rust core app server, the Router and Scheduler services, PostgreSQL with its master and replica, Redis, the card vault, the encryption service for key management, and the Control Center) and to state the region and provider for each one. Then ask how the EU boundary is enforced in practice: which cloud accounts, network policies, and egress controls prevent a replica, backup, log sink, monitoring agent or Redis cache from landing outside the EEA. Ask for the infrastructure-as-code that pins regions, and for the evidence that a deployment cannot silently drift outside them. Ask who holds the Kubernetes cluster administrator role and from which countries those administrators sign in, because remote access from a third country is a transfer under the EDPB's guidance even when the operator only views a screen.
Ask how support works before an incident happens. Who can open a shell into a payment namespace, who can read logs that contain payer identifiers, and through which bastion or privileged access tool? Ask for the written list of support locations and whether any follow-the-sun model routes tickets to staff outside the EEA. Then ask how the card vault and its keys are isolated: whether the vault runs in a separate network segment and cluster, where the key hierarchy lives, whether an HSM or cloud key service in the EU holds the master keys, and who can approve a key rotation. Ask the partner to name the vault model they recommend among the three Hyperswitch documents describe (in-house PCI vault, external PCI vault provider such as VGS or Tokenex, or the SaaS Hyperswitch Vault), and to explain in writing who holds PCI DSS responsibility under that model. Under the in-house model, the Hyperswitch docs make the merchant fully responsible for PCI DSS certification and data handling, so confirm that your own team or a qualified assessor owns that scope.
Finally, ask for the documentation trail. Request a list of every processor, acquirer and sub-processor on each route, with its processing location, its contract basis for transfers, and whether it is subject to third-country law with extraterritorial reach, such as the US CLOUD Act (18 U.S.C. 2713). Ask how that exposure is assessed before a processor is engaged, and how the controller records the assessment. Ask how routing changes are tested before they reach production, including whether a failed processor triggers failover into a non-EU route, and how that is checked against the data location rules. Finally, ask how upgrades avoid payment downtime: staged rollouts, a tested rollback path, database migration order between the primary and replica, and the process for returning a deployment to a prior release. Ask for these answers in a written statement of work, not only in a call.
What buyers ask before hiring help for EU payment data sovereignty
What drives the cost of self-hosted payment orchestration for EU data sovereignty?
The cost depends on the written scope, not on a standard package. The main drivers are the number of processors and acquirers to connect, the number of payment methods and markets, whether the card vault stays in-house or uses an external PCI vault provider, how many environments and Kubernetes clusters must sit in EU regions, and how much legal and data-mapping work the client needs alongside the technical build. Recurring costs include cloud infrastructure, database and backup operations, upgrades, and processor and vault fees charged by third parties. DeployOpen does not publish a price list. Ask for a fixed-scope quote that lists each deliverable, the assumptions behind it, which costs are one-time and which recur, and which items sit with your legal, compliance or processor-management teams.
How long does an EU payment data sovereignty project take?
Duration depends on scope, the number of processors in the route, the vault model chosen, and how quickly the client can supply contracts, data maps and approvals. DeployOpen does not give a generic timeline. Engagements are fixed-scope, so the timeline is agreed in writing before work starts and should show phases for architecture decisions, environment build, connector setup, routing tests, reconciliation checks and cutover. Ask the partner to tie each phase to a client input and to name the dependencies that could move the schedule, such as processor onboarding lead times or legal review of transfer assessments.
What does the client need to provide before implementation starts?
The client needs to provide inputs that define where data may go and who is responsible for it. Typical inputs include:
- Processor and acquirer contracts, including data processing terms, sub-processor lists and the locations where each provider stores or accesses data.
- Entity structure and the controller and processor roles for each entity and market.
- A data map covering payer data, card data, transaction records, logs and support access, with the systems that hold each one.
- Named owners for processor contracts, DORA third-party risk records and PCI DSS scope decisions.
Missing inputs are the most common reason fixed-scope work slips, so confirm these items in the proposal stage.
Can an internal team run EU payment orchestration without outside help?
An internal team with Kubernetes, PostgreSQL, Redis and secure key management skills can deploy Hyperswitch using its public documentation, which covers self-hosting with Helm charts and configuration of the card vault models. The harder work sits outside the code. GDPR transfer assessments, the choice of EU processors, DORA third-party risk arrangements and contract terms need qualified legal and compliance input, and DeployOpen does not provide legal advice. Many teams split the work: internal staff own operations and the processor relationships, while an implementation partner handles hardening, routing tests and documentation. Confirm the legal review path with your counsel before committing to an architecture.
Is a SaaS payment vault cheaper to run than a self-hosted one?
It depends on what you are trying to keep in the EU and who carries the PCI DSS burden. A SaaS vault removes infrastructure and key management work from your team, but it adds platform fees and places card data with a third party, so you must confirm where that provider stores and accesses data, including remote access from outside the EEA. A self-hosted in-house vault gives you control over location but makes you fully responsible for PCI DSS certification and data handling, as the Hyperswitch docs state for that model. Compare total cost over the contract term using the same data location requirements, and ask each option for its written data flow diagram.
Does DeployOpen issue GDPR, DORA or PCI DSS certifications?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. For PCI DSS, a qualified assessor confirms scope and compliance, and for GDPR, supervisory authorities and courts interpret the rules. DeployOpen can help you document data flows, configuration, access controls and logging so that your assessor or legal team has the evidence they need. Ask any partner to state clearly which parts of the work it performs and which parts remain with your assessor and counsel.
Which Hyperswitch limits should buyers check before committing to self-hosted SSO?
Confirm identity requirements early, because the Hyperswitch Control Center supports single sign-on through OpenID Connect only. SAML is not supported, there is no just-in-time or SCIM provisioning, users must be invited first, and roles are managed in Hyperswitch rather than mapped from your identity provider. If your identity standard is SAML or you need automated provisioning, plan for an access process or an additional layer and confirm the approach in writing. Check the current configuration guide in the Hyperswitch docs before you design access controls for the dashboard.
How DeployOpen scopes and supports EU-hosted orchestration
DeployOpen is a Chainscore Labs company that plans, implements, hardens and supports self-hosted open-source platforms inside the client's own infrastructure, which for this topic means your EU cloud accounts, data centers or private networks. For a Hyperswitch deployment, that work covers the Kubernetes footprint, the Router and Scheduler services, PostgreSQL and Redis, the card vault, the encryption service for key management, the Control Center and the connector configuration for each processor in the route. Engagements are fixed-scope, and the scope, deliverables, data locations, named processors and acceptance criteria are agreed in writing before work starts. Ask for that document to state explicitly which regions hold the vault, the transaction store and the logs, because those statements are what your data protection and DORA files will rely on.
Security testing is a separate, scoped activity. DeployOpen runs application and API security testing, so the payment APIs, the Control Center login flow and the connector callbacks can be tested against the configuration you intend to run in production. Before a deployment is accepted, confirm with the partner which findings are fixed, which are accepted with a documented owner, and whether the test covers the tenant isolation and key handling that the EU data location claim depends on. Retainers cover upgrades, patching, monitoring response and recurring testing after go-live, which matters because orchestration routing and connector versions change often.
DeployOpen prepares systems, controls and evidence for compliance assessments, including configuration baselines, data flow diagrams, access records and the records your assessor will request. It does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies that you select. Before signing, confirm with the partner who holds which responsibilities under your own processor and third-party risk program, and ask for the written list of evidence artifacts that will be delivered at handover and during each retainer period.
