How a saved card migration to Hyperswitch starts
The documented Hyperswitch card import exists, but it works only if your current processor cooperates on the export. Under the documented process, the processor encrypts the export with a Hyperswitch public PGP key, sends the CSV over SFTP, and Hyperswitch returns updated customer and payment method reference IDs after import. The import is one step in a larger move, so the first question for your team is whether your processor will produce that export, in that format, and on what terms. Get that answer in writing before you plan anything that depends on it, including customer communications and cutover dates.
Start by inventorying what you hold. The required card fields are card number, expiry month, expiry year and payment_instrument_id, which is the processor token that stands in for the card. Merchant-initiated payments also need original_network_transaction_id for connector-agnostic transactions, so confirm with your processor whether that value can be exported for each stored credential. Ask for a sample file and check it against the documented rules: UTF-8 encoding, comma delimiters, single newline characters, empty fields left empty and no multi-line values. Billing details are mandatory when AVS checks are enabled, so confirm those fields exist before you commit to a plan.
Non-card methods follow a separate path. For SEPA, ACH, PayPal, Klarna and other non-card payment methods, the Hyperswitch docs direct merchants to contact support, and no self-service import is documented. Treat those tokens as their own workstream with a named owner, a list of questions for Hyperswitch and a list of questions for your processor. A successful card import does not confirm that bank debit mandates or wallet agreements have moved, so do not let them drop out of the scope because the card import looks complete.
Effort depends on four drivers that you can examine early. The first is the processor's export, including its format, turnaround and any charge it applies to the work. The second is the token types you hold, since cards, network transaction IDs and non-card methods each involve different steps. The third is the vault model you choose. The self-hosted in-house PCI model leaves the merchant fully responsible for PCI DSS certification and data handling, while the external PCI vault and SaaS vault options move part of that work to another party. The fourth is the parallel run, in which both processors operate while you verify tokens and charges. This page does not state a duration because it depends on the scope agreed for your environment.
What maps cleanly from a processor to Hyperswitch and what does not
This table compares the processor capabilities you may hold today with their documented Hyperswitch equivalent and the migration notes for each. Read the card rows as the documented import path, and read the non-card and network transaction ID rows as items to confirm before you plan the import. The main takeaway is that card tokens and customer records have a defined import route, while everything beyond cards needs a conversation with Hyperswitch support first.
| Source capability | Hyperswitch equivalent | Migration notes |
|---|---|---|
| Saved card tokens (PSP token) | payment_instrument_id mapped to a Hyperswitch payment method reference after import | Included in the documented CSV import. Your processor must export the token as payment_instrument_id alongside card number and expiry fields. |
| Customer records | Customer and payment method reference IDs returned by Hyperswitch | Hyperswitch returns updated customer and payment method reference IDs after import. Store these in your system before you switch traffic, because your order and subscription records will need them. |
| Card-on-file recurring payments | Saved card used for merchant-initiated transactions through Hyperswitch | Recurring charges depend on the saved card import and on network transaction IDs where connector-agnostic merchant-initiated transactions are used. Test one recurring cycle in a sandbox before cutover. |
| Non-card methods (SEPA, ACH, PayPal, Klarna and others) | Not covered by a documented self-service import | Hyperswitch directs these to its support team rather than a self-service import. Ask support in writing whether each method can move, and what they need from you, before you plan the scope. |
| Network transaction IDs | original_network_transaction_id field in the card import CSV | Required only for connector-agnostic merchant-initiated transactions. If you only charge through one processor, confirm with that processor whether you need to export these values at all. |
| Card fields (number, expiry month, expiry year) | Required card columns in the import CSV | Export all three fields in the format the import expects. Missing or malformed values cause rejected rows, so run a small test file first. |
| Billing details | Mandatory when AVS checks are enabled | If your current setup runs address verification, export billing details for every card row. Otherwise, confirm with Hyperswitch whether you can leave them empty. |
| File format and transfer | UTF-8 CSV with commas and single newlines, PGP-encrypted and sent over SFTP | Remove multi-line values and check encoding before encryption. Your processor encrypts the file with the Hyperswitch public PGP key, so confirm who holds the key pair and the SFTP details. |
How the card import file must be built and encrypted
The import file is the only artifact that carries saved card data from your current processor into Hyperswitch, so its structure and encryption need to be settled before any export is requested. The documented flow has three steps. Your current processor encrypts the export with a Hyperswitch public PGP key, sends the CSV over SFTP, and Hyperswitch returns updated customer and payment method reference IDs after the import. Your team owns the handoff at each step. Confirm with the processor who will generate the export, who holds the SFTP credentials, and where the returned reference IDs will be stored so they can be matched to your customer records.
The required fields are card number, expiry month, expiry year, and payment_instrument_id, which is the PSP token the processor issued for each saved card. The original_network_transaction_id field is conditionally required. The documentation ties it to connector-agnostic merchant-initiated transactions, so review your recurring and stored-credential flows and decide whether any fall in that category before the export is scoped. Ask the processor which identifiers it can supply per card. A missing token or network transaction ID is a likely cause of rejected rows, and it is far easier to find that gap in the source system than after the file has been encrypted and sent.
The format rules are strict. The file must be UTF-8, delimited by commas, and separated into records by single newline characters. Empty fields stay empty rather than receiving placeholder text such as NULL or N/A. Multi-line values are not allowed, so any address field that contains a line break in the source system needs to be flattened first. Export tools often add extra header rows, trailing delimiters, or carriage return and line feed endings, so inspect the raw output in a text editor or with a byte-level tool. Billing details are mandatory when AVS checks are enabled on your account, so confirm that setting before deciding which billing columns the export must include.
Before a test file is produced, confirm each rule in this section against the current Hyperswitch data migration documentation, since field names, conditions and format requirements can change between releases. Then run a small test with cards that the processor and Hyperswitch sandbox both accept, not production card data, through the agreed encryption and SFTP path. Check the returned reference IDs, review every rejected row, and record the reason for each rejection. Treat that test as the basis for the production export specification, and do not start a full-volume export until the test file imports cleanly and the reference IDs reconcile with the source records.
Documented import paths and the tools around them
Hyperswitch documents one self-service route for saved cards, a PGP-encrypted CSV sent over SFTP, along with the guidance and tools that prepare, load and check that data. Each path has a different owner and different inputs, so confirm which one fits your processor and payment methods before you plan the work.
PGP-encrypted CSV over SFTP
This is the exchange the documented import process uses for saved cards. Your current processor encrypts the export with the Hyperswitch public PGP key, then sends the CSV over SFTP. After import, Hyperswitch returns updated customer and payment method reference IDs, which you must map back to your own customer records. Confirm with your processor that it can produce this encrypted export, and agree in writing who manages the SFTP endpoint and the key handling.
Hyperswitch data migration documentation
The data migration guide sets the field list and file rules you must meet before any file is sent. Card number, expiry month, expiry year and payment_instrument_id (the processor token) are required. original_network_transaction_id is needed only for connector-agnostic merchant-initiated transactions. The file must be UTF-8, comma-delimited, use single newline characters and contain no multi-line values. Billing details are mandatory when AVS checks are enabled. Check your data against these rules before the export runs.
Control Center for processors and payments
The Control Center is the open source dashboard, licensed under Apache 2.0, where you connect processors and review payments, refunds and disputes across them. Use it to confirm that destination processors are configured before migrated cards are used, and to check migrated payments against the source system. Its single sign-on supports OpenID Connect only, with no SAML, no JIT or SCIM provisioning, and users must be invited first. Plan your access model around those limits.
Support for non-card payment methods
The documented import covers cards only. For SEPA, ACH, PayPal, Klarna and other non-card methods, Hyperswitch directs merchants to contact support instead of documenting a self-service import. Ask support early what it will accept for each method, in what format, and on what timeline, and get the answers in writing. Treat any non-card customer data as an open item until that answer arrives, since it may need a separate project.
Vault model and PCI DSS scope
Migrated card data lands in the card vault of your deployment, and the vault model decides who carries PCI DSS obligations. Hyperswitch documents an in-house PCI model in which the merchant is fully responsible for PCI DSS certification and data handling, plus models that use an external PCI vault provider or the SaaS vault. Choose the model before the import, because it sets your assessment scope. Compliance is validated through a Report on Compliance or a Self-Assessment Questionnaire with an Attestation of Compliance, not a certificate.
What changes when you self-host the card vault
The vault model you pick decides where card numbers sit before the first row is imported, so settle it before any export leaves your current processor. The Hyperswitch docs describe three self-hosted models. In the first, you run the native Hyperswitch Vault, which the architecture docs describe as a separate Rust card vault service built for PCI DSS requirements. In the second, you self-host the orchestration layer but send card data to an external PCI vault provider such as VGS or Tokenex. In the third, you self-host orchestration and use the SaaS Hyperswitch Vault. Each model puts the card number in a different system, and each one changes what your import file touches on the way in.
The in-house model carries the most weight. The Hyperswitch docs state that under this model the merchant is fully responsible for PCI DSS certification and data handling. In practice, the card vault service, the database and cache services in the same deployment, the hosts that run them and every path the CSV travels through fall inside your environment to operate and document. Your team also owns the private key that matches the Hyperswitch public PGP key, along with the SFTP location that receives the encrypted file. Ask your engineering lead to list every system that will hold a decrypted card number during import, including temporary files and logs, because your assessor will ask for that list first.
Who assesses the environment changes with the model. PCI DSS is assessed either through a Report on Compliance completed by a Qualified Security Assessor or through a Self-Assessment Questionnaire, and each produces an Attestation of Compliance. The payment brands, not the PCI SSC, decide which entities must validate. Under the in-house model, your assessor reviews the vault service, its hosting and your key handling directly. Under either outsourced model, part of the cardholder data handling moves to a vault provider, so your assessor will need that provider's current attestation and a written split of responsibilities before the scope is agreed. The PCI SSC lists PCI DSS v4.0.1 as the only active version, so ask your assessor which version the scope will be measured against.
The import target follows from the vault decision and is set before the file is sent. Each row carries a card number, expiry month, expiry year and payment_instrument_id, and Hyperswitch returns updated customer and payment method reference IDs once the import completes. Those reference IDs are how your payment flows call stored cards afterwards, so the target vault must be configured and confirmed in advance. Run a small batch in a non-production environment first, check that the returned reference IDs resolve to the vault you selected, and confirm that the same configuration will be applied to production.
Before you import live cards, confirm the vault choice with your assessor in writing. Ask for a scope statement that names every system holding card data during import, a data flow diagram, and the custody arrangement for the PGP private key. Ask your Hyperswitch deployment team to confirm which vault the target configuration points to in each environment. If the assessor requires a different model after import, stored card data would have to be moved again, so settling the model first avoids moving it twice.
Sequence for importing cards, running in parallel and cutting over
This sequence moves saved card tokens from your current processor into Hyperswitch without interrupting charges. Each step closes with a record that the next step depends on, so the cutover happens only after the import has been reconciled and tested.
Inventory saved card tokens and their types
Your team lists every stored credential in the current token store and separates card records from non-card methods such as SEPA, ACH, PayPal and Klarna. The documented self-service import covers cards, so non-card methods need a support request to Hyperswitch. For each card record, identify whether it is used for merchant-initiated transactions, because those need an original network transaction ID. Done means you hold a signed inventory with counts per payment type and a field-by-field map to the required import fields.
Agree export and SFTP terms with the processor
Your team and the current processor confirm in writing who produces the export, which fields it contains, how the file is encrypted with the Hyperswitch public PGP key, and how it is delivered over SFTP. The agreement should name who owns the SFTP account, who can retrieve or delete files, and how failed transfers are retried. Ask the processor to confirm that the export will match the documented field list. Done means a signed exchange agreement exists and both parties have named a technical contact.
Set up PGP keys and a test file
Your team generates or receives the PGP keys for the exchange, stores the private key in your approved secrets system, and confirms the processor can encrypt with the Hyperswitch public key. Build a small test CSV that follows the format rules: UTF-8, comma-delimited, one newline per record, empty fields left empty, no multi-line values, and billing details present whenever AVS checks are enabled. Encrypt it, transfer it over SFTP, and decrypt it on the receiving side. Done means the round trip succeeds and the file's byte-level format has been checked.
Import into a non-production Hyperswitch environment
Deploy Hyperswitch in a non-production environment using the Docker setup, a Kubernetes deployment with the Helm charts, or the hosted sandbox, depending on what your team will run in production. Before importing, record which vault model you intend to use, because the in-house PCI model makes your organization responsible for PCI DSS certification and data handling. Import the test file, then capture the customer and payment method reference IDs that Hyperswitch returns. Done means the import log and reference ID map are saved and any rejected rows are explained.
Reconcile reference IDs and card counts
Compare the record counts in the source export against the records Hyperswitch accepted, and review every rejected or altered row. Match the returned customer and payment method reference IDs back to the original tokens so each saved card can be traced from the old store to the new one. For merchant-initiated records, run test transactions in the non-production environment to confirm the network transaction data works. Done means every count difference and rejected row has a recorded explanation and a signed reconciliation report exists.
Run a parallel period with new charges on Hyperswitch
Route new payments through Hyperswitch while the current processor stays available to serve stored tokens that have not yet moved. Define the routing rules, fallback behavior and the monitoring your team will watch during this period, including authorization outcomes and reconciliation differences between the two paths. Keep an operations runbook that states who can change routing and how to revert it. Done means new charges are flowing through Hyperswitch under documented rules and the monitoring reports are reviewed on an agreed schedule.
Cut over stored token charges to Hyperswitch
After the reconciliation report is accepted, move charges that use stored tokens to the Hyperswitch references. Freeze the source token store for final changes, import any delta file needed for records created during the parallel run, and repeat the reconciliation on that delta. Confirm the rollback path, including who can restore routing to the old processor and within what conditions. Done means stored-token charges succeed on Hyperswitch, the final reconciliation is signed, and the cutover is recorded.
Decommission the old token store after retention and audit
Retire the old token store only after the retention period and audit obligations have been agreed with your assessor, legal team and the processor. Before deletion, preserve the reconciliation records, import logs and exchange agreement as evidence, then revoke SFTP access and retire the PGP keys used for the exchange. Update your PCI DSS scope documentation to reflect the new card data environment. Done means the retention decision is written down, the old store is removed or archived as agreed, and the evidence is filed.
What drives the effort and cost of a saved card import
This table lists the drivers that change the effort and cost of importing saved cards into Hyperswitch, with whether each is one-time or recurring and what to request in a written quote. Read it before you ask for a fixed-scope proposal, because the vault model and deployment target shape much of the work. The main takeaway: the card file is only one input, and PCI DSS scope and the parallel run often carry the longer-term cost.
| Driver | Why it changes effort or cost | One-time or recurring | Ask for in a written quote |
|---|---|---|---|
| Number and type of saved cards | Volume, card brands and expiry data quality set the validation, rejection handling and rerun work. | One-time | Validation approach, rejection report format, and how reruns of failed records are scoped. |
| Processor export format and SFTP | If the current processor cannot produce a PGP-encrypted CSV and deliver it over SFTP, a transformation or delivery step must be built. | One-time | Who produces the export, who builds any transform, and any processor fees for export support. |
| Network transaction IDs | Required only for connector-agnostic merchant-initiated transactions, so missing IDs affect which recurring payments can move. | One-time analysis, then recurring if flows stay split | Count of cards without IDs, the fallback for them, and how merchant-initiated flows are tested. |
| Non-card payment methods | SEPA, ACH, PayPal, Klarna and similar methods are directed to support tickets rather than a self-service import. | One-time per method | The written support path for each method, expected response steps, and who opens the ticket. |
| Vault model and PCI DSS scope | An in-house PCI vault makes the merchant fully responsible for PCI DSS, while an external vault changes data flow and the scope boundary. | Recurring (assessment and controls) | Chosen vault model, scope diagram, evidence to be prepared, and who issues the attestation. |
| AVS and billing data quality | Billing details are mandatory when AVS checks are enabled, so incomplete addresses cause failed records. | One-time cleanup | Field mapping for billing details, required fields when AVS is on, and the rejection log format. |
| Hyperswitch deployment target | Helm charts on Kubernetes, cloud or local environments, and PostgreSQL and Redis sizing change build and run work. | Recurring (hosting and upgrades) | Target environment, high availability design, backup approach, and upgrade support for each minor release. |
| Parallel run length | Both processors stay active during reconciliation, so processor and infrastructure costs continue until exit criteria are met. | Recurring during the run | Written exit criteria, reconciliation scope, and the duration the quote assumes. |
What usually goes wrong with card imports and how to prevent it
Most card import failures look successful at first: cards appear in the dashboard, but charges fail, customers cannot be matched, or the compliance scope turns out to be wrong. The prevention steps below share one habit: run a test import with a labeled sample, then check the results against the source processor and the target configuration before the full run.
Malformed CSV files
The import file must be UTF-8, delimited by commas with single newline characters, with empty fields left empty and no multi-line values. Encoding errors, a semicolon delimiter, or a notes field containing a line break can shift columns or cause the file to fail. Prevention: run a test import with rows that include accented names, blank optional fields and a multi-line address field, then confirm each row maps to the expected customer and payment method in the Control Center.
Missing expiry or PSP token
Card number, expiry month, expiry year and payment_instrument_id, the PSP token, are the required card fields. A row missing any of them cannot produce a usable saved card, and a token copied from the wrong column can look valid until a charge fails. Prevention: count rows with blank required fields before sending the file, then in the test import compare a sample of imported cards against the source processor records to confirm the tokens match.
Missing network transaction IDs
original_network_transaction_id is required only for connector-agnostic merchant-initiated transactions, such as recurring charges that run without the cardholder present. If it is absent for those cards, the charges may be declined, especially when routing sends them to a different processor than the original. Prevention: list which saved cards back recurring or stored-credential flows, confirm each has an network transaction ID, and run a test merchant-initiated charge on a sample card after import.
Billing data missing under AVS
Billing details are mandatory when address verification (AVS) checks are enabled. If billing addresses sat in a separate table at your current processor and the CSV omits them, the imported cards may fail verification at authorization. Prevention: confirm the AVS setting for each target connector, map billing address columns explicitly, and test one card per address format, with and without a postal code, before the full import.
Reference IDs not stored back
After import, Hyperswitch returns updated customer and payment method reference IDs. If your team does not write these back to its own customer records, later payments and refunds cannot be linked to the saved card, and the old processor IDs remain the only link. Prevention: define the ID mapping table before import, store both the old and new IDs against each customer, and confirm in the test import that a payment using a returned ID succeeds and appears under the correct customer.
Vault model and PCI scope
Token scope depends on the vault model you choose. 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. The Control Center manages processors and payments but does not by itself meet PCI DSS obligations. Prevention: document which system stores card numbers and which tokens leave the vault, then ask your assessor to confirm scope under PCI DSS v4.0.1, the only active version, before importing live cards.
Questions buyers ask before importing saved cards
How much does importing saved cards into Hyperswitch cost?
DeployOpen does not publish a price list, and a quote follows from the written scope. The main cost components are DeployOpen's fixed-scope work (planning, field mapping, import runs, reconciliation and cutover support), which is one-time, and your own effort with the current processor, which is also mostly one-time. Recurring costs sit elsewhere: the cloud or data center hosting the self-hosted stack, and the annual PCI DSS assessment work that your vault model requires. Costs rise with the number of payment methods, the state of the exported data, the number of processor and vault parties involved, and whether you need test cycles beyond the first. Ask for a quote that separates one-time implementation, hosting estimates you own, and any retainer for ongoing support.
How long does a Hyperswitch saved card import take?
The duration depends on the scope agreed in writing, and no fixed timeline applies to every import. The work moves through recognizable phases: discovery of your data and processor export capability, agreement on the CSV layout and PGP key exchange, a test import with sample data, reconciliation of imported records against the source, and a controlled cutover followed by verification of the updated customer and payment method reference IDs. The largest variables are how quickly your processor can produce an export in the required format, how clean the stored data is, and how many vault models or payment methods are in play. Ask the partner to show each phase with its dependencies and the party responsible for each one.
What must our team supply for a saved card import?
Your team must supply four things that no implementation partner can produce alone. First, processor cooperation: your current processor must encrypt the export with the Hyperswitch public PGP key and send the CSV over SFTP. Second, PGP key handling: someone must own the private key lifecycle, including generation, secure storage, access control and rotation. Third, a named PCI DSS owner who decides scope, signs off on the vault model and works with your assessor. Fourth, test data and a test environment that mirrors production fields. You should also confirm billing details if address verification checks are enabled, and whether original network transaction IDs are needed for connector-agnostic merchant-initiated transactions.
Can our internal team run a saved card import alone?
An internal team can run the import alone if it has engineers who have deployed Hyperswitch, a data owner who understands the export, and a processor willing to produce the required file. The documented process is a file exchange plus field mapping, so the risk lies in the details: encryption, format rules and reconciliation. Teams without recent PCI DSS work, or without someone who can manage the PGP key lifecycle, often choose a fixed-scope partner for the import and keep the operation in-house. DeployOpen's role can cover planning, implementation, integration, hardening, documentation and support inside your infrastructure. Compare both options against the same written scope, and agree who owns each step before work starts.
Does importing saved cards change our PCI DSS scope?
Yes, the import can change your PCI DSS scope, and the change depends on the vault model. In the self-hosted model with the native Hyperswitch Vault, the Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling. With an external PCI vault provider, scope depends on the provider's responsibilities and your integration, so get the split in writing and confirm it against the provider's own assessment. With the SaaS Hyperswitch Vault, confirm in writing which controls Juspay operates and which fall to you. The PCI SSC does not enforce compliance. Payment brands and acquirers decide who must validate, and validation uses a Report on Compliance by a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance. Certificates are not recognized as validation.
Which PCI DSS version should a card vault project target?
PCI DSS v4.0.1 is the only active version, because v4.0 retired on 31 December 2024. Version 4.0.1 was published on 11 June 2024 as a limited revision with no added or deleted requirements. Most of the 64 new requirements from v4.0 were future-dated and became effective on 31 March 2025, so any assessment now tests them. The PCI SSC ran a request for comments on v4.0.1 from 3 June to 20 July 2026 to begin the next iteration, and as of October 2026 it had announced no release date for a new version. Plan the vault design against v4.0.1, and ask your assessor how they will treat any future revision during your project.
Can I import SEPA, ACH or PayPal payment methods too?
Do not assume the card import process covers these methods. For SEPA, ACH, PayPal, Klarna and other non-card payment methods, the Hyperswitch docs direct merchants to contact Hyperswitch support rather than documenting a self-service import. Before scoping, ask support whether an import path exists for each method, which fields and formats it requires, who performs the import, whether reference IDs come back in the same way, and what timeline and prerequisites apply. Record the answers in your written scope. If support confirms an import path, DeployOpen can plan and implement the surrounding work, including processor coordination, reconciliation and documentation, within the inside-your-infrastructure model.
What CSV format errors stop a Hyperswitch card import?
The most common blockers are formatting problems rather than card data problems. The documented import CSV must be UTF-8 encoded, delimited by commas, and use single newline characters between records. Empty fields must stay empty, and multi-line values are not allowed, so addresses or notes containing line breaks will fail. Required card fields are card number, expiry month, expiry year and payment_instrument_id, which is the PSP token. Billing details are mandatory when address verification checks are enabled, and original network transaction IDs are required for connector-agnostic merchant-initiated transactions. Validate the file against these rules in a test run, and keep the failing rows for your processor to correct before the production file is produced.
How DeployOpen scopes and delivers a Hyperswitch card import
DeployOpen plans and builds a card import into Hyperswitch around the documented process, in which your current processor encrypts the export with Hyperswitch's public PGP key and delivers it over SFTP. The scope is agreed in writing before any card data moves, and the vault model you choose determines how much PCI DSS work follows. Hyperswitch returns updated reference IDs after import, and the team maps those back to your systems.
How we scope
- Written scope lists the source processor, saved card volume, vault model and target environment before any data is exported.
- We confirm which records need a network transaction ID for merchant-initiated payments, required only for connector-agnostic cases.
- Non-card methods such as SEPA, ACH and PayPal are scoped separately, since Hyperswitch directs those to its support team.
How we build
- We set up the Hyperswitch deployment on infrastructure you control, using the self-hosting guides Hyperswitch documents.
- We prepare the CSV in the documented format: UTF-8, comma-delimited, single newlines, empty fields left empty, no multi-line values.
- We test PGP encryption and SFTP transfer with sample files before any live card data moves.
How we hand over
- Deliverables include the configured deployment, import runbook, field mapping and a record of reference IDs returned by Hyperswitch.
- We document the vault model chosen, including who carries PCI DSS obligations for stored card data under that model.
- DeployOpen prepares evidence for your assessor, who issues the Report on Compliance or Attestation of Compliance.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, separate from the fixed-scope import.
- Hyperswitch releases roughly monthly, so upgrade plans should track Control Center and SDK compatibility matrices.
- Changes to the vault model, processors or PCI DSS version are reviewed before they touch the import pipeline.
