Payment orchestration requirements checklist for buyers

How to use this payment orchestration requirements checklist

This checklist turns payment orchestration requirements into items you can verify. If you are a finance, product or technology leader choosing or building an orchestration layer, you probably already run several processors and carry some PCI DSS exposure, so vague goals like "reliable routing" will not hold up in a vendor review or an assessment. Each item below should be written as a testable statement: which processors and payment methods must work in which market, what a routing or retry rule does, where card data sits, and how a failed processor is handled. Every requirement needs a named owner, a market it applies to, and an evidence source such as a configuration export, a test record, a contract clause or an audit artifact.

Hyperswitch, the Apache-2.0 composable payments platform maintained by Juspay, is the open-source reference point used throughout this page. It is a starting structure, not a finished answer. Its public documentation describes connectors, routing, vaulting and reconciliation modules, but a requirement is only met in your environment once someone has configured it, tested it with your processors and recorded the result. Treat every capability claim, including connector coverage and vault deployment models, as a hypothesis to verify with the vendor, with a proof-of-concept run against your own processor accounts, and with your own test evidence before you sign off.

Start by assigning owners. Processor contracts, settlement terms and chargeback obligations usually belong to the finance or treasury team, while connector configuration, routing logic and retry policy belong to payments engineering, and key management and the card vault belong to security. Record who approves each change. Then work through the sections in order, marking each item as verified, planned or open. Items that remain open after a proof of concept are the ones to raise with any implementation partner before scope is fixed in writing.

Functional requirements: processors, payment methods, routing and retries

This table sets out what each functional requirement asks for, why it matters and how to verify it before committing to a processor mix. Read it as a list of tests to run in a sandbox with your own merchant accounts, since vendor connector lists show coverage claims but not how each processor behaves in your markets.

Requirement	Why it matters	How to verify
Processors and payment methods per market	Acquiring coverage differs by country, currency and card scheme, and a processor listed for a region may not support every local method.	Build a market-by-method matrix with each processor, confirm live merchant accounts per market, and confirm local methods with the processor in writing.
Connector coverage	Hyperswitch documents more than 100 processors and wallets such as Apple Pay and Google Pay, but coverage per market and per feature varies.	Confirm each required connector against your markets, currencies and capture or refund flows in the Hyperswitch sandbox before the scope is fixed.
Routing rules by entity	Separate legal entities or brands often hold separate merchant accounts, so routing must keep each entity's transactions on the correct account.	Test a sample transaction per entity and confirm settlement lands in the right account and reconciliation file.
Routing rules by geography and cost	Cost-based routing can lower fees, but it can also move traffic to a processor with weaker local acceptance or higher decline rates.	Run routing scenarios in a test environment, compare expected fee and approval outcomes per rule, and record which rule decided each transaction.
Retry and fallback logic	Retries on soft declines can recover sales, while retries on hard declines or without idempotency controls can cause duplicate charges.	Test each decline code class, confirm retries respect idempotency keys, and confirm which declines never retry.
Authorization rate comparison	Rate differences between processors guide routing, but they only mean something when measured on comparable traffic.	Use the same test cards, amounts and methods across processors, then compare results by market and method with an agreed measurement window.
Routing change testing	A routing rule change can shift large volumes at once, so untested changes create direct revenue and compliance risk.	Require a staging run for each rule change, a rollback path and a signed sign-off from the team that owns the processor contract.

Which security controls a self-hosted orchestrator must meet

With the native Hyperswitch Vault, card data is stored in the card vault (locker), a separate Rust service in the juspay/hyperswitch-card-vault repository that the architecture documentation describes as built for PCI DSS requirements. The vault runs inside your infrastructure, so the cardholder data environment includes the vault, its database, the encryption service that manages keys, and every system that can reach them. The Hyperswitch documentation states that in this self-hosted, in-house PCI model the merchant is fully responsible for PCI DSS certification and data handling, so your organization, not the software vendor, must produce the assessment and the attestation.

Card data location: Primary account numbers sit in your database and backups, so storage, replication and backup encryption fall within your assessed scope.
Attestation: Your organization or a qualified assessor must validate the environment; confirm the assessment type and who signs it before design starts.
Key management evidence: Document key generation, storage, rotation, split knowledge and destruction for the encryption service keys, and show who can access them.
Encryption controls: Show encryption of stored account data and of data in transit between the router, scheduler and vault, with key separation from the application.
Access and logging: Apply multi-factor authentication to every system with access to the vault and retain logs of authorized user activity, as the FTC Safeguards Rule at 16 CFR 314.4 requires for covered financial institutions.

Confirm with your assessor which PCI DSS requirements apply to your vault and key hosts before you choose this model.

Security requirements buyers should write into the RFP

These six requirements cover the parts of a self-hosted Hyperswitch deployment that carry the most payment risk: the card vault, the merchant dashboard, the logs, the network, the data in motion and at rest, and the testing cadence. Each one should appear in the RFP as a written requirement with a named owner and evidence the partner must produce.

Card vault isolation and key management

Hyperswitch stores card data in its card vault, a separate service from the core app server, and encrypts it through a dedicated encryption service for key management. Ask the partner to show where the vault runs, which network segments can reach it, who holds key custody, and whether keys are held in an HSM. Confirm which HSM options the partner supports and whether they are hardware-backed, cloud-managed or software-only, because that choice changes your assessment scope.

MFA and access control for the Control Center

The Control Center merchant dashboard can change routing, connectors and refunds, so it needs the strictest access controls in the stack. The Hyperswitch docs state that its SSO supports OpenID Connect only, with no SAML, no JIT or SCIM provisioning, and roles managed inside Hyperswitch rather than mapped from your identity provider. Require multi-factor authentication for every user, a documented invite and removal process, and a quarterly review of role assignments.

Audit logging of authorized users

Under the FTC Safeguards Rule at 16 CFR 314.4, covered financial institutions must log the activity of authorized users. For this stack, that means logging dashboard logins, routing rule edits, connector credential changes, vault reads and manual refunds, with each entry tied to a named individual. Ask where logs are stored, how long they are kept, whether they are tamper-evident, and who can alter or delete them.

Network segmentation of the cardholder data environment

Segment the Router, Scheduler, PostgreSQL, Redis and card vault into a defined cardholder data environment, and restrict every connection that crosses its boundary. Connector traffic to processors and any external vault should flow through controlled egress points. Ask the partner for a current data flow diagram, the list of systems in scope, and evidence that the segmentation was tested from outside the segment, not only reviewed on paper.

Encryption in transit and at rest

The Safeguards Rule requires encryption of customer information in transit over external networks and at rest. For a payment stack, that covers client SDK calls, connector API calls, database replicas, Redis caches, backups and the vault store. Ask which TLS versions and cipher suites are enforced, how database and backup encryption keys are rotated, and whether any cache or log can hold card or token data in clear form.

Penetration testing and vulnerability assessment cadence

Absent effective continuous monitoring, 16 CFR 314.4(d)(2) requires annual penetration testing and vulnerability assessments at least every six months. Write this cadence into the RFP for the whole orchestration stack, including the vault and the Control Center, and require retesting after material changes such as a new connector or a Hyperswitch upgrade. Ask for the scope, tester independence and remediation tracking for each finding. PCI DSS control IDs are referenced here by title only.

How PCI DSS scope and processor contracts shape the requirement list

The PCI DSS scope decision drives most of the other requirements on this list. Before you write a single connector requirement, decide which components touch account data: the Hyperswitch Router and Scheduler, the card vault, the encryption service for key management, the Control Center, the logs and the Redis and PostgreSQL stores that may hold card-adjacent data. Then decide whether the vault is in-house, an external PCI vault provider or the SaaS Hyperswitch Vault. Hyperswitch documents these as separate models, and the in-house model places PCI DSS certification and data handling fully on your organization. Each model changes your segmentation design, your annual scope confirmation and the list of third-party service providers you must manage. Confirm the scope with your qualified security assessor early, because it sets the answers to vault, logging, key management and network questions.

Processor contracts need three owners, and each owns a different set of terms. Finance or treasury owns commercial terms: pricing per market, settlement timing, chargeback and refund liability, minimum volumes and termination rights. Security owns the PCI DSS responsibility matrix, which should state for each processor whether it receives raw card data, tokens only or hosted fields, and where it is validated as a service provider. Engineering owns connector configuration and the technical clauses, such as supported payment methods, webhook delivery, data retention for logs and disputes, and the change notice period before a processor alters an API. Ask each processor for its current attestation of compliance and the responsibility matrix in writing, and check that the contract names those documents. Do not accept a verbal statement that a processor is covered by the orchestrator's assessment.

Before signing, confirm three points with each counterparty. First, whether stored tokens can be exported to another vault or processor, and under what conditions, because this decides whether a later switchover is possible without customer re-entry. Second, the data location commitments for card, transaction and payer data, which must match the data location requirement on this list. Third, the reconciliation file formats, cut-off times and dispute data they provide, since your finance team cannot reconcile what the contract does not describe. Record the answers in the requirements list as named, owned items so that the scope review, the routing tests and the vendor review all draw from the same source.

Integration requirements for orchestration, billing and reporting

A payment orchestrator rarely runs alone. Its routing decisions, settlement data and admin access touch the ledger, billing, fraud tooling, identity and analytics. Each integration below needs an owner, a data contract and a test before the processor go-live date.

ERP and general ledger posting

Settlement, fee, refund and chargeback events must post to the general ledger in a form finance can close against. Ask who maps Hyperswitch transaction states to ledger accounts, how batch files or APIs are sent to the ERP, and how a payment that was authorized but not settled is tagged. Confirm the posting format with your ERP team and with the processor's settlement reports, since the orchestrator does not define your chart of accounts.

Billing and subscription systems

For recurring merchants, the billing engine decides when a charge is due and the orchestrator decides where it goes and what happens on a decline. Confirm which system owns the subscription state, which owns retry schedules, and how stored network tokens move between them. Kill Bill is one open source option for the billing side. Test duplicate-charge protection before any retry logic goes live.

Fraud and 3DS providers

Fraud scoring and 3-D Secure authentication often run as separate services called during authorization. Ask which provider decides step-up, whether its decision can override a processor route, and how liability shifts are recorded for each transaction. Confirm with each provider which connectors Hyperswitch supports today, and whether the provider's data residency terms match your vault and transaction data location.

Identity provider for the admin console

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 the identity provider. Plan the joiner and leaver process for every admin account, and confirm these limits against the current SSO documentation before you write them into access policy.

Client SDKs for checkout

Hyperswitch lists client SDKs for web, Android, iOS, React Native and Flutter. Each checkout surface you run needs its own test matrix, its own release cadence and its own owner for the SDK version in production. Confirm which SDK versions your checkout apps depend on, how the orchestrator handles deprecated SDK versions, and whether card data ever touches your app code or stays inside the vault iframe or SDK boundary.

Data warehouse and reporting export

Finance, risk and operations teams need transaction, routing and reconciliation data outside the orchestrator's operational database. Ask which export methods are supported, how often data is refreshed, how card identifiers are masked before they reach the warehouse, and who approves each downstream copy. Confirm the export schema with the vendor and your data protection team, and document where each copy is stored and how long it is kept.

Operational requirements and how to verify them

This table pairs each operational requirement for a self-hosted Hyperswitch deployment with the evidence to ask for and the place it usually fails. Use it to turn vendor claims about uptime, upgrades and recovery into checks you can run before signing a scope. Requirements that depend on your own cloud target or processor agreements are marked for confirmation.

Requirement	What to verify	Evidence to request	Where it usually fails
Kubernetes deployment	Helm charts deployed to a named cloud target (AWS, GCP, Azure or your own cluster) with documented values for each environment	Deployment runbook, chart version pinned in the repository, cluster architecture diagram	Charts installed from defaults with no sizing, secrets or network policy decided for production
PostgreSQL and Redis availability	Primary and replica for PostgreSQL, Redis for cache and scheduler queue, with tested failover for each	Failover test records, replication lag alerts, Redis persistence and eviction settings	Replica never tested for promotion, or scheduler queue loss not considered during a Redis incident
Processor and orchestrator failover	Secondary processor for each market, documented fallback rules, and a tested path if the orchestrator itself is unavailable	Routing table by market and payment method, failover drill results, checkout behavior when the orchestrator is down	Fallback rules exist on paper but were never exercised against live connector credentials
Routing change testing and rollback	Each routing or retry rule change tested in a non-production environment, then released with a tested reversal	Change ticket, test cases with expected processor per scenario, rollback steps with owner	Rules edited directly in the production dashboard with no version history or approval
Upgrade and release handling	Staged upgrades that keep payment acceptance running, with a maintenance plan for database migrations; check release cadence on the Hyperswitch releases page before setting a schedule	Upgrade runbook, rollback plan for schema changes, record of the last upgrade in a staging copy	Upgrades applied during peak trading hours, or a database migration with no tested reverse path
Reconciliation and reporting	Daily matching of processor settlement files against orchestrator records, with exceptions routed to a named owner	Reconciliation report sample, exception aging, sign-off record from finance	Reconciliation run only at month end, leaving timing differences and refunds unmatched for weeks
Data location and backup	Where the card vault, transaction logs and backups are stored, with encrypted, tested restores to a separate location	Data flow map by region, backup schedule, restore test results with timing and who approved them	Backups copied to a region not covered by the data residency decision, or restores never tested end to end
Incident response and processor escalation	Severity levels, on-call rota, and named contacts at each processor and acquirer for outage and dispute escalation	Incident runbook, escalation contact list with current validity date, last tabletop exercise record	Escalation paths depend on one person, or processor contacts are not kept current

What buyers ask before hiring help with payment orchestration

How much does a payment orchestration requirements phase cost and what drives it?

The requirements phase is priced from a written scope, and no fixed figure applies to every merchant. The main drivers are the number of processors and acquirers, the number of markets and currencies, the payment methods in each market, how many entities and checkout flows must be covered, and which vault model you choose. A single-market merchant with one existing gateway needs a much smaller discovery effort than a group with several entities, multiple processors and stored cards to migrate. Ask any partner for a quote that lists the workshops, the deliverables (routing matrix, PCI scope statement, reconciliation design, failover plan) and the client-side time each one needs. Request that the quote separate one-time work from recurring support.

How long does a self-hosted payment orchestration rollout take?

The timeline depends on the scope agreed in writing, and no duration is set by default. The factors that most often set it are the number of processor connectors to build and certify, whether stored cards must move between vaults, the PCI DSS assessment work on your own environment, the number of routing and retry rules to test, and how long your processors take to approve changes. Reconciliation against finance records usually needs its own test cycle. Ask for a plan with phases, client dependencies and acceptance tests for each phase, so you can see which steps wait on your contracts, your PCI owner or your change board.

What does the client team need to provide for a payment orchestration project?

Four roles must be named before work starts, and each one controls a dependency. First, someone with authority over processor contracts must supply account details, certification access and fee schedules. Second, a PCI owner must define the cardholder data environment boundary and accept responsibility for the assessment. Third, a finance reconciliation owner must agree the settlement files, match rules and close calendar. Fourth, engineering must provide access to Kubernetes, PostgreSQL, Redis, identity and logging, plus change approval for production. Missing any of these usually moves the schedule more than the technical build does.

Can an internal team build payment orchestration without outside help?

An internal team can build it if it already has engineers who run Kubernetes, PostgreSQL and Redis in production, staff who understand card data handling, and people who own processor relationships. Hyperswitch is open source under Apache 2.0, so the software itself carries no license fee. The harder work is the surrounding operation: connector configuration for each processor, the card vault and key management, PCI DSS evidence, routing tests, reconciliation and upgrades without payment downtime. Compare your team's capacity for those tasks against the written scope of a partner, and decide which parts you will keep in-house.

Does self-hosting payment orchestration remove our PCI DSS obligations?

No. Self-hosting changes where the systems run, but it does not transfer PCI DSS responsibility away from you. In the self-hosted, in-house PCI vault model, the Hyperswitch documentation states that the merchant is fully responsible for PCI DSS certification and data handling. Using an external PCI vault provider reduces what your environment stores, but you still have to confirm scope, segment the network, and manage every processor and third-party service provider in the route. Ask your assessor or qualified security assessor to confirm the scope before you rely on any design. DeployOpen prepares systems and evidence for assessments but does not issue audit reports or attestations.

What should we ask a payment orchestration partner before signing?

Ask questions that expose how the work is done and who owns each risk. Request how they configure Hyperswitch connectors and routing rules and how each change is tested before release. Ask how the card vault and encryption keys are isolated from application services, and where the key management responsibility sits. Confirm how PCI DSS responsibility is split in writing, and what evidence they hand over. Ask how reconciliation works across processors, how upgrades avoid payment downtime, and what the handover and support model covers. Finally, ask for a fixed-scope quote with deliverables and dates agreed in writing, and check whether ongoing support is offered as a separate retainer.

Which Hyperswitch limitations affect our identity and access setup?

Check these before you design access for the Control Center. The Hyperswitch Control Center supports single sign-on through OpenID Connect only, and SAML is not supported. It has no just-in-time or SCIM provisioning, so users must be invited first. Roles are managed inside Hyperswitch rather than mapped from your identity provider. Plan a joiner, mover and leaver process that covers these manual steps, and confirm the current behavior in the Hyperswitch documentation for your version before you commit to a design. Ask your partner how access reviews will be evidenced for your assessor.

How to turn this checklist into a scoped selection

This sequence turns a long requirements list into a short, owned and tested set of platform and partner options, ending in a fixed written scope. Each step produces a artifact that the next step depends on, so the scope reflects what was verified rather than what was assumed.

List processors and markets first
Start by writing down every market you take payments in, the payment methods you must accept in each, and the processors and acquirers you hold or plan to hold contracts with. Include the entity that signs each contract and the currencies it settles in. Finance and payments operations usually hold this list, and the outcome is a single table that every later step refers to. The step is done when each market row names at least one processor and one owning entity, and gaps are marked as open questions.
Assign an owner to each requirement
Take each requirement from the checklist and name one accountable owner, not a team. Routing and retry rules usually sit with payments operations, card vault and key management with security, PCI DSS scope with compliance, processor contracts with procurement and legal, and reconciliation with finance. Record who signs off on each item and who is consulted. The step is complete when every row has one owner, and any requirement without a clear owner is escalated before technical work starts.
Run a sandbox connector test
Use a hosted sandbox to check the assumptions in your table before committing to architecture. Hyperswitch documents a hosted sandbox for testing, so connect a sandbox account for each processor you intend to use, send test authorizations, captures, refunds and a failed payment, and confirm how the response is normalized. Record which payment methods and 3DS flows actually work in the sandbox for each connector. The output is a dated test log tied to each market row. Processor sandboxes differ in coverage, so anything you cannot test must be listed as unverified.
Score each requirement as verified or unverified
Go through the checklist and mark every requirement as verified, unverified or not applicable. A requirement is verified only when you have evidence, such as a sandbox log, a vendor document, a configuration you reviewed or a written answer from the processor. Anything resting on a sales claim or a README line stays unverified until someone confirms it in your environment. Keep the evidence link next to each score. The step is done when no requirement is scored on memory alone, and the unverified list is short enough for each owner to close.
Shortlist platforms and implementation partners
Compare the remaining options against the verified requirements. For a self-hosted Hyperswitch option, check the deployment model you need for card data, including whether the card vault stays in-house, uses an external PCI vault provider or uses the SaaS vault, and confirm that the single sign-on method meets your identity policy. For each partner, ask for a written statement of which requirements they will implement, which they will test and which remain yours. The shortlist is complete when each candidate has a documented gap list that shows what it does not cover.
Agree a fixed written scope before work starts
Turn the verified requirements and the chosen platform into a written scope that names deliverables, the environments in scope, acceptance tests and the parties responsible for each item, including processor contract changes that sit outside the implementation. Most DeployOpen engagements are fixed-scope and agreed in writing before work begins, and the quote follows from that scope. Ask for a fee breakdown that separates one-time setup from recurring operations and upgrades. The step is done when both sides sign a scope that references the test log and the requirement scores from earlier steps.

How DeployOpen scopes and delivers payment orchestration requirements

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including payment orchestration built on Hyperswitch. We start by writing down the requirements in this checklist against your markets, processors and data location, then move to build and handover only once the written scope is agreed.

How we scope

We record the markets, payment methods and processor contracts that the written scope must cover.
We confirm which teams own each processor contract, card vault decision and PCI DSS responsibility before design starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.

How we build

We configure processor connectors, routing and retry rules, and fallback targets in your own cloud or data center.
We set up the card vault model you choose and document where stored account data and encryption keys reside.
We test routing changes, 3DS flows, and reconciliation exports against agreed acceptance cases before go-live.

How we hand over

We deliver architecture, configuration, runbooks and a PCI DSS scope description written for your assessor.
We document reconciliation and reporting procedures so finance and operations teams can run them independently.
We walk your teams through the handover so they can operate the platform and confirm each deliverable.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover platform upgrades, connector changes and periodic security testing of the orchestration layer.
We prepare systems and evidence for your compliance assessments, while independent auditors issue any reports.

Payment orchestration requirements checklist