How to run a payment orchestration RFP with the right questions
If you are a finance or payments lead choosing a partner to place a self-hosted orchestration layer in front of your existing processors, this section gives you a neutral question set, what a good answer contains, and the answers that should worry you. Send the questions in writing before any demonstration, and ask for answers tied to your own environment: the processors you already contract with, the payment methods and markets you serve, and where your card data and routing logic would physically sit. Vague answers about "our standard setup" are a warning sign on their own. Assign answers by function. Payments should answer connector setup, routing and retry logic, and failover. Security should answer vault isolation, key management, and the PCI DSS responsibility split. Finance should answer reconciliation and settlement, and engineering should answer upgrade and rollback procedures. Ask each respondent to name the specific Hyperswitch components involved, such as the Router service, the card vault, the encryption service, and the Control Center, and to say which are yours to operate. Hyperswitch is open source under Apache 2.0, so a partner can show you the code and configuration they run. The same questions apply whether the partner builds on Hyperswitch or on another stack.
Ask for the written PCI DSS responsibility matrix first. If a partner cannot state, for each component, who holds the controls and who signs the attestation, the rest of the answers will be hard to verify. Hyperswitch's own documentation states that a merchant running the in-house vault model is fully responsible for PCI DSS certification and data handling, so confirm which of the three documented vault models your partner proposes and what that choice means for your scope.
Questions on Hyperswitch connectors and routing setup
How do you configure Hyperswitch connectors to the processors we need?
Ask the partner to confirm, in writing, the exact connector list, the Hyperswitch release each connector was tested against and the credential model for each processor. Hyperswitch documents connectors to more than 100 processors, including Stripe, Adyen, PayPal, Worldpay and Checkout.com, but support depth varies by processor and payment method, so a listed connector does not mean every flow works in your market. A good answer names the connector version, the merchant account owner and the sandbox used for each processor, and states which features are verified and which are not. Request a connector inventory that lists processor, payment methods, markets, currencies, 3DS support and the named internal owner for each contract. Confirm who holds processor credentials and where they are stored before any production traffic flows.
What should a written routing matrix contain before go-live?
A written routing matrix should map every combination of market, currency, payment method, card brand and merchant entity to a primary connector and an ordered fallback list. Ask for the matrix as a versioned document, not a dashboard setting that only the engineer can read. Each rule should state the trigger (for example, a decline code class or a cost threshold), the owner who approved it and the date it took effect. Illustrative example: a rule might send domestic debit cards in one market to a local acquirer first and fall back to a global processor only on specific soft declines. Ask the partner to show how the matrix is stored, how changes are approved and how an unapproved change would be detected. Intelligent routing features are documented separately, so confirm which routing logic is rule-based and which is data-driven before relying on either.
How is retry logic configured and kept from double charging customers?
The partner should explain which declines trigger a retry, how many attempts are allowed, how long the system waits between attempts and how it avoids a second capture for the same order. Retries must respect issuer rules and the customer's consent for stored credentials, so ask who defined the retry policy and where it is documented. Request the idempotency design for payment and refund requests, the retry limits per payment method and the alerting that fires when retries cluster on one connector. Ask for test evidence showing that a simulated timeout followed by a retry produces one authorization, not two. Clarify whether retries are part of the default Hyperswitch behavior or custom configuration built by the partner, because that determines who maintains it after an upgrade.
What sandbox evidence should we require before routing real payments?
Require written test evidence from the sandbox for each connector and each rule in the routing matrix, not a general statement that testing was done. Hyperswitch offers a hosted sandbox and a local Docker setup, and processors provide their own test environments, so ask which environment produced each result. A useful evidence pack lists the test case, the connector version, the expected route, the observed route, the response codes and the tester's name and date. Include failure cases such as declines, timeouts, 3DS challenges and partial captures. Ask how the partner replays these tests after each routing change, and whether the results are kept as records you can retain under your own policy.
Who owns each processor contract and who can change its routing?
Each processor contract should have one named business owner, one technical owner and one approver for routing changes, and the partner should document all three. The implementation partner typically configures and maintains connectors, while your finance or payments team usually holds the processor contracts and pricing terms. Ask for a responsibility matrix that shows who can add or disable a connector, who can change a fallback order and who receives processor incident notices. Confirm how access to processor dashboards and API keys is granted and revoked. This matrix matters for your third-party risk file and for any PCI DSS responsibility split, so it should be signed off by your side, not only by the partner.
What does a fixed-scope connector and routing engagement cover, and what does it cost?
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms in the client's own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. For connectors and routing, the scope should list the processors, markets, payment methods, routing rules, retry policies and test cases included, plus any exclusions such as new processor onboarding after go-live. DeployOpen does not publish a price list, so the quote follows from that written scope. Costs recur for Kubernetes hosting, processor fees, ongoing support or retainers and re-testing after upgrades. Ask every bidder to separate one-time setup from recurring operations so the totals can be compared.
Can our team run connector and routing changes without the partner after handover?
Yes, if the handover includes the configuration in version control, a runbook for each common change and training for the people who will make them. Ask the partner to show how routing rules are exported, reviewed and deployed, and which Hyperswitch administrative actions require elevated access. Confirm the Control Center sign-in model before handover: the Control Center supports single sign-on through OpenID Connect only, not SAML, has no JIT or SCIM provisioning, requires users to be invited first and manages roles inside Hyperswitch rather than mapping them from your identity provider. Ask how these limits are handled in your access reviews. Your team should also know which changes need a test run and a second approver before they reach production.
How the card vault and key management are isolated
In this model, the card vault runs inside your own infrastructure as a separate Rust service from the Hyperswitch card vault repository, alongside the encryption service that manages keys. The Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling, so the partner's answers must show how that responsibility is carried out in practice.
- Locker location: Ask which cluster, namespace and cloud account or data center hosts the locker, and whether it sits in the cardholder data environment.
- Key storage and rotation: Ask where the master key is held (an HSM, a cloud KMS or a software store), how data keys are rotated, and how a rotation is rehearsed before it is needed.
- Key custody: Ask who holds split custody or dual control over key material and whether any single engineer can decrypt stored cards.
- Segmentation: Ask for the network policy that limits the vault to Router traffic only, and how Scheduler, PostgreSQL and Redis are kept off the vault's data path.
- Access logging: Ask which administrative and key-use events are logged, where the logs go, and how long they are retained.
A good answer names the systems, the owners and the evidence for each control. Ask for the network policy files and the most recent key rotation record before you sign.
Here Hyperswitch orchestrates payments while an external PCI vault provider, such as VGS or Tokenex, stores the card data. Hyperswitch documents this as self-hosted orchestration with an external or third-party PCI vault. Card data leaves your environment for the provider, so the isolation question shifts from where the locker runs to what remains in your cardholder data environment and how the provider is governed.
- Locker location: Ask which provider region stores the data, whether the provider is itself assessed for PCI DSS, and how you obtain its current attestation.
- Key management: Ask which party holds the encryption keys for the provider's vault, and whether any keys or tokens you hold could reveal card numbers on their own.
- Responsibility split: Ask for a written responsibility matrix covering the vault, the orchestration layer, the processors and your own systems.
- Segmentation: Ask which of your services still receive raw card data, which should be none in this model, and how the partner verifies that.
- Access logging: Ask for the logs you receive from the provider, the logs Hyperswitch produces, and how the two are correlated during an investigation.
A good answer shows that your environment never handles raw card data at all and that the provider's attestation is current. Confirm the provider's obligations with the provider directly, since DeployOpen does not issue attestations for third parties.
In this model, orchestration runs in your infrastructure while the card vault is provided as a service by Juspay through the SaaS Hyperswitch Vault. The Hyperswitch docs describe this as self-hosted orchestration with the SaaS vault. The key question is which parts of the card data path are yours and which are the vendor's, and how the connection between the two is protected.
- Locker location: Ask in which region the SaaS vault stores data, and whether that region matches your data location commitments.
- Key management: Ask who controls the keys protecting data in the SaaS vault, whether you can request key rotation, and what happens to stored tokens if the relationship ends.
- Key custody: Ask whether the vendor holds custody of keys on your behalf and what contractual and technical limits apply to its staff.
- Segmentation: Ask how traffic from Router to the SaaS vault is encrypted and authenticated, and which of your services can call the vault endpoint.
- Access logging: Ask which vault events are visible to you, how you export them to your own log store, and how long the vendor keeps them.
A good answer defines the boundary in writing, covering what your systems hold, what the vendor holds and how credentials for the connection are rotated. Confirm the vendor's current security documentation and contractual terms with Juspay.
Splitting PCI DSS responsibility between buyer and partner
PCI DSS responsibility in a self-hosted orchestration stack is divided by the deployment model, not by the platform alone. Each card below is a decision the RFP should force into writing before a partner is selected, so that the responsibility matrix, the scope boundary, the attestation and the evidence trail all point to the same owner.
Who signs the responsibility matrix
The responsibility matrix maps each PCI DSS requirement to the party that operates the control: the buyer, the partner, the processor or a vault provider. Ask the partner to draft it against the chosen deployment model, not a generic template. In the self-hosted, in-house PCI model, the Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling, so the buyer's signature must sit on every row that touches stored account data. Check that the matrix names an owner for each requirement and a review date.
Who owns the cardholder data boundary
The cardholder data environment (CDE) boundary decides which systems must meet PCI DSS controls. In a self-hosted deployment it usually includes the card vault, the encryption service, the database and cache tier that can hold tokens or account data, and the network paths between them. Ask who draws the boundary, who maintains the network diagram, and who approves any change that moves a component across it. A partner can build the segmentation, but the buyer should confirm in writing which side owns each data flow.
Who performs the annual scope confirmation
Scope confirmation is the yearly exercise that proves which systems are in scope and that segmentation works. The partner can run technical validation, such as checking that a system outside the boundary cannot reach the vault, but the assessment itself is owned by the buyer and its assessor. Ask the partner to specify what evidence it produces for each scope review, how often it re-tests segmentation after a routing or connector change, and who signs off on the scope statement that goes to the assessor.
How third-party service providers are managed
Every processor, acquirer, external PCI vault and hosting provider in the payment route can affect the cardholder data environment. Ask who holds the contract with each one, who collects their PCI DSS attestation of compliance, and who tracks expiry dates. If an external vault such as VGS or Tokenex is used, confirm whether its attestation covers the tokenization path you rely on. The RFP answer should list each provider in the route, its responsibility role, and the owner of its evidence file.
Who holds the attestation
The attestation of compliance is a document issued by a qualified assessor or self-assessment process chosen by the buyer, and it is held in the buyer's name. DeployOpen prepares systems, controls and evidence for that assessment, but it does not issue audit reports, attestations or certifications. Ask the partner to state this split in the proposal, identify who the assessor will be, and confirm that the buyer receives every artifact the assessor requests, including configuration exports and test results.
Who handles evidence collection
Evidence collection covers configuration baselines, access reviews, change records, vulnerability scan results, penetration test reports and logs proving that controls operated during the assessment period. Ask the partner which evidence it generates automatically, which it prepares on request, and where it is stored and for how long. Confirm who has read access to the evidence repository, who keeps the copies after the engagement ends, and how the buyer's team will receive the files without depending on the partner for each request.
How routing changes are tested before they reach live payments
A routing change moves through a written request, a test run in a sandbox or hosted environment, a staged rollout, watched metrics, and a sign-off with rollback criteria agreed in advance. Each step leaves a record that a covered institution can show as change management evidence.
Write the routing rule change request
The change starts as a written request that names the affected markets, merchant segments, payment methods, processors and connectors, and states the expected effect on routing order, retries and fallbacks. The requester is usually the payments owner at the buyer, and the partner's engineer drafts the rule in the configuration format used by the platform. The step is complete when the request and draft rule are stored in the change ticketing system and linked to a named approver. Ask the partner to show a sample ticket from a past change, including who could approve it and which fields are mandatory.
Review the change for impact and conflicts
Before testing, a reviewer checks the draft against the current routing configuration for overlapping rules, processor contract limits, currency and country coverage, and any effect on stored tokens or 3DS handling. The partner's engineer and the buyer's payments owner both confirm the processor contracts allow the proposed volume and that the fallback path still works if the new primary fails. The output is a short impact note attached to the ticket. Ask the partner how conflicts are detected and whether the check is a manual review, an automated diff, or both.
Test the change in sandbox or hosted environments
The rule is deployed to a non-production Hyperswitch environment, such as a self-hosted test instance or the hosted sandbox the vendor documents, and exercised with scripted payments across the affected connectors. Test cases cover approvals, declines, timeouts, retries, failover to the secondary processor, and refunds where the rule changes their path. The step is complete when every test case has a recorded expected and actual result. Confirm with the partner which test cases are standard, which are written per change, and whether sandbox behavior matches live processor behavior for the codes you depend on.
Stage the rollout by market or merchant segment
The change goes live to a small slice of traffic first, such as one country, one currency, or one merchant segment, while the rest stays on the previous rule. The partner's operations engineer enables the slice through configuration, and the buyer's payments owner confirms the scope in the ticket before traffic moves. Expansion to the remaining segments happens only after the staged slice has passed the monitoring step. Ask how the partner limits the slice, how it records which traffic received the new rule, and whether a single configuration change can revert the slice without a code deployment.
Monitor authorization rates and error codes
During the staged rollout, authorization rates, decline reasons, processor error codes, latency and retry counts are compared against a baseline taken before the change. The comparison runs for the staged slice and for a control group still on the old rule, so a market-wide shift does not hide a local regression. The output is a dashboard snapshot or report saved to the ticket at fixed checkpoints. Ask the partner which metrics are on the dashboard, who receives alerts, and how the baseline is set when seasonal volume or a processor incident distorts the numbers.
Agree rollback criteria in advance
Before rollout starts, the buyer and partner write down the conditions that trigger a rollback, such as an authorization rate drop beyond an agreed threshold, a rise in a specific processor error code, or a failed fallback path. The thresholds are set by the buyer's payments and risk owners, not by the implementation team alone. The criteria are recorded in the change ticket so the decision to roll back is made against written rules rather than judgment during an incident. Ask the partner to help define the thresholds and to show how a rollback is executed and logged.
Sign off and record the change
Once the change has run through all segments and the monitoring window closes without triggering rollback, the buyer's approver signs off in the ticket. The final record links the request, impact note, test results, rollout steps, monitoring snapshots and sign-off, and is retained under the buyer's records policy. For a covered institution, this record is the change management evidence the FTC Safeguards Rule at 16 CFR 314.4 expects organizations to adopt, and it should be reviewed against the buyer's own change procedure. Ask the partner which procedure applies, who holds the audit trail, and whether the logs of user actions in the platform can be exported for review.
Questions on reconciliation across processors
How does a partner ingest settlement files from each processor into Hyperswitch?
Each processor delivers settlement, payout and fee data in its own format and schedule, so the partner must build or configure one ingestion path per connector. Ask which files each processor in your route provides (daily settlement reports, fee advices, dispute files), how they are delivered (SFTP, API pull, portal download), and who owns the parsing rules when a processor changes its format. Ask whether the partner tests ingestion against real processor sandbox files before go-live and how a failed or late file is detected and reported.
How are payments matched to Hyperswitch records and the general ledger?
Matching works on keys such as the payment ID, connector reference and amount, with defined tolerance rules for timing and currency differences. The Hyperswitch docs describe reconciliation as a module, but the matching logic, the ledger export format and the mapping to your chart of accounts are typically configured or built per engagement. Ask the partner to show the match keys for each processor, how split settlements and multi-currency payments are handled, and which journal entries flow to your general ledger and in what format.
How are reconciliation breaks classified and aged?
A break is any item that does not match across the orchestrator, the processor report and the ledger, and each break should carry a category such as timing, missing settlement, amount mismatch or unknown reference. Ask the partner for the break taxonomy they will configure, the aging buckets they will report, and the thresholds that trigger escalation. Confirm whether aging and classification are built into the reconciliation module or require custom reporting, and what the partner must build versus what your team configures.
Who works the exception queue after go-live?
Ownership usually splits between the platform team, which keeps ingestion and matching running, and finance operations, which clears breaks and approves adjustments. Ask who is named in the runbook for each break category, what the service levels are for response (agree these in the written scope rather than assuming them), and who signs off write-offs. Also ask whether the partner provides ongoing monitoring of the queue as part of a retainer or handles only the initial setup under a fixed-scope engagement.
How does reconciliation cover refunds, chargebacks, partial captures and fees?
Each event type creates its own transaction lifecycle and must be matched separately, because a refund or chargeback does not reference the original settlement line in the same way. Ask the partner to map the following to ledger accounts:
- Refunds and their settlement timing
- Chargebacks, including reversal and re-presentment events
- Partial captures and the remaining authorized balance
- Processor fees, interchange and scheme fees, which the Hyperswitch docs cover under cost observability
Ask which of these the partner configures out of the box and which need custom code, and how they test each path with processor sandbox data.
What does the partner build versus configure for reconciliation and cost observability?
The Hyperswitch docs describe reconciliation and cost observability as modules, so much of the work is configuration: connectors, mapping, and report settings. Custom work usually includes ledger export formats, bespoke break rules, dashboards and integration with your ERP or accounting system. Ask the partner for a written split of configured versus custom items, the effort each carries, and which parts depend on your processors' data quality. Request a fixed-scope quote that lists each report and export as a deliverable.
How long must reconciliation records be kept if we are a broker-dealer?
If your firm is a broker-dealer, SEC Rule 17a-4(b) requires preserving records such as bills receivable or payable and bank statements for not less than three years, with the first two years in an easily accessible place. Ask the partner how settlement files, match results, break logs and ledger exports are stored, whether retention and immutability settings can be applied to them, and how records are retrieved during an examination. Confirm with your compliance counsel which records are in scope, since the rule text and your own record policy decide the retention design.
What drives the cost and time of reconciliation work?
The main drivers are the number of processors and payment methods, the number of settlement formats, the complexity of the ledger mapping, and the volume of refunds, chargebacks and multi-currency activity. Ask the partner to itemize each driver in the quote, state which items are one-time (ingestion builds, mapping, testing) and which recur (file monitoring, break handling support, updates when a processor changes its format). Ask what your own team must provide, such as sample files, chart of accounts and finance sign-off, because delays there often extend the timeline.
How upgrades are handled without payment downtime
An upgrade plan for a self-hosted Hyperswitch deployment has one job: protect in-flight payments, scheduled retries and webhook deliveries while the Router, Scheduler, PostgreSQL and Redis change underneath them. Ask the partner to show, for each component, what happens to a payment that is mid-authorization when the new version starts. Ask how the partner tracks releases: the Hyperswitch project publishes tagged releases on its GitHub releases page, and the partner should name who reads those release notes, how security fixes are triaged against routine versions, and how a decision to skip or defer a release is recorded.
Ask how the partner tests on a staging copy. A useful answer names the staging data set (sanitized, with no live card data), the connectors exercised against sandbox credentials, and a replay of real traffic patterns such as retries, 3DS challenges and refunds. Ask whether database migrations are backward compatible, meaning the previous Router version can still read the new schema during a rolling update. Ask how the Scheduler queue is drained before a Scheduler upgrade so that pending retry and revenue recovery jobs are not lost or run twice. Confirm the drain procedure, the monitoring that shows the queue reaching zero, and who may approve a restart.
Ask for the rollback path in writing. It should state which database changes are reversible, how long a previous container image and database snapshot are kept, and the point after which rollback is no longer safe. Release cadence, maintenance windows and emergency change rules must be agreed in writing for each environment (sandbox, staging, production), including who can start a window, how processors and merchants are notified, and how the partner's fixed-scope or retainer terms define upgrade responsibility. Any downtime figure in the proposal should be stated as an agreed commitment, not an estimate.
Answers that should worry you
Partners rarely say outright that they will cut corners. The warning signs show up in how they answer questions about PCI responsibility, keys, routing changes, reconciliation and upgrades. Use each card below as a follow-up question in the RFP and ask for the answer in writing.
PCI handled by the software
A partner who says the orchestration software makes you PCI DSS compliant has misread how scope works. Hyperswitch is software you run, and whether your environment meets PCI DSS depends on how you deploy, segment and operate it. The Hyperswitch docs state that under the in-house vault model the merchant is fully responsible for PCI DSS certification and data handling. Ask who signs the responsibility matrix and who pays for the assessment of your environment.
No written responsibility split
If the answer to who does what is verbal, or a generic statement about shared responsibility, the gaps will surface during an audit or an incident. The split should name each party for patching the core app server, operating the vault, rotating keys, maintaining connector credentials, and producing evidence for each control. Ask for a responsibility matrix as a deliverable before the contract is signed.
Unclear key custody
A partner who cannot say where the encryption keys live, who can access them, and how they are rotated has not isolated the card vault. The Hyperswitch repository lists a separate encryption service for key management, and the design choices around it determine whether keys sit in a hardware security module, a cloud key service or software. Ask for a key custody diagram, the list of named roles with key access, and the rotation procedure.
PAN stored outside the vault
Offers to keep card numbers in application databases, logs, spreadsheets or a convenience cache are a serious red flag. Stored primary account numbers outside the card vault widen the cardholder data environment and the PCI DSS scope that must be assessed each year. Ask the partner to show where every PAN touchpoint sits, which systems can read it, and how logs and backups are kept free of card data.
No staging test for routing
Routing rules change approval rates, cost and failover behavior, so an untested change can send live volume to the wrong processor. A credible partner tests each rule change in a staging environment with sandbox connectors, records the expected routing outcome, and promotes the change through a documented change management step. Ask for the test cases, the approval chain, and how a rule is reverted within the change window.
Reconciliation as an afterthought
If reconciliation is described as something the finance team will sort out later, expect unmatched settlements, delayed fee postings and disputes that cannot be traced to a transaction. Reconciliation should be designed with the connectors, covering authorization, capture, refund, chargeback and payout records across every processor in the route. Ask how daily matching works, which exceptions are queued for review, and who owns the ledger entries.
How to score partner responses
This table lists the criteria a buyer should score in a payment orchestration RFP, the written evidence each one requires, and what a strong, partial or weak answer looks like. Weights are set by the buyer's own risk, so the table is a starting structure rather than a fixed ranking. The main takeaway is that a score earns credit only when the partner can show an artifact such as a design document, test record or runbook.
| Criterion | Evidence required | Weight set by the buyer | Score guidance |
|---|---|---|---|
| Connectors and routing | Connector inventory for your markets, routing rule export or sample, retry and fallback configuration, and the change record for the last routing edit | Higher where processor mix or cross-border volume is concentrated in few providers | Strong: named connectors live in your markets with documented routing logic. Weak: a generic connector count with no market mapping |
| Vault and key isolation | Architecture diagram of the card vault and encryption service, key hierarchy, key custody model, and access logs for vault administrators | Higher where card data is stored in-house rather than with an external vault | Strong: vault and keys isolated in separate network and access zones with documented custody. Weak: isolation described only in a slide |
| PCI DSS responsibility split | Responsibility matrix naming who performs each requirement, current Attestation of Compliance or a dated plan to obtain one, and scope diagram | Higher for any deployment where the partner or buyer holds card data | Strong: a per-requirement matrix signed by both parties with the scope boundary drawn. Weak: a statement that the partner is compliant |
| Routing and change testing | Test plan for routing changes, staging results, approval records, and rollback steps for a failed change | Higher where routing rules change often or touch regulated flows | Strong: changes tested in a staging environment against sandbox processors, with approval and rollback recorded. Weak: changes made directly in production |
| Reconciliation | Sample reconciliation report, exception handling procedure, and the reporting fields that match processor settlement files | Higher where multiple processors settle to several accounts or entities | Strong: a sample report that ties authorizations, captures, refunds and settlements to the ledger. Weak: a dashboard screenshot without exception steps |
| Upgrades without payment downtime | Upgrade runbook, rollback plan, record of a past upgrade in a comparable environment, and the release tracking method | Higher where payment availability targets are contractual | Strong: a documented rolling or blue-green method with a tested rollback. Weak: a promise of zero downtime without a method |
| References and documentation | Named reference contacts you can call, handover documents, and runbooks covering incident and key rotation | Moderate, but higher for first-time self-hosted operators | Strong: references verified by your team and runbooks delivered before go-live. Weak: anonymous testimonials or documents promised after signature |
What buyers ask before hiring outside help on payment orchestration
Cost and effort for a self-hosted Hyperswitch engagement follow from the written scope, so the first request to any partner should be a fixed-scope proposal that lists each component being built or changed. The main cost drivers are the number of connectors to set up and certify, the vault model chosen (the native Hyperswitch Vault with in-house PCI, an external PCI vault provider, or the SaaS Hyperswitch Vault), the size of the Kubernetes footprint that hosts the Router, Scheduler, PostgreSQL and Redis, and the PCI DSS assessment of your own environment, which the assessor performs and the partner only prepares evidence for. Operations, meaning monitoring, patching, backups and on-call support, is usually the largest recurring item. Ask the partner to separate one-time work (design, connector setup, migration, testing) from recurring work (upgrades, support, retained testing) and to price each line on its own so you can see what a later vault or connector change will cost.
Duration depends on the same inputs, plus the state of your current processor contracts and the teams that must approve changes to them. Ask for a schedule that names the dependencies on your side: access to sandbox accounts for each processor, a decision on the vault model, network and identity approvals, and named owners for routing rules and reconciliation sign-off. Ask the partner which of these you must provide and what happens to the schedule if a processor sandbox is delayed. Confirm the Control Center sign-in method early, because Hyperswitch supports single sign-on through OpenID Connect only, without SAML, JIT or SCIM provisioning, so user onboarding and role management will be handled inside Hyperswitch unless you accept a different approach.
Whether you can do this yourself depends on the in-house team's experience with Kubernetes, PostgreSQL operations, PCI DSS scoping and processor certification. Hyperswitch is Apache-2.0 licensed, so the software itself has no license fee, but the Hyperswitch documentation states that in the self-hosted, in-house PCI model the merchant is fully responsible for PCI DSS certification and data handling. That responsibility is the strongest reason to ask for a written split of duties in the quote. Request a list of deliverables that will exist at handover (architecture diagrams, runbooks, upgrade procedure, test evidence for routing changes), and ask what remains your team's job after the first release, so the decision to build internally, bring in a partner or use a SaaS vault is made on documented costs rather than assumptions.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For payment orchestration, that means turning each RFP question into a written, testable design for a self-hosted Hyperswitch deployment, with evidence the client can pass to auditors and processors.
How we scope
- Engagements are fixed-scope, with processors, connectors, vault model and routing use cases agreed in writing before work starts.
- The written scope names which PCI DSS responsibilities sit with the client and which sit with the vault or processor providers.
- A quote follows from the written scope, so ask for each connector, environment and routing rule to be listed explicitly.
How we build
- Deployment covers the Hyperswitch app server, Scheduler, PostgreSQL with replica, Redis and the chosen card vault model in the client's cloud or data center.
- Connector setup and routing rules are configured, then tested in a non-production environment before any live traffic is routed.
- Key management, vault isolation and network segmentation are implemented and checked against the scope agreed with the client.
How we hand over
- Handover documents cover architecture, connector configuration, routing rule history, key custody and the PCI DSS responsibility matrix.
- Reconciliation procedures, runbooks for failover and upgrade steps are delivered so the client's own teams can operate the platform.
- Evidence packs are prepared for compliance assessments, but audit reports and certifications are issued only by independent auditors and certification bodies.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after the initial handover.
- Upgrade plans for Hyperswitch releases are documented with rollback steps and a staged validation in a separate environment.
- Confirm during the RFP which support hours, escalation paths and upgrade windows are included in any retainer you consider.
