How Hyperswitch revenue recovery retries failed subscription payments
A subscription business whose recurring charges begin to fail needs a recovery layer that works alongside its billing system. The Hyperswitch revenue recovery module acts as a failsafe for recurring payments: it integrates with the merchant's existing subscription management system, keeps that system in charge of plans, invoices and customers, and retries failed transactions on its behalf. Consider an illustrative case: a subscriber's card is declined at renewal, the billing system marks the invoice as past due, and nothing else happens until the customer notices or a support ticket arrives. Teams that should evaluate the module are those where recurring revenue depends on charges the billing system triggers, but where that system has limited ability to decide how, when and through which route a declined charge should be attempted again.
According to the Hyperswitch docs, the revenue recovery retry engine analyzes more than 20 transaction parameters to choose a retry strategy, and the docs position it against simple dunning setups. A dunning setup typically applies one retry schedule to every failed charge, which can be easy to run but leaves little room for different decline reasons or customer segments. The practical question for your team is which of those parameters matter for your customer base, and how much of the retry decision you want to keep in your own configuration. Before scoping, ask the implementation team to list the parameters available in the version you plan to deploy, show how each strategy is selected, and explain what a retry looks like from the customer's side, including any notifications the subscription system sends.
The module is a configuration and integration project inside infrastructure you control. The Hyperswitch architecture docs describe a Router service and a Scheduler service with Producer and Consumer roles, backed by PostgreSQL with a master and replica setup and by Redis for caching and the scheduler queue. Your team will need to decide where those components run, how the subscription system sends payment requests and receives outcomes, and which saved payment methods are reused for later attempts. Card data stays in the Hyperswitch card vault or in the vault model you choose, so that vault decision also determines the scope of your PCI DSS obligations.
Decide early who owns retry timing. If the subscription system and Hyperswitch both retry the same invoice, customers may receive duplicate attempts and the two systems may report different outcomes. Agree on a single owner for each retry path, document which status events flow back to the subscription system, and test declined-card scenarios in the hosted sandbox or a local Docker setup before connecting live processors. Ask the provider to confirm which of your processors support the recovery flow you need, since Hyperswitch documents connections to more than 100 processors and the capabilities behind each connection still vary by processor.
Which revenue recovery configuration fits your subscription stack
This table compares four decisions that shape a Hyperswitch revenue recovery deployment: how failed invoices reach the platform, which vault model holds stored cards, how retries interact with routing, and which deployment target fits. Read each row for when the option fits and what it constrains. The main takeaway is that the vault model sets your PCI DSS scope, so settle it before choosing a deployment target.
| Decision | Option | When it fits and what it constrains |
|---|---|---|
| Subscription handoff | Existing subscription system sends failed payments to Revenue Recovery | Fits when your billing system stays the subscription record. Confirm the exact handoff contract in the Revenue Recovery docs and with your billing vendor before design. |
| Subscription handoff | Keep plain dunning in the billing system | Fits when failures are few and retry logic is simple. The Revenue Recovery retry engine analyzes more than 20 transaction parameters, so compare what your billing tool can actually evaluate. |
| Vault model | Self-hosted with the native Hyperswitch Vault (in-house PCI) | Fits teams ready to own card storage. The docs state the merchant is fully responsible for PCI DSS certification and data handling. |
| Vault model | Self-hosted orchestration with an external PCI vault such as VGS or Tokenex | Fits when card data should sit with a dedicated vault provider. You manage that provider contract, integration and its own compliance evidence. |
| Vault model | Self-hosted orchestration with the SaaS Hyperswitch Vault | Fits when you self-host orchestration but not the vault. Confirm where card data is held and the data path before go-live. |
| Retry routing | Auth-rate or multi-objective routing | Fits when retries should favor processors with better approval rates. Multi-objective routing re-ranks auth rate by processor cost, so cost inputs must be kept current. |
| Retry routing | Default fallback routing | Applies when no rule matches or a processor is ineligible. Confirm the fallback order for each processor before retries run in production. |
| Deployment target | Helm charts on Kubernetes, with guides for Minikube, AWS, GCP and Azure | Fits production. Requires Kubernetes operations, PostgreSQL with a master and replica, and Redis. From v1.124.0, a running Superposition service is required before upgrading. |
How revenue recovery differs from plain dunning
Plain dunning follows a fixed schedule. A failed charge triggers a reminder email, the payment is retried at set intervals, and the customer eventually receives a final notice or the subscription is cancelled. This works reasonably well when failures are mostly temporary, such as a card that was briefly over its limit. The Hyperswitch revenue recovery docs describe a different model. Its retry engine analyzes more than 20 transaction parameters to choose a retry strategy for each failed transaction, so the timing and path of a retry can differ from one customer to the next instead of following one calendar for everyone.
Some failures a reminder email cannot fix at all. Expired or replaced card credentials need an updated payment method from the customer or a credential update process, and retrying the old details will not change the outcome. Certain issuer declines need a different attempt, such as a different timing or processing path, which a fixed schedule rarely varies. Other declines are final, such as those indicating a closed account or a reported stolen card, and should not be retried. Your team should decide which of these categories each decline code falls into and what action follows, because a reminder only helps when the customer can act on it.
The two approaches can coexist. Your subscription system typically continues to own plans, invoices, the customer-facing notices and the cancellation policy, while the recovery module handles the retry logic for the payment attempt and integrates with that existing system. The practical risk is duplicated or conflicting messages, for example a dunning email sent by the subscription tool at the same time as a recovery notice. Before go-live, confirm in your own configuration which system sends each customer message, which system makes the final cancellation decision, and how the two exchange status updates for the same invoice.
Test your own decline mix before deciding how much plain dunning to keep. Export a representative sample of recent failed recurring charges and group them by decline code, processor and card type. For each group, estimate whether a reminder, a retry at a different time, a credential update or no action is the likely fix. This shows how much of your failed revenue depends on a customer action and how much depends on the retry logic. Ask your implementation partner to show how the engine would classify each code in your sample, and measure results in a controlled test rather than relying on a general recovery figure from any vendor.
Which Hyperswitch services carry recovery runs
Recovery runs across two Hyperswitch application services, a PostgreSQL primary and replica pair, and Redis. Each component produces a different health signal: queue depth, database capacity, replica lag and cache memory. Use these cards to decide what to monitor before the first recovery run in your environment.
Router service handles payment traffic
The Router is the Hyperswitch app server for payment API traffic. Recovery activity that touches payments passes through it, so request latency, error rates and server-side failures on this service are the first signals of trouble. Confirm in the architecture docs which Router endpoints your recovery flow and subscription integration call in your release.
Scheduler producer queues due work
The Scheduler runs as a Producer and a Consumer. The Producer selects scheduled work and places it on the queue, so a gap in production means retries never reach the queue at all. Monitor whether the Producer keeps pace with due items and alert when expected items stop appearing. Confirm with the docs which task types the Producer creates in your release.
Scheduler consumer executes retries
The Consumer takes queued tasks and runs them, which is where retry attempts reach the processor. A growing backlog means retries run late, so queue depth and the age of the oldest queued task are the measures to track. Watch for repeated task failures, which can indicate a stuck queue rather than a healthy one. Confirm the consumer scaling model and task retry behavior for your release.
PostgreSQL primary holds recovery state
PostgreSQL stores the payment and recovery records that the services read and write. The primary takes writes, so its connection count, storage growth and write latency set the capacity limit for the stack. Plan headroom for peak billing days in your subscription calendar, and confirm with the docs which writes recovery adds to the database.
Replica lag affects read freshness
The replica serves reads, and a replica that falls behind the primary can return older attempt or status data. For recovery, that can mean a retry decision based on stale state or a dashboard that trails live activity. Monitor replication lag as a standing metric, set alerts on sustained lag, and confirm with the docs which read paths use the replica in your release.
Redis caches and queues scheduler work
Redis serves two roles: caching and the scheduler queue. Because queued recovery tasks live in Redis, memory pressure, eviction behavior and persistence settings matter as much as cache hit rate. Monitor memory use, queue depth, evictions and restarts, and confirm with the docs and your own deployment how Redis persistence and eviction are configured before go-live.
How to set up Hyperswitch revenue recovery alongside your subscription system
This sequence takes a self-hosted Hyperswitch stack from a pinned release to live revenue recovery beside an existing subscription system. Each step ends with a check, so the team can confirm the dependency, vault, event and routing decisions before real recurring payments depend on them.
Confirm release, dependencies and Superposition
Start by pinning the Hyperswitch release and listing its dependencies in a written plan, owned by your platform team. From v1.124.0 onward, Superposition is a required configuration dependency, so a Superposition service must be running before you upgrade to that version. Check the compatibility matrix on the GitHub releases page for Control Center and web client versions, and confirm each component version against the release you intend to run. The step is done when you have a version pin, a dependency list and a named owner for each component.
Stand up a test environment
Run a non-production Hyperswitch stack using the Docker-based local setup for an individual engineer, or the Helm charts on Kubernetes for a shared environment. The hosted sandbox is available for early API testing. The stack includes the Router and Scheduler services, backed by PostgreSQL and Redis, so confirm both data stores are provisioned before deploying. Connect at least one processor sandbox account and sign in to Control Center. The check is a successful test payment that appears in Control Center, which confirms the core services are reachable and the dashboard works.
Choose the vault model early
Decide which of the three documented self-hosted vault models you will run before any card data moves: the native Hyperswitch Vault under an in-house PCI model, an external PCI vault provider such as VGS or Tokenex, or the SaaS Hyperswitch Vault. The in-house model makes you fully responsible for PCI DSS certification and data handling, so bring in your compliance lead and assessor at this stage. Record the decision with the owner of the vault and the list of systems in PCI scope. The check is a signed design note that names the vault, its operator and every system that touches card data.
Connect failed-invoice events to revenue recovery
Map the events your subscription system emits for failed invoices, declined renewals and card updates to the recovery inputs described in the Hyperswitch revenue recovery docs. Your subscription system stays the system of record for plans, invoices and customers, while Hyperswitch handles the retries of failed recurring transactions. Confirm which event types your subscription platform can send, how it signs and retries deliveries, and whether it can resend events that were missed. The check is a test renewal that fails in the subscription system and arrives in Hyperswitch with a matching payment reference.
Migrate stored credentials through the vault
Move saved payment credentials into the vault model chosen earlier, and link each subscription's stored credential to its Hyperswitch customer and payment method. Ask your current vault or processor in writing whether tokens or card data can be exported, and on what terms. That answer decides whether migration is a token transfer or whether customers must re-enter card details. Run the transfer in the test environment first, using a small set of test subscriptions. The check is that each migrated subscription charges successfully in the test stack using its new reference.
Configure retry routing and fallback rules
Set the routing strategy for recovery attempts in Control Center. Hyperswitch documents six strategies: rule-based, volume-based, auth-rate, multi-objective (auth rate re-ranked by processor cost), least cost routing for debit networks, and default fallback routing for when no rule applies or a processor is ineligible. Begin with rule-based routing and a fallback that finance can explain, then add more advanced strategies once you have baseline results to compare against. The check is a test transaction that shows which processor receives a retry under each rule you configured.
Verify recovery with test declines
Simulate declines using the test cards and decline codes your processors document, and confirm that each one triggers the retry path you intended. The Hyperswitch docs say the revenue recovery retry engine analyzes more than 20 transaction parameters to choose a strategy, so test a range of card types, networks and decline reasons. Ask your subscription team to run a full failed renewal cycle and confirm the final outcome of each attempt is visible in Control Center. The check is a test subscription that fails, retries and reports its final outcome in Control Center, with each decline type logged.
How the retry engine chooses a strategy for each failed payment
The Hyperswitch docs say the revenue recovery retry engine analyzes more than 20 transaction parameters before it chooses a retry strategy. Do not plan around a list you remember from another product or from a summary. During scoping, pull the full parameter list and the decline handling logic from the revenue recovery docs for the version you will deploy, and confirm them with Hyperswitch if anything is unclear. Parameter sets can change between minor releases, so record the version alongside the list. For each parameter, note its source: the subscription system, the processor response, or the Hyperswitch payment record.
Some parameters will come from your subscription system, not from Hyperswitch. Billing period, plan, invoice amount, customer tenure and dunning state may all sit in that system, so your integration must pass them through reliably on every failed charge. Missing or inconsistent fields can change the retry decision in ways that are hard to see in production. Assign an owner to each field, define how it is validated, and decide what should happen when it is absent. Ask the vendor whether the engine applies defaults in that case and what those defaults are.
Retry choices sit alongside routing, and the two must be planned together. The docs describe six routing strategies: rule-based, volume-based, auth-rate, multi-objective (auth rate re-ranked by processor cost), least cost routing for debit networks, and default fallback routing for when no rule applies or a processor is ineligible. A retry that passes back through routing may reach a different processor than the original attempt. Confirm whether retries re-evaluate routing, which strategy applies to recurring merchants, and when default fallback takes over. To shape these decisions, you must supply processor contracts, rule definitions, weighting choices, debit network preferences and the cost data that multi-objective and least cost routing depend on.
Before go-live, build a decision test matrix with illustrative failed payments covering each decline type, customer segment and routing strategy you intend to use. For each case, check the logs or Control Center records to confirm which parameters were recorded and which strategy and processor were selected. Also plan for the risks that follow from automated retries: repeated attempts on a cardholder's account, customer messages that arrive out of sequence, and processor or card scheme limits on retry frequency. Agree on those limits with each processor in writing and set alerts for retry volumes that exceed what you expect.
Card data, PCI DSS scope and access for recovery retries
Recovery retries need stored credentials, so the vault model you choose sets your PCI DSS scope and who must be contracted for data handling. The same decisions shape how operators sign in to the Control Center and how personal data is processed.
Self-hosted in-house PCI vault
The native Hyperswitch Vault keeps card data inside your own deployment, using the card vault service and encryption service described in the architecture docs. The Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling under this model. Before you choose it, confirm with your qualified security assessor who will operate the vault, who holds the encryption keys, and who maintains the controls that scheduled retries depend on.
External PCI vault provider
Self-hosted orchestration with an external PCI vault provider, such as VGS or Tokenex, moves card storage into the provider's environment while Hyperswitch keeps routing and retries. This changes which systems fall in your PCI DSS scope, so the assessor must review the data flow between your router and the vault. Confirm the provider's own attestations, token support for each connector you use, and how stored credentials are returned for a retry attempt.
SaaS Hyperswitch Vault with self-hosted orchestration
In this model the router runs in your infrastructure, but card storage uses the SaaS Hyperswitch Vault. Recovery retries then depend on network paths and availability between your deployment and the hosted vault, so test how scheduled retries behave during an outage. Ask for contract terms covering where card data is stored, how long tokens persist, and how deletion requests are handled.
Control Center SSO through OpenID Connect
The Control Center supports single sign-on through OpenID Connect only, and SAML is not supported. Your identity provider must offer an OIDC client that issues the claims Hyperswitch expects, so confirm this with your identity team before design work starts. Test sign-in in a non-production instance, and follow the Control Center SSO guide for the version you deploy.
Invite-first access and Hyperswitch roles
Users must be invited before they can sign in, and the Control Center offers no just-in-time or SCIM provisioning. Roles are managed inside Hyperswitch, not mapped from identity provider groups, so every role change is an administrator action in the dashboard. Confirm how account removal works for leavers and schedule regular reviews of the user list against HR records.
GDPR Article 28(3) processor terms
Where a third party such as a vault provider, a hosted vault or an implementation partner processes personal data for you, GDPR Article 28(3) requires a written processor contract. It must bind the processor to documented instructions, including for transfers, and to the security measures required by Article 32. Obtain each provider's data processing terms before any card or customer record moves, and have counsel review them against your scope.
Trade-offs between in-house recovery and an outsourced setup
The decision with the longest cost tail is who owns the recovery logic and the infrastructure it runs on. Self-hosting the revenue recovery module keeps retry decisions, subscription events and card references inside your environment, but your team then operates the Router and Scheduler services, the PostgreSQL primary and replica, the Redis queue and the card vault. The Hyperswitch docs state that under the self-hosted, in-house PCI model the merchant is fully responsible for PCI DSS certification and data handling. An external PCI vault provider or the SaaS Hyperswitch Vault moves part of that burden out, but adds a third party to the card data path, a contract to manage and an exit plan to write. Confirm which vault model your PCI scope assumes before you estimate operational work.
Monthly minor releases will set the pace of your upgrade workload. The GitHub releases page lists v1.126.0 (August 24, 2026), v1.127.0 (September 28, 2026) and v1.128.0 (October 16, 2026), and each carries a compatibility matrix for Control Center and web client versions. The last two releases landed under three weeks apart, so a fixed monthly maintenance window will not match the cadence. Each upgrade needs a matrix check, a staging run of recovery retries against your subscription system, and a tested rollback. Decide in advance how far behind the current release you are willing to run, and who signs off on each upgrade.
Superposition is the dependency that can stop an upgrade before it starts. The v1.124.0 release notes state that Superposition became a required configuration dependency, and that a Superposition service must be running before you upgrade to that version. Any later upgrade inherits that requirement. Decide whether Superposition runs in the same cluster as the recovery stack, who patches and backs it up, and what happens to the recovery path if it is unavailable. Read the release notes for the version you plan to run and confirm, with Juspay or in your own staging environment, what Superposition stores and how it fails.
Keeping recovery healthy in production is ongoing work that sits across several roles. A payments operations owner needs to read retry outcomes against the subscription system and notice when processors change how they respond to retries. A platform engineer watches scheduler backlog, database replica lag, Redis health and certificate or key rotation for the encryption service. A security owner keeps the evidence that PCI DSS or SOC 2 assessors will ask for, including access reviews and change records for each upgrade. Before go-live, agree who receives each alert, what threshold triggers a page, and who can stop a failing retry configuration.
A one-time fixed-scope build and a retainer answer different questions. The fixed-scope build covers agreed design, configuration, integration with your subscription system, staging validation and handover, with scope, deliverables and timelines confirmed in writing before work starts. A retainer covers ongoing support, upgrades and continuous testing on terms you agree, which is where monthly releases and Superposition changes are absorbed. In a quote, ask which releases are included, how a release that breaks the compatibility matrix is handled, how Superposition upgrades are scheduled, and what response expectations are written into the contract.
What to confirm about revenue recovery in your environment
These checks determine whether the revenue recovery module fits your subscription stack and processors. Each item changes scope, upgrade timing or the amount of integration work, so confirm them in writing before the statement of work is signed.
Release line and module settings
Confirm which Hyperswitch release line includes the revenue recovery module and which settings it exposes in that release. Release notes and the GitHub releases page list each version with its compatibility matrix for Control Center and web client versions, so check the exact version you plan to run against both the notes and the module documentation. Record the module's settings for that version in your change record, because settings may change between minor releases.
Subscription events the recovery needs
Recovery works alongside your existing subscription system, so that system must send the events the retry logic depends on, such as failed invoice or renewal attempts and subscription state changes. List every event your platform emits, identify which ones reach Hyperswitch, and confirm each payload carries the identifiers needed to tie a retry to the original subscription, invoice and customer. Ask your engineers to test each event in a non-production environment before go-live.
Subscription vendor integration
DeployOpen does not claim an integration with any specific subscription vendor unless that integration is confirmed in writing for your engagement. Ask whether the scope includes building the event bridge to your current billing system, which usually depends on access to its webhooks or APIs, and who maintains that code after handover. A generic integration pattern and a vendor-specific connector are separate deliverables, so name the one you need in the statement of work.
Connectors for your processors
Retries only run through processors that have a configured connector in your deployment. Map each processor and payment method in your recurring book to a Hyperswitch connector, and confirm that connector supports the retry path you need, including the operations used for recurring charges and the data it must receive. The Hyperswitch README says it connects to more than 100 processors, but that count does not confirm support for your specific processor, region or payment method.
Superposition for v1.124.0 and later
The Hyperswitch v1.124.0 release notes state that Superposition became a required configuration dependency, and a Superposition service must be running before you upgrade to that version. Check whether your current stack already runs Superposition, who operates it, and how its availability is monitored, because a missing service blocks the upgrade. Confirm whether the same requirement applies to each later release you plan to run.
Decline types the module covers
Recovery decisions depend on the decline reason, and the Hyperswitch docs say the retry engine analyzes more than 20 transaction parameters to choose a retry strategy. Obtain the decline code list from each processor you use, map those codes to retry, stop or customer-action outcomes, and confirm which ones the module treats as retryable. Test a sample of soft and hard declines in a sandbox so you can see the chosen strategy for each before live traffic.
Hyperswitch revenue recovery questions buyers ask before hiring help
What drives the cost of a Hyperswitch revenue recovery build?
The main cost drivers are the number of subscription systems and processor connections in scope, the number of environments you run, and how much of the dunning policy must be decided before the build starts. Who gets paid: a fixed-scope engagement covers the design, configuration, integration, testing and handover work agreed in writing, while your team covers internal reviews, approvals and business decisions. One-time versus recurring: the build is one-time, while hosting, Kubernetes capacity, PostgreSQL and Redis operations, upgrades and support recur. Ask any quote to itemize integrations, environments, testing and handover, and to state whether upgrades and retainers are priced separately. A quote follows from the written scope, so a precise list of systems and retry rules produces a more precise figure.
How long does a fixed-scope Hyperswitch recovery project usually take?
Duration depends mainly on how many subscription systems and processor connections are in scope and how many environments must be built and tested, from development through production. Each added integration brings mapping, testing and sign-off work, and a stack that must pass through staging and a production change window takes longer than a single sandbox build. Finance decisions on retry timing, customer messaging and escalation can also set the pace, often more than the engineering does. This page does not give a fixed duration. Ask for a timeline with milestones in the written scope, and confirm whether it assumes sandbox processor accounts and subscription system test data are available on the first day of the project.
What do we need to give the implementation team before work starts?
Before work starts, you usually provide access to your subscription management system, including test data and the events or webhooks it sends when a charge fails. You also provide processor credentials for sandbox and production accounts, delivered through your own secrets process. A named owner must approve the dunning policy, covering retry timing, number of attempts, and when a customer is contacted or access is paused. Infrastructure access matters too: a Kubernetes cluster or cloud account where the stack will run, database and Redis provisioning, and network paths to each processor. Agree in writing who holds each credential, who signs off each stage, and how changes to the retry policy are approved after go-live.
Can our internal engineering team build Hyperswitch revenue recovery alone?
Yes, an internal team can build it alone if it already runs Kubernetes, PostgreSQL and Redis in production and has engineers who understand recurring billing and payment failure codes. The software is licensed under Apache 2.0, so the decision rests on labor, skills and operating capacity. The harder parts often sit outside the code: choosing a card vault model, which determines PCI DSS responsibility, aligning retry rules with finance, and keeping pace with monthly minor releases. Teams with only one or two engineers available for on-call work often find the ongoing operational load decides the question. A partner can take on the build, the handover and retainer support. The choice comes down to capacity and risk tolerance, and both options need a written plan for upgrades and incident response.
How do upgrades and retainers change the total cost of ownership?
Upgrades and retainers add recurring effort on top of the one-time build. Hyperswitch ships roughly monthly minor releases, and each release lists a compatibility matrix for Control Center and web client versions. Some releases add hard dependencies: the v1.124.0 release notes made Superposition a required configuration dependency, so a deployment needed a Superposition service running before it upgraded to that version. Each upgrade calls for regression testing of routing, retries and reconciliation, plus a rollback plan. A retainer covers ongoing support, upgrades and testing under a fixed agreement, while an internal team absorbs that work itself. Ask any quote to state the release cadence it assumes, how many upgrades are included, and how security patches are handled.
Does Hyperswitch revenue recovery work with our existing subscription system?
Yes. Hyperswitch Revenue Recovery is designed to integrate with your existing subscription management system and act as a failsafe for recurring payments. When a charge fails, the retry engine chooses a retry strategy and carries out the attempts, while your subscription system keeps ownership of plans, invoices and customer records. The integration depends on the events your subscription system sends, the payment method data it can supply, and where retry outcomes are written back. Before design starts, document each handoff, including who owns the customer communication and how a successful retry updates the subscription status. Those decisions usually shape the integration more than the Hyperswitch configuration itself.
What does the retry engine check before it picks a retry strategy?
The Hyperswitch docs say the revenue recovery retry engine analyzes more than 20 transaction parameters to choose a retry strategy. For engineers, the practical point is that the quality of the data you send matters, including payment method details, decline and error codes, and the timing of attempts. Check which parameters each processor connection actually returns, because a parameter that is missing or mapped inconsistently cannot inform the decision. Test with sandbox declines across every processor in scope. Ask the implementer to document which inputs come from your subscription system and which come from the processor, and how each retry outcome is recorded. Confirm the exact parameter list against the documentation for the release you deploy.
Does a self-hosted revenue recovery build change our PCI DSS scope?
The answer depends on the vault model you choose, because that decides where card data is stored. Hyperswitch documents three self-hosted models: self-hosted with the native Hyperswitch Vault, self-hosted orchestration with an external PCI vault provider such as VGS or Tokenex, and self-hosted orchestration with the SaaS Hyperswitch Vault. 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. Revenue recovery reads payment data and retries charges, so every component that touches cardholder data belongs in your scope analysis. Involve your qualified security assessor early. DeployOpen prepares systems, controls and evidence for assessments but does not issue attestations or certifications.
How DeployOpen scopes and delivers a revenue recovery build
DeployOpen plans, implements, integrates and supports self-hosted Hyperswitch revenue recovery inside your own infrastructure, alongside the subscription system you already run. Each build starts from a written, fixed scope that names the processors, subscription events and retry rules in play. Hyperswitch documents its retry engine as analyzing more than 20 transaction parameters, so the scope should record which of those signals your environment can supply.
How we scope
- The written scope names the subscription system, processors and Hyperswitch connectors that revenue recovery must work with.
- Scope records which transaction signals your environment can pass to the retry engine, and which it cannot.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build work starts.
How we build
- Deploy the Hyperswitch core and its PostgreSQL and Redis dependencies in your Kubernetes clusters or cloud accounts.
- Configure revenue recovery against the subscription events your billing system emits, confirmed in staging before go-live.
- Test retry paths in a sandbox with simulated failed payments, then document each rule as it is built.
How we hand over
- Handover includes deployment code, configuration, runbooks and documentation of retry rules, owned by your team.
- Walk your finance, billing and engineering owners through dashboards, failure codes and how recovery outcomes are reported.
- Hand over admin access, secrets locations and change procedures so your team can run retry configuration independently.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Hyperswitch releases roughly monthly, so each upgrade checks Control Center and SDK compatibility before rollout.
- Check Superposition is running before upgrading to v1.124.0, which made it a required dependency.
