Why adding a second processor with self-hosted orchestration is a PCI and data decision first
Adding a second processor is mostly a decision about where card data sits, how tokens move, and which system owns payment state. A merchant whose checkout, stored cards and reconciliation all run through one gateway usually wants a second processor for resilience, for authorization rates, or both. The routing rules are the visible part of the work, but they are the easy part. Before any traffic moves, the team has to decide which system holds primary account numbers, whether stored cards can be exported from the current gateway's vault, and which ledger is treated as the record when the two processors disagree.
Hyperswitch, an Apache 2.0 licensed orchestration layer maintained by Juspay, sits between checkout and the processors. The Rust core handles routing, retries and vaulting, and a deployment on Kubernetes with Helm charts keeps it inside your own infrastructure. Card data is held in a separate card vault service, so the vault model you choose drives PCI DSS scope more than the routing logic does. Hyperswitch documents three models: a self-hosted native vault that the merchant runs in-house, self-hosted orchestration with an external PCI vault provider, and self-hosted orchestration with the SaaS Hyperswitch Vault. In the in-house model, the Hyperswitch documentation states that the merchant is fully responsible for PCI DSS certification and data handling.
Confirm the vault model before you confirm the processor contract. Ask your assessor which PCI DSS v4.0.1 requirements apply to each model, and ask your processors whether they will accept tokens generated by a different vault. Also confirm with the vendor which Hyperswitch version and connectors you will run, since the platform's releases change often. A clear answer on these three points sets the scope for everything that follows.
Requirements a second processor adds and what each means for the build
This table maps each obligation that appears when a merchant adds a second processor behind Hyperswitch to what it means for the build and the evidence an assessor will ask for. Read it as a checklist for scoping the work, and confirm each applicability question with your acquirer, your payment brands and your regulator before fixing the design.
| Requirement | What it means for the build | Confirm before scoping |
|---|---|---|
| PCI DSS applicability to the cardholder data environment | The orchestration layer, the card vault, and any system that transmits card data become part of the cardholder data environment. The new processor is a third-party service provider whose responsibilities must be documented. | Which systems and connectors are in scope, and which SAQ or ROC type applies to your merchant level and channel |
| PCI DSS v4.0.1 as the only active version | Design and assessment should target v4.0.1, since v4.0 was retired on 31 December 2024 and v3.2.1 on 31 March 2024. The standard is organized into 12 principal requirements under six goals. | Whether the PCI SSC has announced a successor version, since no release date had been set as of October 2026 |
| Stored card migration between vaults | Moving saved cards to a new processor or vault requires a token migration plan, a key and data handling procedure, and reconciliation of migrated tokens against source records. Card data should be moved only through controlled, encrypted channels. | Whether the existing processor permits card data export, and whether the receiving vault has agreed to accept it |
| Encryption in transit and at rest (Requirement 3 and 4 themes) | Stored account data must be minimized and rendered unreadable, and cardholder data crossing open networks must be encrypted. Key management for the vault and encryption service must be separated from application administrators. | Where keys are generated and held, and who can access them, including any HSM used |
| FTC Safeguards Rule controls (16 CFR 314.4) | For covered financial institutions, customer information must be encrypted in transit and at rest, multi-factor authentication applies to anyone accessing information systems, change management procedures apply, and user activity must be logged. | Whether your business is a covered financial institution under the rule and how the orchestration admin console authenticates users |
| Annual testing under 16 CFR 314.4(d)(2) | Absent effective continuous monitoring, penetration testing and vulnerability assessments are required at least every six months. The new routing path and connectors should be included in the test scope. | Whether your monitoring qualifies as continuous, and which environments the testers will cover |
| SEC Rule 17a-4(b) retention for broker-dealer records | Where applicable, records such as bills receivable or payable and bank statements must be preserved for at least three years, the first two in an easily accessible place. Transaction logs and reconciliation files from both processors need to fit that retention plan. | Whether the merchant or a related entity is a broker-dealer, and how long processor logs and webhook data are kept |
| Change management for routing rule updates | Each change to routing, retry or fallback rules should be requested, tested in a non-production environment, approved, logged and reversible. This also supports the FTC change management expectation. | Who approves routing changes, and how a rule change is rolled back during an authorization drop |
| PCI SSC enforcement and payment brand roles | The PCI SSC sets the standard but does not enforce compliance or impose penalties. The payment brands and acquirer decide which entities must validate and run enforcement programs. | Which payment brands and acquirer obligations apply to your volume and card types, in writing |
Which vault model fits a merchant moving stored cards between processors
In the self-hosted model with the native Hyperswitch Vault, the card vault runs as a separate service inside your own infrastructure. Primary account numbers are received, encrypted and stored there, so the vault, its database, the encryption service for key management and every system that touches them are inside your cardholder data environment. The Hyperswitch documentation states that the merchant is fully responsible for PCI DSS certification and data handling in this model.
- Scope: The vault, key management, hosting platform, logging and administrator access all enter your CDE and your assessment.
- Obligation: You hold the PCI DSS obligation end to end, including the assessment and the evidence behind it.
- Existing tokens: Tokens from your current gateway cannot be used here unless the gateway exports the underlying card data under a documented, secure process, so confirm that route and its PCI status before you plan the migration.
- Exit and location: You control where data is stored and can leave the platform with your own data, but you carry the work of key rotation and vault migration yourself.
Ask the implementation partner to map every system that stores, processes or could affect card data before you commit to this model.
In self-hosted orchestration with an external PCI vault provider, such as VGS or Tokenex, Hyperswitch runs your routing and payment logic while card numbers are held by the provider's vault. Your systems receive tokens and never need to see the full primary account number. This narrows your CDE, but the provider's own PCI DSS status and its integration points become part of your third-party risk review.
- Scope: Your application, Hyperswitch core and any system that handles raw card data at the point of capture may still need review, so confirm exactly where card entry happens.
- Obligation: Your obligations shrink but do not disappear. Request the provider's current PCI DSS attestation of compliance and the scope of services it covers.
- Existing tokens: Moving tokens from your gateway into the provider's vault is a token migration that depends on both parties' formats and cooperation, so ask for a written migration path and a test with sample records.
- Exit and location: Your ability to leave depends on whether the provider exports tokens or the underlying card data, and in what format. Check data residency, retention and deletion terms in the contract.
Confirm the provider's attestation and token portability in writing before any migration starts.
In self-hosted orchestration with the SaaS Hyperswitch Vault, your routing, reconciliation and checkout logic remain on infrastructure you run, while card storage happens in a vault operated as a hosted service. This keeps your Hyperswitch deployment in your control but moves the storage of primary account numbers outside your environment. Where the vault sits and who operates it is the central question for this model.
- Scope: Card data stays out of your own systems, but the connection between your checkout and the hosted vault remains in scope, so confirm how tokens and card entry are protected in transit.
- Obligation: The vault operator holds the PCI DSS obligation for the vault service. Ask for its current attestation, the responsibility matrix and the services it covers.
- Existing tokens: Importing tokens from your current gateway depends on the export options available from that gateway and on whether the hosted vault accepts them, so verify both before planning cutover.
- Exit and location: Confirm the hosting region, the export format for stored cards and any fees or notice periods that apply on exit.
Get the vault operator's PCI attestation, token export terms and data location in writing before you sign.
Which platforms fit a second-processor build and why
The orchestration layer is the decision that matters for a second processor, because it sits in the checkout path and decides which processor receives each payment. ERP, ledger and billing choices follow from systems you already run, so treat them as context and integration points rather than the starting point.
Hyperswitch as the orchestration layer
Hyperswitch sits between your checkout and your processors, so it is the component that changes most in a second-processor build. Its documentation describes connectors to more than 100 processors and wallets, plus modules for routing, retries, vault tokenization and reconciliation. Check which connectors you need in each market, whether your existing gateway has a supported connector, and who owns the connector credentials. Confirm connector coverage before you commit to a design.
Card vault and key management
The vault decides where stored card data lives and how it moves when you add a processor. Hyperswitch documents three self-hosted vault models: its native vault, an external PCI vault provider, and the SaaS vault. Each one changes your PCI DSS scope and the migration work for stored cards. Ask whether the vault can export or re-tokenize cards for a new processor and who holds the encryption keys.
Kill Bill for recurring billing
Kill Bill is relevant only when subscriptions or recurring charges run beside one-off payments. Recurring billing creates retry schedules, dunning and invoice-level reconciliation that a payment orchestrator does not model on its own. If you have no recurring billing, leave it out of this build. For the design choices, see the open source subscription billing content group.
Apache Fineract as ledger context
Apache Fineract is a core banking platform, so it fits only if you already run or plan to run a ledger for lending, deposits or merchant accounts. For a second processor, the question is how settlement amounts post to the ledger. The reconciliation feed from the orchestrator and the processor settlement files is the integration point. Confirm whether your ledger needs per-processor settlement accounts before you map the feed.
Odoo Enterprise as ERP context
Odoo Enterprise fits when your finance team already runs Odoo for invoicing, accounts receivable or general ledger. Settlement and fee entries from each processor then need an account mapping and a clear owner for month-end. The open source core is licensed under LGPL-3.0, while Enterprise adds features such as hosting and upgrades, so confirm which edition your finance workflow depends on. If your ERP is ERPNext or another system, the same reconciliation feed applies.
How stored cards move from the existing gateway to the new vault
This sequence moves stored cards or tokens from the current gateway into a vault that Hyperswitch can call, without losing payment methods or breaking recurring charges. Each step ends with an output that the processor contracts, the PCI assessor and the finance team can check.
Inventory stored credentials and token formats
Your payments team, with the current gateway's support contact, lists every stored payment method: card-on-file tokens, subscription tokens, network tokens if any, and any card data held outside the gateway. For each type, record the format, the owning entity, the merchant account it belongs to and which flows depend on it, such as recurring billing or saved cards at checkout. The output is a token inventory with counts per type and per flow, plus a list of anything that cannot be moved and will need customers to re-enter details. The inventory is done when the gateway confirms it matches the counts in its own reporting.
Confirm raw PAN export conditions with the gateway
Before any export is planned, your team asks the current gateway in writing whether it permits export of raw card numbers, in what file formats and to which receiving parties, and what it requires from the receiving environment. Your QSA or internal PCI lead confirms what that receiving environment must meet and how the transfer will be scoped within the cardholder data environment. The output is a written decision: export of raw account data permitted under stated conditions, or not permitted, in which case the migration uses network token enrollment or customer re-entry. Do not start a transfer until both the gateway and the assessor have accepted the conditions in writing.
Choose the vault model
Your architecture and security leads select one of the three vault models Hyperswitch documents: the native Hyperswitch Vault run in-house, a self-hosted orchestration layer with an external PCI vault provider, or the SaaS Hyperswitch Vault used alongside self-hosted orchestration. The choice follows from the export decision in the previous step, your appetite for owning PCI DSS obligations for stored data, and where the data may reside. Under the in-house model, the merchant takes full responsibility for PCI DSS certification and data handling, so the assessor should review this choice before it is made. The output is a signed architecture decision record that names the vault model, the key custodian and the cardholder data environment boundary.
Run token migration in a non-production environment
Your platform engineers and the vault provider run the migration in a staging environment that mirrors the production Hyperswitch deployment, using a sample of tokens from each inventory category. For each category, they either import the data through the approved vault path or enroll cards for network tokens with the card brands' token service, depending on what the gateway permits. Connector credentials for the new processor are loaded and tested with sandbox transactions. The output is a migration log per category showing success, failure and reason codes, and a test run that charges and refunds through the new route. Failures are fixed and the sample is re-run until every category passes.
Reconcile counts and sample transactions
Your finance and payments operations teams compare the number of stored methods in the source gateway with the number in the target vault, category by category, and resolve every difference. They then pick a sample of stored methods and run test authorizations against each one through the new route, comparing the outcome, the network response and the tokens returned with what the source gateway shows. Recurring schedules are checked against the next expected charge dates. The output is a signed reconciliation report with zero unexplained differences, a list of accepted exclusions with owners, and sample results that the payments lead approves before any customer traffic moves.
Cut over by cohort
Your payments team moves stored methods and checkout traffic in defined cohorts, such as one merchant account, one customer segment or one card type, instead of all at once. For each cohort, the team confirms routing rules, fallback targets and the source gateway's continued availability for refunds and disputes on older transactions. Monitoring tracks authorization rates, decline codes and error rates per cohort against the baseline from the source gateway. The output is a cohort log with start and end points, a go or hold decision for each cohort, and a rollback path that is tested before the next cohort begins. The source gateway stays available until the reconciliation of open items is complete.
Routing and fallback rules that protect authorization rates
Routing rules decide which processor sees each payment, so they are the first place a second processor can either raise authorization rates or quietly lose sales. Before enabling fallback, write down the rule set in plain terms: which card brands, markets, amount bands and, where the processor exposes it, issuer or BIN ranges go to the existing gateway and which go to the new connector. Segment conservatively at first, for example by one market and one card brand, so that each rule can be measured on its own. Hyperswitch's intelligent routing documentation describes the routing and retry capabilities, but confirm each feature (rule types, fallback triggers, retry limits and rule versioning) against the Hyperswitch release you deploy, because capabilities change between versions.
Authorization rates must be measured per processor and per rule, not only as one blended number. Tag every attempt with the connector, the rule that selected it and whether it was a first attempt or a fallback, then compare approval rates by segment over a fixed window. Two risks need explicit checks. The first is decline-code mismatch: processors map issuer responses to different codes, so a retry that is safe on one connector may be a hard decline on another, and fallback logic should retry only on codes your team has classified as soft. The second is duplicate capture on fallback: if the first processor authorized the payment but the response was lost or timed out, a retry on the second processor can create a second authorization. Confirm how the platform marks an attempt as uncertain, and reconcile by payment ID before any capture is released.
Treat routing and retry rules as controlled changes. Under the FTC Safeguards Rule at 16 CFR 314.4, covered financial institutions must adopt change management procedures and log the activity of authorized users, so a rule edit in the Control Center should have a named approver, a test record and an audit trail. Limit who can edit rules through the platform's role model, and remember that the Control Center supports single sign-on through OpenID Connect only, with roles managed in Hyperswitch rather than mapped from the identity provider, so access reviews must be run inside Hyperswitch. Ask your implementation partner to show how rules are tested in a sandbox and rolled back, and confirm which of these steps your organization must evidence to its own assessors.
Integration points that change in checkout, reconciliation and PCI scope
Putting Hyperswitch in front of an existing gateway touches six places: the checkout client, the orchestration services, the card vault, the data stores, the admin console and the books. Each one changes a different part of checkout, reconciliation or PCI DSS scope, so review them together before routing traffic to a second processor.
Checkout SDK and client-side tokenization
The storefront moves from calling one gateway's script to calling the Hyperswitch client SDK, which collects card details and tokenizes them before they reach your servers. Confirm that card fields are rendered inside the SDK or a hosted iframe, so raw PAN never touches your application code. Check which wallets and 3DS flows each connector supports, because the same button may behave differently per route.
Hyperswitch Router and Scheduler
The Router handles payment requests, routing decisions, retries and connector calls, while the Scheduler runs asynchronous work such as retries and follow-up jobs. Your routing rules, fallback order and timeout settings live here, so a change in one rule can shift volume between processors without any checkout code change. Ask who approves routing changes and how each change is tested before it reaches production traffic.
Card vault and encryption service
Stored card data sits in a separate card vault service, and an encryption service manages the keys that protect it. This is where PCI DSS scope is decided: if the vault is self-hosted in-house, your organization carries the full PCI DSS responsibility for storage and key handling. Decide early whether to run the vault in-house or pair orchestration with an external PCI vault provider, because the choice changes your assessment more than any other design decision.
PostgreSQL master and replica with Redis
Payment state, merchant configuration and transaction records are stored in PostgreSQL with a master and replica, while Redis handles caching and the scheduler queue. Reconciliation reports and dashboards usually read from replicas, so replication lag can make a transaction look missing for a short period. Confirm backup, restore and point-in-time recovery targets with your partner, and check that Redis data loss cannot strand queued retries or refunds.
Control Center access and SSO limits
The Control Center is where operations staff configure connectors and routing. Its single sign-on supports OpenID Connect only, with no SAML, no SCIM and no just-in-time provisioning, and roles are managed inside Hyperswitch rather than mapped from your identity provider. Your access reviews must cover Hyperswitch user lists and role assignments directly, since removing someone from the identity provider will not remove their console access.
Reconciliation export to ERP or ledger
Each processor reports settlements, fees and disputes in its own format and timing, so the books now receive transactions from two sources. Map Hyperswitch payment identifiers to processor references, settlement batches and ERP journal entries before go-live. Ask how fees, partial captures, refunds and chargebacks are exported, and who signs off on the matched totals each close.
Evidence auditors and assessors ask for, and which component produces it
This table maps each piece of evidence a PCI DSS assessor, QSA or financial regulator is likely to request after adding a second processor to a self-hosted Hyperswitch stack to the party that produces it. Hyperswitch components can generate operational records such as routing configuration history, transaction logs and vault access records, but the scope statement, the assessment report and the attestation come from the merchant and its assessor. Read the Hyperswitch column as a source of raw records to confirm in your own deployment, not as a finished audit artifact.
| Evidence item | Hyperswitch components can generate | Merchant and assessor must produce |
|---|---|---|
| PCI DSS scope statement and data flow diagram | Connector and routing topology exported from configuration, which helps document the route | Scope statement, data flow diagram, segmentation evidence and annual scope confirmation, owned by the merchant and reviewed by the assessor |
| Attestation of Compliance or Report on Compliance | Nothing; the platform does not validate the merchant | ROC from a Qualified Security Assessor or SAQ with AOC, the only accepted validation; a certificate is not validation |
| Routing change logs and approvals | Configuration change history and routing rule versions, to be confirmed in your build | Change approval records, test results and sign-off from the processor contract owner and security reviewer |
| Access logs for authorized users | Admin and API access logs from the Control Center and Router, to be confirmed for retention and fields | Access review records, the user roster and evidence that SSO and MFA cover each administrator |
| Vault key management records | Vault and encryption service operation logs, if enabled; key rotation events to be confirmed | Key custodian procedures, key ceremony records, HSM or KMS configuration and rotation evidence |
| Authorization rate comparison reports per processor | Per-connector authorization outcomes and routing decision data from the orchestration layer | Analyst-reviewed comparison, the chosen definitions for approval rate and the business decisions taken from it |
| Reconciliation reports matching processor settlement to ledger | Transaction and payout records with processor references, to be confirmed for export format | Settlement file intake, matching rules, exception queue and ledger sign-off by finance |
| Penetration test and vulnerability scan records | Nothing; scan output comes from the merchant's testing program | Annual penetration tests and vulnerability assessments; 16 CFR 314.4(d)(2) requires them at least every six months for covered institutions without continuous monitoring |
What buyers ask before adding a second processor
What drives the cost of adding a second processor with self-hosted orchestration?
Cost depends on the work and the infrastructure, not on a fixed package. Cost components include the Kubernetes environment that runs the Hyperswitch Router, Scheduler, PostgreSQL and Redis; the connector setup for each processor; the card vault decision; and the PCI DSS assessment of your own environment, which you pay a Qualified Security Assessor or internal team to perform. Recurring costs include hosting, operations, processor fees and upgrades. Ask any quote to list one-time and recurring items separately, the number of connectors in scope, the vault model, and which environments are covered. DeployOpen does not publish a price list; a quote follows from written scope.
Can our in-house team add a second processor without an implementation partner?
Often yes, if the team already runs Kubernetes, PostgreSQL and Redis in production and has engineers who know payment flows. Hyperswitch is open source under Apache 2.0 and documents self-hosting with Helm charts, so the software itself is accessible. The harder parts are the processor certification work, routing and fallback design, reconciliation, and PCI DSS scope decisions. Check whether your team has done these before, who signs off on the scope, and whether you have capacity to run the system after go-live. A partner can cover some or all of these, and the split should be written down.
How long does adding a second payment processor take?
Duration depends on the number of processors, the payment methods and markets involved, whether stored cards must move, and how much testing your processors and acquirers require. Your processor's certification timelines and your change management process often set the critical path more than the software does. Ask for a plan with milestones for environment build, connector testing in a sandbox, shadow routing, staged traffic and rollback criteria. No duration can be stated responsibly without the written scope, so request a timeline that ties each phase to a deliverable.
What does the work need from our payments, security and finance teams?
Payments teams own processor contracts, connector credentials, routing rules, retry logic and checkout changes. Security teams approve the network design, key management, access controls, logging and the PCI DSS scope boundary. Finance teams need to agree on how settlement files, fees and refunds from each processor are matched in reconciliation. Each group should name a decision owner before work starts. Missing ownership is a common reason second-processor projects stall, so confirm these owners in the statement of work.
Does an external vault reduce PCI DSS scope for our merchant environment?
It can, but the reduction depends on the vault model and on how your systems handle card data. Hyperswitch documents three vault models: the native in-house PCI vault, self-hosted orchestration with an external PCI vault provider such as VGS or Tokenex, and self-hosted orchestration with the SaaS Hyperswitch Vault. With the in-house model, the Hyperswitch documentation states that the merchant is fully responsible for PCI DSS certification and data handling. With an external vault, the vault provider's own PCI DSS status is a separate question you must verify. Scope is decided by your assessor against PCI DSS v4.0.1, the only active version, and certificates are not accepted as validation. Ask your QSA to confirm the boundary in writing.
How do we compare authorization rates between processors fairly?
Fair comparison requires the same traffic mix, the same card types and regions, and the same time windows across processors. Compare approval rates by BIN range, card brand, geography, and transaction type, not one blended number. Track decline codes separately, because soft declines and retries can distort results. Use the routing configuration and any intelligent routing rules to split traffic deliberately, and record which rule sent each transaction. Hyperswitch documents intelligent routing, which you should test in a controlled split before relying on it. Agree on the metric definition before the test starts, and keep the test long enough to cover normal weekly cycles.
What changes for stored cards if the first processor is later removed?
Stored cards are tied to the vault that holds them, not directly to the processor, so the vault model determines the migration path. With the Hyperswitch card vault, tokens and encrypted card data stay in your environment, and routing can point to a different processor without re-collecting card numbers. With an external or SaaS vault, moving tokens depends on whether the vault provider supports export and whether the new processor accepts those tokens. Network tokens may be easier to keep working across processors, but this depends on your acquirers and agreements. Confirm token portability, the export format, the key handling and the testing plan before the first processor is switched off.
Which parts of this work need written scope before we ask for a quote?
Before requesting a quote, write down the processors and payment methods to be connected, the markets and currencies, the vault model, the stored card volume and whether tokens must move, the routing and fallback rules, the reconciliation reports, the environments to be built, and the PCI DSS responsibilities for each party. Also list whether your QSA is already engaged and which change windows apply. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts. A written scope gives every vendor the same basis for comparison.
Questions to put to an implementation partner before signing
Before signing, ask the partner to show how Hyperswitch connectors and routing rules are configured, stored and versioned. Ask whether connector credentials are held in the encryption service for key management or in plain configuration, who can change a routing rule in the Control Center, and whether every change is recorded in Git and reviewed before it reaches production. Ask how the Router and Scheduler services, backed by PostgreSQL and Redis, are deployed and whether the partner's Helm chart values are kept in your repository. Confirm that the written scope names each connector and routing rule that will be delivered. Ask how the card vault and encryption keys are isolated from application services. For the vault model you choose, ask the partner to state in writing who operates the card vault service, where its keys sit, who holds key custody, and which network paths and service accounts can reach it. Ask for the PCI DSS responsibility matrix for that model. For the in-house model, the Hyperswitch docs place full PCI DSS responsibility on the merchant, so the matrix should list the assessment, segmentation and key ceremonies as your duties. For an external vault such as VGS or Tokenex, it should list the provider's attestation and your integration duties. Ask which assessment template and attestation the partner expects you to produce. Ask how routing changes are tested before production, including whether the partner uses the hosted sandbox or a self-hosted staging environment, how test cards and processor sandboxes are handled, and how authorization rates are compared between the old and new gateway during a controlled split. Ask how reconciliation across two processors is built: which settlement files are ingested, how transactions are matched to Hyperswitch payment IDs, and who signs off on mismatches. Ask how stored token migration is validated, including record counts, sample decryption checks in a non-production environment and a documented rollback. Finally, ask how upgrades avoid payment downtime, and who owns each processor contract, its fees and its incident escalation. Request a written scope with deliverables, acceptance criteria and a named owner for every item.
Rollout phases and the output of each
The sequence moves a second processor from sandbox to live traffic in controlled steps, so each phase produces evidence the next one depends on: a confirmed PCI scope, tested connectors, rehearsed token moves, measured authorization rates and a signed reconciliation.
Confirm PCI scope with the QSA
The merchant's compliance lead and the Qualified Security Assessor (QSA) map which systems will receive, store or transmit cardholder data once Hyperswitch sits in front of the existing gateway. DeployOpen supplies the architecture diagram, data flow diagram and vault model choice, and the merchant decides whether the card vault stays in-house or sits with an external PCI vault provider. The step is done when the QSA agrees the in-scope system list in writing and the team knows which PCI DSS v4.0.1 requirements the change touches.
Set up connectors in a sandbox
DeployOpen deploys Hyperswitch in a non-production environment, using the hosted sandbox for early connector work or a local Docker or Helm-on-Kubernetes setup when the data must stay inside the client's environment. The engineering team configures the second processor's connector credentials in the sandbox, maps payment methods and confirms webhook delivery back to Hyperswitch. The output is a sandbox connector configuration with successful test authorizations, captures, refunds and webhook events logged for each supported payment method.
Test routing in staging with test cards
The staging environment mirrors production routing rules, including the first gateway as default and the second processor as a candidate. DeployOpen runs the processor's test card scenarios, including declines, soft declines, 3-D Secure challenges and partial captures, and the merchant's QA team checks checkout behavior in each flow. The step closes with a test log that shows each routing rule selecting the intended connector and each fallback firing when the primary returns an error, signed off by the merchant's payments owner.
Rehearse the stored card token migration
Stored cards move between vaults only after a rehearsal on a copy of the token set, because token migration is the step most likely to break recurring payments. DeployOpen exports a sample of tokens into the target vault in a controlled environment, the merchant confirms that each migrated token can be charged in the sandbox, and the team measures the number of tokens that fail and why. The output is a migration runbook, a failure list with resolution steps, and written approval from the merchant and the vault provider on the cutover method.
Compare authorization rates in shadow mode
Shadow routing sends a copy of selected transactions to the second processor for evaluation without changing which processor settles the payment, so the team can compare results before any customer traffic moves. DeployOpen configures the routing logic and reporting, and the merchant's payments analytics team defines the metrics per market, card type and issuer. The step is complete when the team has a documented authorization rate comparison, a list of decline reason differences, and a decision on which segments are ready for live traffic.
Shift live traffic by percentage
Live traffic moves to the second processor in stages, starting with a small share of eligible transactions and expanding only after the monitoring thresholds set in the previous step hold. Fallback rules stay enabled throughout, so a transaction declined by a processor outage can be retried on the other route where the rules and card scheme permit. The output is a cutover log that records each percentage change, the date and operator, the alerts reviewed and the rollback steps tested before each increase.
Sign off reconciliation and review decommissioning
Finance and operations confirm that settlement files, payouts and fees from both processors match Hyperswitch transaction records for the full cutover period. Once reconciliation is accepted, the team reviews what the first gateway still holds, including stored cards, webhook endpoints, API keys and audit logs, and decides what to delete, migrate or retain under the merchant's record retention policy. The step closes with a signed reconciliation report, a decommission checklist with owners, and evidence that the first gateway's stored data was removed or documented as retained.
How DeployOpen scopes and supports a second-processor build
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure, including the cloud accounts, data centers or air-gapped networks where a Hyperswitch deployment would run. For a second-processor build, that means DeployOpen can take on the Kubernetes deployment of the Router and Scheduler services, the PostgreSQL and Redis tier, the card vault decision, connector configuration for the new processor, routing and fallback rules, and the Control Center setup, and it can also run security testing against the new payment paths. Scope should name which of these pieces are in and which stay with your own platform or processor teams, because the vault model and the connector list change the effort more than anything else.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. A Qualified Security Assessor or the relevant certification body makes the PCI DSS determination, and the Attestation of Compliance is issued by the assessor or by the merchant's own validation process. Ask any partner to show, in writing, which artifacts they will produce for your assessor, such as network diagrams, configuration baselines, key management records and change logs, and which decisions remain yours. Most engagements are fixed-scope: scope, deliverables and timelines are agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers, which suits a payment stack that must track new Hyperswitch releases and processor API changes after go-live.
DeployOpen does not publish a price list. A quote follows from the written scope, so the fastest route to a useful number is a scope document that lists processors and payment methods per market, the vault model chosen, the number of routing rules, the environments to be built, and the testing and cutover plan. Ask for the one-time build fees separately from any recurring retainer, and ask what each excludes, such as processor sandbox access, the external vault contract, HSM hardware or your own PCI DSS assessment. Confirm these items with the partner and with your processors before signing, because they are the usual sources of change requests.
