Self-hosted subscription billing and PCI DSS scope

No. The Hyperswitch Control Center supports single sign-on through OpenID Connect only, and SAML is not supported. If your identity provider is SAML-only, you need an OpenID Connect bridge or a different admin access design before the dashboard can authenticate staff through your directory. Confirm the current SSO configuration steps in the Hyperswitch docs on configuring SSO for the Control Center and test them against your own identity provider before you commit to the design. Your identity team should also confirm how the OpenID Connect client is registered, how signing keys rotate, and what happens to sessions when a user is disabled in the directory.

No. The Control Center does not offer just-in-time provisioning or SCIM provisioning, so a user cannot be created automatically on first login or pushed from your directory. An administrator must invite each user first, which means joiner, mover and leaver steps have to be run as manual tasks or scripted through your own process. Offboarding deserves particular attention: removing a person in the identity provider does not, by itself, remove their Hyperswitch account, so your procedure must include disabling the invited user inside the Control Center. Record each invitation and removal as a ticket so the access history can be shown to an assessor.

Roles are managed inside Hyperswitch, not mapped from your identity provider. Group membership in your directory does not assign permissions in the Control Center, so each role change is a deliberate action in the dashboard. Design a small, written role model before go-live, separating people who configure connectors and routing, people who view reports, and people who can reveal or manage vault and key material. Review assignments on a fixed schedule and keep the review evidence. Confirm with the vendor and in your own test environment exactly which permissions each built-in role grants, because a role that looks read-only may still expose sensitive configuration.

MFA is enforced by your identity provider, not by a Control Center setting you can assume exists. When you use OpenID Connect, sign-in to the dashboard goes through your provider, so MFA policies on that provider apply to the login, and you should require them for every admin role. Confirm whether any local or break-glass accounts exist in your deployment, since accounts that bypass the identity provider would sit outside your MFA policy. Your team should test the full sign-in path, including password reset and account recovery, to make sure none of those flows skip the second factor.

If your business is a covered financial institution under the FTC Safeguards Rule, 16 CFR 314.4 requires multi-factor authentication for any individual accessing any information system, along with logging of authorized user activity and change management procedures. Invite-only onboarding and MFA at the identity provider can support those requirements, but they do not satisfy them alone. You also need logs of admin actions that reach the billing and payment systems, a documented change process for connector and routing changes, and evidence that your access reviews happen. Whether your organization is covered is a legal question to settle with counsel before you map controls to this rule.

Cost depends on how much identity integration, role design and evidence work the scope includes, and DeployOpen does not publish prices. Your identity provider team, your internal security and compliance staff, and any implementation partner each carry part of the work. The recurring cost is the ongoing access review, invitation and removal handling, and log retention, which continue after launch. Ask any partner for a written scope that lists the OpenID Connect configuration, the role model, the MFA verification, the runbooks for joiners and leavers, and the evidence package, along with who maintains each item after go-live.

Assessors usually ask for a current list of admin users and roles, the invitation and removal records for each person, sign-in records showing the MFA method used, and periodic access review sign-offs. For a PCI DSS assessment, the evidence should match the scope your assessor agreed, so the list of people who can reach the vault, encryption service and Control Center must be complete. Your assessor decides what is sufficient, and DeployOpen prepares systems, controls and evidence for those assessments but does not issue reports or attestations. Build the evidence pack while you configure the system, not after an audit request arrives.

Invite-only onboarding limits who can enter the dashboard, but it does not by itself limit what an admin can change. Pair it with role separation, so that changes to connectors, routing rules and vault settings require a role that is granted deliberately and reviewed. Add change control on top: approvals for configuration changes, a record of who made each change, and a check that production changes match an approved request. Test these controls in a non-production environment first, because the exact permissions in each role determine whether the separation holds.

The cost depends on the scope of the cardholder data environment, the vault model you choose, the number of payment and tax integrations, and the volume of evidence the assessor will need. A single gateway with hosted fields and no stored card numbers is a much smaller piece of work than a self-hosted vault that holds card data in your own environment. Costs fall into two groups. Implementation work is one-time: scoping, architecture review, network segmentation, configuration, logging and documentation. Recurring costs include the assessor's annual validation, quarterly scans where they apply, staff time for access reviews and change control, and platform upgrades. Ask any partner for a written scope that lists the systems in scope, the vault model, each integration and the evidence set before you compare quotes. DeployOpen does not publish a price list; a quote follows from that written scope.

The timeline depends on your environment, how many systems touch cardholder data, and when your assessor can review the work. A billing system that only receives gateway tokens will move faster than one that needs a self-hosted vault, network segmentation and a full review of administrative access. Two external dependencies often set the pace: the assessor's schedule and the acquirer's or payment brand's requirements for validation. Confirm the assessment type early, because a Self-Assessment Questionnaire and a Report on Compliance involve different effort. Ask your partner to put milestones, dependencies and the assessor's review window into the written scope so the timeline is tied to named work rather than estimates.

Most of the delay in these projects comes from missing access and missing decisions, not from the technical work. Plan to supply the following before work starts:

• Named contacts at your acquirer or payment service providers who can confirm validation requirements and approve the architecture.
• Read access to current architecture diagrams, network designs, cloud account structure, Kubernetes or hosting configuration and existing logs.
• Named owners for each change type, including catalog and price changes, gateway configuration, key management and access approvals.
• A decision on the vault model and on who holds responsibility for cardholder data handling.

Without these, the scoping step cannot close, and the assessor will ask for evidence that does not yet exist.

An internal team can do scoping alone if it has people who understand cardholder data flows, network segmentation, key management and the assessment type your payment brands require. The gaps usually appear in three places: confirming which components are in scope, documenting the evidence an assessor will sample, and keeping that evidence current through upgrades. Many teams keep the delivery work in-house and bring in outside help for the scope review or the evidence pack. Be honest with yourselves about who will maintain the setup after go-live, since PCI DSS validation is an annual exercise tied to the systems as they run, not as they were designed. DeployOpen can plan, implement and document the environment, but the assessment itself belongs to your QSA or the applicable assessor.

No. DeployOpen does not issue Attestations of Compliance, Reports on Compliance or any other validation. Those documents come from a Qualified Security Assessor for a Report on Compliance, or from the merchant or service provider for a Self-Assessment Questionnaire, each with an Attestation of Compliance that the payment brands accept. DeployOpen prepares the systems, network controls, configuration records and evidence that the assessor or your self-assessment will rely on. Ask your acquirer which assessment type applies to your setup before you scope the work, and ask any partner to state in writing what it delivers for evidence and what remains with your assessor.

The active version matters because it determines the requirements your assessor will test. PCI DSS v4.0.1 is the only active version, since v4.0 was retired on 31 December 2024 and v3.2.1 was retired on 31 March 2024, according to the PCI SSC. The PCI SSC ran a request for comments on v4.0.1 from 3 June to 20 July 2026 to start the next iteration, and as of October 2026 it had announced no release date for a new version. Ask your partner how they will track changes to the standard and whether the scope includes a review if a new version is published during your engagement.

The vault model sets how much of the cardholder data environment you own. In the self-hosted, in-house PCI model, the Hyperswitch documentation states the merchant is fully responsible for PCI DSS certification and data handling. In the model with an external PCI vault provider, such as VGS or Tokenex, the scope shrinks but depends on that provider's own validation. Ask whether the vault provider's attestation will be available to your assessor, how tokens are issued and who controls the keys. Get the answer in writing before you compare quotes, because the vault choice drives most of the cost difference between two proposals.