Migrate from Stripe to Hyperswitch: what the move involves
The documented Stripe migration guide covers a specific set of Stripe UI elements, payment types and backends. Anything outside that list, including custom checkout flows, bespoke webhook handling and Stripe products the guide does not name, is design work that your team or a partner has to plan and build. On effort, the honest answer is that it depends on which Stripe products you use and how many of them fall outside the guide. A standard integration on the covered list is mostly configuration and testing. A broad Stripe footprint needs more planning. A written scope, produced after an inventory of your Stripe usage, is what sets the real estimate.
Start with an inventory. List every Stripe API object your application creates or reads, every front-end element it renders, and every server language and platform involved. Then map each item against the guide. The guide lists the payment sheet, card element and wallet element as supported UI elements, along with one-time and recurring payments, customers, refunds, cards, wallets, bank transfers and buy now, pay later methods. Each covered item still needs verification in your own environment, because a supported payment type can behave differently with your processors, currencies and return flows. Record the guide version you checked against, since the list can change between Hyperswitch releases.
Two Stripe features are listed as not supported. Payment Links and Stripe Checkout appear in the guide only as feature requests, so if your business depends on either, you need a replacement decision before work starts. The likely options are rebuilding the hosted page on supported elements or accepting a change to the customer journey. Backend coverage also needs a check. Node is listed as supported, and Python, PHP and Ruby are available on request, so confirm delivery for your language. On the commerce side, WooCommerce is supported while BigCommerce and Shopify are not, which can decide the whole project if your storefront is one of the latter.
Card handling changes the compliance picture. Hyperswitch's PCI documentation notes that Stripe no longer lets merchants accept raw card data from its dashboard, and that a PCI DSS Attestation of Compliance must be shared with Stripe support if raw card processing is needed. Ask whether any part of your current flow sends raw card data to a service, and which vault model you plan to use after the move, because that determines your PCI DSS scope. Do not treat the migration as complete until this question has a documented answer. A written scope should also cover parallel running, cutover and a rollback path, with the owner of each decision named.
Which Stripe capabilities map to Hyperswitch and which do not
This table compares Stripe products, SDKs and backends with their documented status in Hyperswitch's Stripe migration guide. Read each row as a go or no-go signal for your current integration, and treat any not-supported row as a custom build or checkout redesign. Confirm every status against the current Hyperswitch docs before you commit, because support changes between releases.
| Stripe capability | Hyperswitch status | Migration notes |
|---|---|---|
| Payment sheet, card element and wallet element | Supported | Documented UI elements in the Stripe migration guide. Confirm the Hyperswitch client SDK version that matches your web, Android or iOS app. |
| One-time and recurring payments | Supported | Confirm how your subscription logic, invoices and retries map to Hyperswitch flows before you cut over recurring billing. |
| Customers | Supported | Map Stripe customer IDs to Hyperswitch customer records during planning so saved payment methods can be linked. |
| Refunds | Supported | Test partial and full refunds end to end, including refund status handling in your order system. |
| Cards | Supported | Card acceptance depends on your vault model and processor connectors. Saved cards are covered by a separate import process. |
| Wallets | Supported | Confirm which wallets are enabled for each connected processor and each target market. |
| Bank transfers | Supported | Confirm the bank transfer methods and regions you need against the current connector list. |
| BNPL | Supported | Confirm provider availability per market and per connector before you rely on it in production. |
| Payment Links and Stripe Checkout | Not supported (feature request only) | A not-supported row means you need a custom build or a different hosted or embedded checkout design. Plan that work before setting a cutover date. |
| Node backend | Supported | Confirm the Hyperswitch SDK or API client version for your Node runtime and framework. |
| Python, PHP and Ruby backends | Available on request | Ask the Hyperswitch team for current status before scoping. Do not assume parity with the Node path. |
| WooCommerce | Supported | Confirm plugin version compatibility with your WooCommerce and Hyperswitch releases. |
| BigCommerce and Shopify | Not supported | A not-supported row means a custom build or a different checkout design is needed. Confirm current status in the docs before planning. |
How the documented quick migration covers Stripe SDKs and products
The documented quick migration is a published path for moving a Stripe integration onto Hyperswitch orchestration when your checkout uses the Stripe UI elements, payment flows and backends that the Hyperswitch Stripe migration guide lists as supported. Its value is that it gives you a known starting point. It does not make every Stripe product portable, so the first task is to map your current integration against that list before anyone estimates work or chooses a design.
The guide lists the payment sheet, card element and wallet element as supported UI elements, along with one-time and recurring payments, customers, refunds, cards, wallets, bank transfers and buy now, pay later. It lists Node as the supported backend, with Python, PHP and Ruby available on request, and it lists WooCommerce as supported while BigCommerce and Shopify are not. Confirm each item against your codebase. A custom checkout built directly on the Stripe API, or a backend in a language outside the supported set, is not covered by the quick path and needs its own plan for request mapping, webhook handling and token handling.
The difference between a supported SDK path and a custom integration matters for effort. On a supported SDK path, the front-end element and the server calls follow a documented pattern, so the work is mostly configuration, connector setup and testing. On a custom integration, your team must reproduce the behavior of every Stripe call it makes, including idempotency keys, error codes, retries and webhook event types, against Hyperswitch's API. Ask your partner or internal lead to produce an inventory of every Stripe endpoint and webhook your code calls, and classify each one as covered, mapped by hand or out of scope.
Stripe Checkout and Payment Links are listed as not supported, with support only as a feature request. If either is part of your revenue flow, the design must include a replacement flow before the migration starts. That replacement could be a hosted page you operate, an embedded payment sheet, or a payment link generated by your own application, and each option changes your PCI scope and your testing plan. Do not assume the Stripe-hosted page will continue to work during cutover.
Stripe's own changes to raw card acceptance also matter. Hyperswitch's PCI documentation notes that Stripe no longer allows raw card acceptance from its merchant dashboard, and that a PCI DSS Attestation of Compliance must be shared with Stripe support if raw card processing is needed. Whether you handle raw card data, and whether that affects where your card vault runs, determines your PCI scope. Record that question now as an open decision, and work through the scope analysis in the PCI section of this page before you choose a vault deployment model.
Documented migration paths, APIs and export routes
Hyperswitch documents several routes for moving a Stripe integration: a quick migration guide, APIs and client SDKs, the Control Center and a set of self-hosting options. The cards below describe each route and what to check against the docs before you plan the move. Confirm current export and import options with the Hyperswitch docs before committing to a sequence, because only the routes listed there should be treated as documented.
Stripe migration quickstart
The Hyperswitch Stripe migration guide is the documented starting point for this move. It lists the Stripe UI elements, payment flows, backends and platforms it covers, and it names items that are not supported, such as Payment Links and Stripe Checkout. Read the supported and unsupported lists against your own Stripe footprint before estimating the work.
Core APIs for payments and refunds
The Hyperswitch APIs are the server-side interface your backend would call once payments route through Hyperswitch. Map each Stripe API call your code makes, including payment intents, customers, refunds and saved payment methods, to its Hyperswitch equivalent. Gaps in that mapping, not the SDK choice, usually determine how much application code changes.
Client SDKs for web and mobile
Hyperswitch publishes client SDKs for web, Android, iOS, React Native and Flutter. If your checkout uses Stripe's payment sheet, card element or wallet element, confirm which Hyperswitch SDK covers the same surface on each platform. Test each client separately, since a checkout working on web does not confirm the mobile flows.
Control Center for processors and payments
The Control Center is the open source merchant dashboard for connecting processors and viewing payments, refunds and disputes across them. Use it to configure your processor connections and to check that migrated payments and refunds appear as expected. Confirm which reporting exports it offers before you plan finance reconciliation.
Self-hosting with Helm and Docker
Hyperswitch documents Helm charts for Kubernetes, with guides for local Minikube, AWS, GCP and Azure, and a Docker-based local setup. Choose the path that matches your cloud accounts or data centers, and note that the Router, Scheduler, PostgreSQL and Redis components all need to run in that environment. Ask your platform team which of these paths they will support.
Hosted sandbox for testing
The hosted sandbox lets your team exercise API calls, SDK flows and processor connections before any self-hosted environment exists. It is a testing route, not a production target, so plan the production hosting and vault model separately. Confirm the sandbox's current limits and data handling in the docs before loading any test cards.
How saved cards follow the move from Stripe to Hyperswitch
Saved card migration is a separate workstream from the payment integration, and it should be planned as one. Moving your Stripe calls to Hyperswitch changes how payments are routed, but it does not move the stored card data that customers rely on for recurring and one-click payments. In Hyperswitch, card data sits in the card vault, also called the locker. The vault is a separate Rust service in its own repository, and the architecture documentation describes it as built for PCI DSS requirements. Because it is a distinct component, you can deploy, secure and assess it on its own timeline while the orchestration layer is being cut over.
Hyperswitch documents three self-hosted vault models, and the one you choose determines who runs the card data environment. In the first, you self-host with the native Hyperswitch Vault, an in-house PCI model in which the merchant is fully responsible for PCI DSS certification and data handling. In the second, you self-host orchestration and send card data to an external PCI vault provider, with VGS and Tokenex named in the documentation as examples. In the third, you self-host orchestration but use the SaaS Hyperswitch Vault, so card storage is handled by the hosted vault service. Each model answers differently where encrypted card data lives, who manages the keys and who carries the attestation work.
The vault model drives your compliance scope, so decide it before you design the cutover. Under the in-house model, every system that stores, processes or transmits cardholder data is in scope, and your organization carries the PCI DSS certification work. Under an external or SaaS vault, the scope depends on the provider's own attestation and on your data flows, so you should confirm both in writing. Your integration services, network paths and any component that still touches raw card numbers remain your responsibility to document. DeployOpen can prepare the architecture, controls and evidence for an assessment, but the assessment report comes from an independent qualified assessor.
Before you commit to a model, confirm which exports Stripe provides for your account. The card data you can take out determines whether an in-house vault is practical and how much of your saved card base can move at all. Hyperswitch's PCI documentation notes that Stripe no longer allows raw card acceptance from its merchant dashboard, and that the PCI DSS Attestation of Compliance must be shared with Stripe support if raw card processing is needed. Ask Stripe support in writing which export formats, fields and network transaction data your account can receive, and whether raw card processing applies to your setup. The file format and required fields are covered on the card data import page in this group.
Sequence for a Stripe to Hyperswitch migration with parallel run and cutover
This sequence moves a Stripe integration onto Hyperswitch orchestration in controlled stages, so payments keep flowing while routing, saved cards and reconciliation are proven against live traffic. It ends with a documented cutover and a defined point at which Stripe paths are retired.
Inventory Stripe products, SDKs and back-office processes
Your team lists every Stripe surface in use: payment sheet, card and wallet elements, one-time and recurring payments, customers, refunds, saved cards, webhooks, Payment Links or Checkout, reporting exports and finance reconciliation jobs. Check each item against the Hyperswitch Stripe migration guide, which lists supported and unsupported features, and mark anything unsupported as a scope decision. The step is done when every item has an owner, a support status and a named replacement path, reviewed by payments, finance and engineering together.
Confirm version and deployment against the self-hosting docs
Deploy a non-production Hyperswitch stack by following the self-hosting documentation for your target environment, including the Router, Scheduler, PostgreSQL, Redis, card vault and Control Center components. Before choosing a release, read the release notes and compatibility matrix for each candidate version, and confirm any required services such as Superposition for the version you select. The step is done when the stack starts cleanly, the versions in use are recorded, and your team has written down the upgrade and rollback path.
Pilot a test flow on sandbox or non-production
Run a pilot on the hosted sandbox or your non-production deployment, connecting a test Stripe account and at least one other processor you plan to use. Exercise the flows that matter most: one-time and recurring payments, refunds, a card-on-file charge, webhook delivery and an error path. Record every mismatch between the Stripe behavior your application expects and what Hyperswitch returns. The step is done when each in-scope flow passes with recorded evidence and every unsupported feature has a decision attached.
Design routing rules and fallback behavior
Define which processor is primary for each merchant segment, currency, country and card type, and what happens when that processor is ineligible or declines. Hyperswitch documents several routing strategies, including rule-based, volume-based, auth-rate, multi-objective and default fallback routing, so choose the ones that match your risk and cost goals and document why. Agree the retry and fallback thresholds with payments operations. The step is done when the routing configuration is written down, peer reviewed and tested against the pilot cases.
Migrate saved cards and webhook consumers
Plan how stored cards and customer payment methods move, which depends on your vault model and the card import process, and confirm network transaction identifiers for merchant-initiated payments before any import. Point webhook consumers at Hyperswitch events and check that each downstream system handles the new event shapes. The step is done when a sample of saved cards has been charged successfully in the test environment and every webhook consumer has been verified against Hyperswitch events.
Run parallel traffic and reconcile both paths
Send a defined share of live traffic through Hyperswitch while Stripe continues to handle the rest, and compare authorization outcomes, amounts, refunds and settlement records between the two paths. Use Hyperswitch reconciliation and your finance team's existing reports to find gaps in fees, currencies, timing and status mapping. Review discrepancies daily and fix root causes before increasing volume. The step is done when reconciliation shows no unexplained differences across the agreed comparison period and the owners sign off.
Execute a staged cutover with a rollback plan
Move traffic to Hyperswitch in stages, starting with the lowest-risk segments and widening only after each stage passes its checks. Keep the Stripe path available and the rollback steps rehearsed until the final stage is stable. Monitor authorization rates, latency, error rates and webhook lag against the baseline from the parallel run. The step is done when all in-scope traffic runs on Hyperswitch, the rollback path has been tested, and the cutover record is complete.
Decommission Stripe paths after reconciliation
After the agreed reconciliation period closes with no open differences, remove Stripe API calls, webhook endpoints, keys and scheduled jobs that are no longer needed, and archive the reconciliation evidence for audit. Confirm with your compliance owner which records and attestations must be retained, and check whether any remaining Stripe use requires a separate review. The step is done when Stripe paths are removed from production, keys are revoked, and the decommissioning record is signed off.
What drives the cost and duration of the move
This table compares the factors that change how much work the Stripe move takes and what to settle before asking a partner for a quote. Read each row as a question to answer about your current integration. Stripe products and checkout patterns outside the documented quick migration, along with the PCI scope you choose, tend to shape the effort most.
| Driver | Effect on effort | What to ask in a quote |
|---|---|---|
| Stripe products beyond the supported list | Products outside the documented quick migration need custom mapping, testing and sometimes a different design, which adds the most effort. | Which Stripe products, APIs and SDK versions are in use, and which fall outside the supported list? |
| Custom checkout or Payment Links | Payment Links and Stripe Checkout are not supported in the documented quick migration, so hosted flows need a replacement design. | Whether a replacement hosted or custom checkout is in scope, and who builds and tests it. |
| Backend language and platform plugins | Node is documented as supported; Python, PHP and Ruby are available on request. WooCommerce is supported, while BigCommerce and Shopify are not. | Which backend language and plugin versions run the store, and how each is covered by the migration scope. |
| Saved card volume and vault model | Card volume drives import and reconciliation work. The vault model decides who carries PCI DSS obligations for stored data. | Number of stored cards, the vault model chosen, and whether the card data import is included in the scope. |
| Processors connected beyond Stripe | Each additional processor adds routing rules, credentials, connector testing and reconciliation mapping. | Which processors and payment methods must be live at cutover, and which can follow later. |
| Webhooks and reconciliation | The number of webhook event types your systems consume and how payouts, refunds and disputes are matched set the testing load. | Which Stripe webhook events your systems consume, and how payouts and refunds are reconciled today. |
| PCI scope decision | The in-house vault makes you fully responsible for PCI DSS certification and data handling. External or SaaS vault models change that scope. | Which vault model is chosen, who will assess it, and whether raw card data reaches your systems. |
| Identity and SSO for the Control Center | Control Center SSO uses OpenID Connect only, with no SAML and no JIT or SCIM provisioning. Users are invited first and roles are set in Hyperswitch. | Whether your identity provider supports OIDC, and how invited users and their roles will be managed. |
| Superposition dependency for upgrades | From v1.124.0, Superposition is a required configuration dependency and must be running before you upgrade to that version. | Whether Superposition will be deployed and operated in your environment, and how upgrades will be sequenced. |
What usually goes wrong in a Stripe to Hyperswitch move
Most problems in a Stripe to Hyperswitch move come from assumptions made before the build starts: which Stripe features carry over, which platforms are covered, and how saved cards and money movement are verified. Each card below names a failure point and the check that prevents it.
Assuming Payment Links and Checkout will port
Stripe Payment Links and Stripe Checkout are listed as not supported in the Hyperswitch Stripe migration guide, with support only as a feature request. Teams that planned to keep hosted payment pages will find those flows have no direct replacement. Before scoping, inventory every Stripe product in use and confirm each one against the current guide, then plan a rebuild with the Hyperswitch client SDKs for any hosted flow that matters.
Underestimating unsupported platforms
The migration guide supports WooCommerce but lists BigCommerce and Shopify as not supported. If your storefront runs on either platform, the Stripe plugin path does not apply and the checkout integration becomes custom work. Confirm your platform and plugin versions against the guide early, and treat any storefront change as a separate estimate with its own testing.
Moving saved cards without network transaction IDs
Merchant-initiated payments such as subscriptions and card-on-file renewals depend on network transaction IDs. A card import that omits them can leave recurring charges failing or downgraded after cutover. Before any export, confirm with the Hyperswitch import documentation which fields are required, check that your Stripe export includes the network transaction data, and test a sample of recurring customers in the sandbox.
Choosing an in-house vault without a PCI program
The self-hosted in-house PCI model places full responsibility for PCI DSS certification and card data handling on the merchant. Choosing it without a funded PCI program, documented controls and an assessor relationship moves risk onto your team that Stripe previously carried. Decide between the in-house vault, an external PCI vault provider and the SaaS vault only after your compliance lead confirms the assessment scope and ownership.
Skipping the parallel run
Cutting all traffic to Hyperswitch at once removes the fallback if authorization rates, webhooks or retries behave differently in your environment. A parallel run sends a defined share of traffic through each path so you can compare results before full cutover. Set the traffic split, success criteria and rollback trigger in writing before the first live transaction, and keep Stripe active until those criteria are met.
Weak reconciliation between processors
Running two processors without a shared reconciliation process leaves settlement, refund and dispute records split across systems that do not agree. Finance teams then close periods with unexplained differences. Map each Stripe report and payout to its Hyperswitch equivalent, define the matching keys, and run reconciliation on both paths during the parallel run, not after cutover.
Questions buyers ask before moving from Stripe to Hyperswitch
How much does it cost to move from Stripe to Hyperswitch?
Cost depends on scope, and no single figure applies to every team. The Hyperswitch software is licensed under Apache 2.0, so the platform itself carries no license fee. You pay for the infrastructure that runs it, the engineering to rebuild your payment calls and webhooks, the vault decision, testing, and the PCI DSS work your chosen model creates. Processors continue to charge their own fees, so compare those before cutover. Recurring costs include hosting, monitoring and staff time for upgrades, since Hyperswitch ships minor releases roughly monthly. DeployOpen issues a quote from a written scope. Ask for each line separately: one-time build, vault and PCI work, infrastructure, and any retainer for ongoing support.
How long does a Stripe to Hyperswitch migration take?
The timeline is set by scope, not by the Stripe API alone. The main drivers are which Stripe products and SDKs you use, how many backend services and frontends call them, and whether you run Payment Links or Stripe Checkout. Hyperswitch does not support those two, so any flow built on them needs a replacement design first. Other drivers include the number of saved cards to carry over, the vault model you choose, whether you need a parallel run with traffic split before cutover, and whether single sign-on for the Control Center is in scope. A Kubernetes platform that is not yet in place adds further work. Ask any provider for a phased plan in the written scope, with dependencies, test gates and the cutover window named.
What must our internal team provide for a Stripe to Hyperswitch move?
Your team supplies the access and decisions that an outside party cannot assume. Expect to provide administrator access to the Stripe account and its webhook endpoints, owners for each service that calls Stripe, and a Kubernetes platform or cloud account where the stack will run. You also need a named decision-maker for the vault model, a PCI DSS owner who can speak for scope, test merchant accounts for each processor, and a staffed change window for cutover and rollback. Finance or operations should confirm settlement, refund and dispute reporting, because reconciliation moves with the payments. Agree these responsibilities in writing so that delays from missing access show up in the plan.
Can our own engineers migrate from Stripe to Hyperswitch without a partner?
Yes, a capable internal team can do it without a partner, if it already has Kubernetes operations, payments engineering and PCI DSS experience. Hyperswitch documents self-hosting with Helm charts on Kubernetes, a Docker-based local setup and a Stripe migration guide that lists the supported products. Teams usually struggle outside the main path. The Router and Scheduler services depend on PostgreSQL with a master and replica setup and on Redis. The v1.124.0 release made Superposition a required configuration dependency, so check that before upgrading. Vault and PCI decisions also carry audit consequences. A partner can take any of these as fixed-scope work while your engineers keep ownership of the business logic. List your skill gaps against the workstreams in the scope to decide.
Does Hyperswitch support all Stripe products and SDKs?
No. Coverage is limited to what the Hyperswitch Stripe migration guide lists. Supported items include Stripe UI elements such as the payment sheet, card element and wallet element, one-time and recurring payments, customers, refunds, cards, wallets, bank transfers and BNPL. Stripe Payment Links and Stripe Checkout are not supported and exist only as a feature request, so flows built on them need a replacement design. On the backend, Node is supported, and Python, PHP and Ruby are available on request. For storefronts, WooCommerce is supported, while BigCommerce and Shopify are not. Products outside that list need confirmation before scoping. Check each Stripe product you use against the guide and get the answer in writing.
What happens to our saved cards when we move off Stripe?
Saved cards do not move automatically when you change orchestration. Moving them is a separate workstream. Hyperswitch documents a card data import that depends on an Attestation of Compliance exchange, a PGP-encrypted CSV sent over SFTP, and required fields, including network transaction IDs for merchant-initiated payments, which recurring charges rely on. Hyperswitch's PCI documentation also notes that Stripe no longer allows raw card acceptance from its merchant dashboard, and that your PCI DSS Attestation of Compliance must be shared with Stripe support if raw card processing is needed. Start that conversation with Stripe early, because it can determine whether card data can leave Stripe at all. Plan the fallback for customers whose cards cannot be carried over, for example by asking them to re-enter details at their next payment.
Who carries PCI DSS obligations when we self-host Hyperswitch?
Your organization carries the PCI DSS obligations for the environment it operates. In the self-hosted, in-house PCI model that Hyperswitch documents, the merchant is fully responsible for PCI DSS certification and data handling. Your team then owns the card vault, its key management, the network controls around it and the evidence an assessor will request. If you choose an external PCI vault provider such as VGS or Tokenex, or the SaaS Hyperswitch Vault, the scope changes, and the split of responsibilities must be documented with that provider. Confirm the scope with a qualified security assessor before design. DeployOpen prepares systems, controls and evidence for assessment, but it does not issue attestations or certifications. An independent assessor does that.
How DeployOpen works on this
DeployOpen plans and implements self-hosted Hyperswitch inside your own infrastructure, so the Stripe migration runs against your environment and your processors. Work starts from a written, fixed scope that states which Stripe products, SDKs and saved-card paths are covered and which are excluded.
How we scope
- Inventory which Stripe products, SDKs and backends your integration uses, checked against the documented supported list.
- Record unsupported items such as Payment Links, Stripe Checkout and Shopify, and agree how each will be handled.
- Confirm the saved-card path with your PCI scope, vault model and the card data import requirements before build begins.
How we build
- Deploy Hyperswitch with Helm on Kubernetes in your cloud account or data center, with Router, Scheduler, PostgreSQL and Redis configured.
- Configure Stripe as a connector, set up routing rules, and test payments, refunds and webhooks in a sandbox before any live traffic.
- Migrate client-side integration to the Hyperswitch SDK for the platforms you use, and test each payment method in scope.
How we hand over
- Deliver runbooks for deployment, connector configuration, routing changes, upgrades and rollback of the cutover.
- Document the vault model chosen, including the PCI DSS responsibilities that stay with your organization.
- Walk your engineers through the running system and the test evidence, then transfer administration to your team.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan Hyperswitch upgrades against the release compatibility matrix for Control Center and client SDK versions.
- Ask any provider quoting this work to confirm in writing what the retainer covers, response expectations and who performs upgrades.
