How do you answer GDPR erasure requests for customer data in a self-hosted Hyperswitch?
Hyperswitch supports the right to erasure through permanent deletion of personal data on request, and it publishes a Deletion API that merchants can use to delete customer personal data. That API is a tool, not the obligation itself. In a self-hosted deployment you run the Router, the Scheduler, PostgreSQL, Redis, the card vault, Control Center and every log pipeline yourself, so under Article 17 you, as the controller, carry the duty to erase personal data from every copy, backup, log and downstream system where it sits. Your erasure process has to answer one question for each request: where else does this person's data exist, and has it been removed or lawfully retained there?
The platform helps with the mechanical part of Article 17. Its Deletion API can act on the primary records for a given customer, which supports the erasure grounds in Article 17(1), such as data no longer necessary, withdrawn consent or a successful objection. It cannot decide whether a request is valid, whether one of the six grounds applies, or whether an exception in Article 17(3) lets you keep certain data, for example to meet a legal obligation to retain payment records or to establish or defend legal claims. Those are legal judgments for your data protection officer and counsel. Record the ground or exception relied on for each request, along with the dates of receipt and response, because erasure must happen without undue delay.
Before you rely on the Deletion API, confirm its reach in your build. Inventory which PostgreSQL tables, Redis entries, scheduler jobs and vault records hold customer identifiers, and confirm whether the API removes those records or only marks them. Card data sits in the separate card vault, so check whether a deletion request reaches the vault token mapping and what happens to tokens already shared with processors. Then test with a synthetic customer across each store. Backups need a separate answer. The EDPB's 2025 coordinated enforcement action on the right to erasure, which covered 32 data protection authorities and 764 controllers and was announced on 18 February 2026, listed deletion of personal data in backups among its seven recurring challenges. Set a documented rule that re-applies pending erasures when a backup is restored.
Erasure also reaches beyond your own stack. Under Article 19, you must inform each recipient of the personal data about the erasure, unless this proves impossible or involves disproportionate effort. Your register of connected processors, analytics tools, fraud engines and reporting exports therefore has to be current. Anonymisation does not replace deletion for this purpose, since the same EDPB action found ineffective anonymisation used in place of deletion. Decide with your legal team which fraud, dispute or tax records you retain under an Article 17(3) exception, and record the retention period and legal basis for each category.
DeployOpen can plan the erasure workflow, configure and test the Deletion API against your store inventory, script verification queries, and prepare the records that show what was done for each request. DeployOpen does not issue certifications, attestations or legal conclusions. Supervisory authorities judge whether your process meets Article 17, and fines for infringements of data subject rights can reach EUR 20 million or 4% of worldwide annual turnover, whichever is higher (Article 83). Ask for a written scope that names each store, the test cases, the recipients to notify and the evidence you will keep.
Which GDPR erasure and retention requirements map to which Hyperswitch capabilities
This table maps each GDPR erasure and retention requirement in scope to the Hyperswitch capability that supports it and to the settings the operator must define. Read each row left to right: the requirement sets the question, the capability shows what the platform provides, and the configuration column lists what your team still owns. The main takeaway is that the Deletion API covers only part of the work, and triage, retention, backups, recipient notification and access control remain with the operator. The exact Deletion API scope must be confirmed against the documentation for the release you run.
| Requirement | Hyperswitch capability | Configuration the operator must define |
|---|---|---|
| Article 17(1): grounds for erasure without undue delay | Deletion API for permanent deletion of customer personal data on request, as described on Hyperswitch's GDPR page. Confirm which tables and fields the API covers in your release. | Erasure triage: a documented process that tests each request against the six Article 17(1) grounds, logs the decision and records the date of receipt and completion. |
| Article 17(3): exceptions to erasure | The Deletion API does not decide whether an exception applies. Records kept for a legal obligation or legal claims must be identified before any deletion runs. | Retention schedule: for each payment and customer record type, the legal basis, the retention period and the owner who approves exceptions. Confirm periods with your legal and tax advisers. |
| Article 19: notification of erasure to recipients | The supplied material does not describe an erasure notification workflow. Confirm whether the release emits erasure events or exports that downstream systems can consume. | Recipient notification: a register of processors, connectors, analytics tools and banks that received the data, with a defined method and owner for telling each one about an erasure. |
| Article 32: security of processing | Self-hosting with Helm charts on Kubernetes lets the operator set network, identity and encryption controls in its own environment. Hyperswitch documents these as deployment choices, not guarantees. | Access control: named roles for who can invoke deletion, read or change vault data, administer PostgreSQL and Redis, and export records, with logs kept for each deletion action. |
| Card vault separation | Card data is held in the separate card vault (locker) service, so erasure of card records follows vault handling rather than the core application database alone. | Vault scope decision: whether a customer erasure request also triggers deletion of stored card tokens or PAN in the vault, and how that aligns with your PCI DSS scope and vault deployment model. |
| Backups, replicas and caches | The operator runs the PostgreSQL primary and replica and the Redis cache and scheduler queue, so copies in these stores and in backups are operator-controlled. The EDPB's 2025 enforcement action listed deletion from backups as a recurring challenge. | Backup purge: how erased records leave backups and replicas, the time window in which they are removed, and a restore procedure that re-applies erasures after a recovery so deleted data does not return. |
| Dashboards, exports and logs | Control Center views, reconciliation exports and application logs can hold payment and customer data. Confirm which of these the Deletion API reaches. | Retention schedule per data store: how long Control Center exports, reconciliation files, application logs and monitoring data are kept and how each is purged on request. |
| Article 44: transfers to third countries | Not a Hyperswitch feature. Transfer exposure depends on where the operator hosts each component and who can view data during remote support, which is covered in the transfers section of this page. | Transfer assessment: confirm the hosting region of every component, the locations of support access and any third-country processors before setting erasure timelines for those stores. |
What the Hyperswitch Deletion API covers and what it leaves to you
Hyperswitch's GDPR page says it supports the right to erasure through permanent deletion of personal data on request, and it publishes a Deletion API that merchants can use to delete customer personal data. In a self-hosted deployment, that API is a tool inside your own stack. You run it, you decide when it is called, and you answer for what it leaves behind. Before you commit to an erasure timeline with a data subject, establish exactly which stores the API reaches in your environment and which ones you must clean up yourself.
Start by mapping each request to the records that exist in your deployment. Payment records hold transaction history, amounts and statuses in the core application database. Customer objects link a person to their payments. Saved payment methods are the stored instruments a returning customer can reuse. Connector references tie a customer to an account or token at each payment processor you have connected. Card data itself sits in the card vault, which is a separate service, so you need to know whether a deletion call reaches the vault or whether vault records need a separate step. Build a table with one row per record class, its location in your deployment, what the API removes, what you remove by other means and what you keep.
The operator must confirm in the Hyperswitch documentation which data classes the Deletion API removes and which it does not. Do not assume that a customer deletion reaches every store, and check the documentation for the exact release you run, because Hyperswitch ships minor releases roughly monthly and behavior can change between them. Test the workflow in a non-production environment with synthetic customers. After each test, query every store that holds personal data, including the Redis cache and scheduler queue, application logs, reporting copies and the Control Center, and record the results. Keep the test evidence, since it shows how you verified the scope.
Some data will sit outside the API's reach by design. Processors you connect to hold their own copies of payment records under their own legal obligations, so you need to instruct them under your contracts and check the recipient notification duty in Article 19 of the GDPR against your own processing. Backups are the other common gap. The EDPB's 2025 coordinated enforcement action on erasure identified deletion of personal data in backups as a recurring problem, so write down how backups are handled, when they expire and what happens if a restore brings back an erased record. Retention exceptions under Article 17(3), such as legal obligations to keep financial records, should be documented per record class with a named owner.
What evidence a supervisory authority or auditor will ask you to produce for erasure
Regulators and auditors will ask for records showing how each erasure request was handled, what was deleted, what was kept and why, and who was told. These six items form the core set for a self-hosted Hyperswitch deployment, where you run every component and hold the records yourself. The GDPR requires no audit, attestation or certificate, so this evidence serves your own accountability and any regulator enquiry.
Written erasure procedure
A dated, versioned document that sets out how a request is received, verified, routed to the Deletion API and closed, including which Hyperswitch components hold customer personal data in your deployment. Name an owner and an approver for each step. Re-check it after each Hyperswitch upgrade, because a new release can change which tables, caches or services hold data, and record the version it was reviewed against.
Request log with Deletion API results
One record per data subject request, holding the receipt time, identity check outcome, response deadline, each Deletion API call with its timestamp and response, and the final outcome. Supervisors ask how long requests took and whether any deletion failed without anyone noticing. Keep the log outside the systems being erased so the evidence survives the deletion. After each upgrade, run a test deletion in staging and confirm the response fields your log expects still match.
Retention schedule with legal basis
A table listing each category of customer data Hyperswitch stores, such as payment metadata, vaulted card references, customer profiles, logs and support notes. For each category, record the retention period, the legal basis for keeping it, and the event that starts the clock. Article 17(3) exceptions, such as a legal obligation to keep transaction records, decide what survives a request. Review the schedule whenever you enable a new connector or module, since each one can add a data category.
Backup purge and expiry records
Records showing when a deleted customer's data was removed from PostgreSQL replicas, Redis caches, log stores and backups, and when backups containing that data expired. The EDPB's 2025 coordinated enforcement action listed deletion of personal data in backups among its recurring challenges. Document your backup rotation period and a restore procedure that re-applies deletions after a restore. Confirm the backup retention settings with the owners of your database and backup tooling.
Article 19 recipient notification records
Records of each recipient that received the customer's data and was told about the erasure, as Article 19 requires controllers to do unless this proves impossible or involves disproportionate effort. Keep the notice sent or the documented reason none was sent. In Hyperswitch, recipients can include connected processors, external vaults and fraud engines. Maintain a current list of connector configurations so each recipient can be identified for every request.
Transfer map for erasure data
A map of every location where personal data sits, including the country of each database, backup, log store and support access path, and whether a Chapter V transfer applies. EDPB Guidelines 05/2021 treat remote access from a third country, even only viewing data on a screen, as a transfer. Erasure evidence is complete only if it covers every location on this map. Update the map when you change hosting regions or connect a new processor, and check it against the data flows in each Hyperswitch release.
Configuring erasure and retention in a self-hosted Hyperswitch, in order
This sequence takes the operator from knowing where customer personal data sits in a self-hosted Hyperswitch to a tested, repeatable erasure process. Each step names an operator owner and closes with a record that can be shown to a data protection authority or auditor.
Inventory personal data in every component
Work through the router, scheduler, PostgreSQL primary and replica, Redis, application and access logs, Control Center and the card vault. For each, record which personal data it holds, why it is held, where it is copied, and whether a deletion path exists. Include backups, observability exports and any downstream system that receives data from Hyperswitch, because each copy is something an erasure request must reach. The data protection lead owns the register, and each component owner signs off their entry. The step is done when every component has a complete entry in the register.
Define retention periods for each category
For each data category in the inventory, the DPO or legal counsel records how long the operator keeps it, the reason for that period, and the event that starts the clock, such as the end of a customer relationship or a statutory record-keeping duty. Set the action at expiry for each category: delete, or anonymise only where counsel has confirmed that anonymisation meets the purpose. The EDPB's 2025 coordinated enforcement action found anonymisation used in place of deletion to be a recurring problem, so the schedule should say when it applies. The step is done when a signed retention schedule is approved by the DPO and the business owner of each system.
Confirm Deletion API scope for your version
Platform engineering reads the Hyperswitch GDPR documentation and the release notes for the exact version running in production. It then runs the published Deletion API against a staging copy to establish which records it removes, which it only redacts, and which it leaves in place, such as transaction or ledger records needed for reconciliation. Scope should not be assumed to carry across upgrades. Record the version tested, the observed behavior and any gaps against the inventory, and raise gaps with the vendor or the community before go-live. The step is done when the platform lead and the DPO approve a written scope note.
Build request intake and triage with Article 17(3) exceptions
Privacy operations sets up one intake channel, a method to verify the identity of requesters, a request log with dates, and a triage checklist. For each request, confirm which Article 17(1) ground applies and whether an Article 17(3) exception covers any data, including compliance with a legal obligation, a public task, archiving and research, or the establishment, exercise or defence of legal claims. Where erasure is refused in part, record the reason and tell the requester. Where Article 19 applies, notify recipients of the data. The step is done when a test request runs from intake to a recorded decision with a complete audit trail.
Test deletion in a non-production environment
The QA lead with platform engineering seeds a non-production Hyperswitch deployment with synthetic customer records across the router, PostgreSQL primary and replica, Redis, logs and the vault. They then run erasure requests through the Deletion API and any manual procedures. Afterward, check each store: rows removed or redacted, cache entries cleared, log lines scrubbed, vault data handled as designed, and the replica matching the primary. Record what remains and why. The step is done when the test report lists each component with the expected and observed result and carries the DPO's sign-off.
Define backup purge and restore rules
The backup owner sets out how erased data leaves backups. The rules should state whether backups are purged on a schedule, how long copies are kept, and whether a restored backup is checked against the erasure log before it returns to service. The EDPB's 2025 coordinated enforcement action listed deletion of personal data in backups among recurring challenges, so the rule must be written down and tested. Restore a backup taken before an erasure request in a test environment and confirm the erased records do not reappear. The step is done when the restore runbook is approved and the test result is filed.
Set access control for who can trigger deletion
The identity and access owner limits deletion to named roles and separates the person who approves an erasure from the person who runs it. Access to the Control Center and the infrastructure that holds data is granted only through those roles. Hyperswitch manages Control Center roles inside the product and does not map them from the identity provider, so the operator must maintain the role list and review it on a set schedule. Log each deletion with the requester, approver, operator and time. The step is done when the role matrix is approved and the first access review is recorded.
Schedule periodic review after each release
The change manager adds an erasure review to every Hyperswitch upgrade. Using the release notes and compatibility matrix for each version the operator adopts, the review checks whether new tables, logs, caches or services hold personal data, whether the Deletion API scope has changed, and whether the inventory and retention schedule still match the system. Re-run the non-production deletion test before the release is promoted. The step is done when the review record is filed against the change ticket and every open item has a named owner.
What Hyperswitch does not settle for you under GDPR
Hyperswitch gives you a Deletion API for customer personal data, but the platform stops short of the legal decisions and operating processes that make an erasure request complete. The six gaps below sit with the operator, who must decide, build or confirm each one before relying on the API. Confirm each item with Hyperswitch or within your own environment.
Lawful basis and retention periods
Hyperswitch does not decide which lawful basis applies to each category of customer or payment data, and it does not set how long each category is kept. As the controller, you make those decisions. Before the first erasure request arrives, record a basis and retention period per data category, then compare that schedule with the fields the Deletion API actually removes. Confirm the field-level behavior with Hyperswitch for your version.
Article 17(3) exception decisions
Hyperswitch will process a deletion but has no logic to decide whether an Article 17(3) exception applies, such as a legal obligation to keep transaction records or the establishment, exercise or defence of legal claims. A chargeback or dispute may require retained data. Assign a named decision owner and a documented review step before the Deletion API runs. Confirm with counsel which retention obligations apply in each jurisdiction you serve.
Backups, logs and caches
Calling the Deletion API does not remove copies in PostgreSQL backups or replicas, Redis caches, scheduler queue data or application logs unless your own process reaches them. The EDPB's 2025 coordinated enforcement action on erasure listed deletion of personal data in backups as a recurring challenge. Define backup expiry, log retention and cache handling, then test a restore to confirm erased records do not return.
Downstream system deletion
The Deletion API acts only on data held in Hyperswitch. Copies that reached your ERP, CRM, analytics warehouse, email tools or support desk remain until something removes them. Map every system that receives customer or payment fields from Hyperswitch, then decide for each whether erasure is automatic, manual or out of scope. Confirm with each system owner how they delete records and whether their backups are covered.
Third-country transfer compliance
Hyperswitch does not make any third-country transfer compliant. Under Chapter V, storing data in a cloud outside the EEA, or accessing it remotely from a third country, can be a transfer, and EDPB Guidelines 05/2021 treat even on-screen display for support as one. Map where each component runs, where support staff connect from and which processors you use. Confirm transfer mechanisms with counsel and assess third-country government access before engaging providers.
Who can run deletions
The Control Center supports single sign-on through OpenID Connect only, with no SAML and no JIT or SCIM provisioning. Users must be invited first, and roles are managed inside Hyperswitch, so access to deletion functions has to be reviewed there. Limit the deletion role to a small named group, and confirm with Hyperswitch whether SSO options have changed for your version. Remove access in Hyperswitch when staff leave.
Questions buyers ask before handling GDPR erasure for Hyperswitch data
How much effort does a GDPR erasure workflow for Hyperswitch take?
Effort depends mainly on how many systems hold personal data about a customer and how far erasure must reach into backups. Hyperswitch documents a Deletion API for removing customer PII, but a self-hosted stack also holds data in the Router and Scheduler services, PostgreSQL with its replica, Redis, the card vault, the encryption service, and any logs or analytics exports you run. Each store needs a named owner, a deletion path and a record of what was removed. Backup design is often the largest driver. The EDPB's coordinated enforcement findings, announced on 18 February 2026, listed deletion of personal data in backups among recurring challenges. A transfer map adds work wherever data is accessed or stored outside the EEA. Ask any partner to size the work from a written inventory of stores before agreeing on a figure.
Can an internal team handle Hyperswitch erasure requests alone?
Yes. A team with payments, database and privacy skills can usually build and run the workflow alone, but two parts need testing before anyone relies on them. The first is the scope of the published Deletion API: confirm which objects it removes, what it leaves in place, and how it treats records you must keep for legal or tax reasons. The second is backup purge, which should be proven by restoring test copies and checking that deleted records stay gone. Internal teams often underestimate the legal side. Article 17(3) sets exceptions such as compliance with a legal obligation and the establishment or defence of legal claims, so someone with legal authority must decide retention cases. DeployOpen plans, implements and documents this kind of workflow in infrastructure you control, and a fixed-scope engagement covers only the parts you agree in writing.
How long does a GDPR erasure implementation on Hyperswitch take?
The timeline depends on three things: the size of your data inventory, the change windows you can use in production, and the amount of testing the deletion path needs before go-live. A larger inventory means more owners to confirm and more stores to test. Hyperswitch ships roughly monthly minor releases, so upgrades that touch the deletion path compete with erasure work for the same change windows. Testing covers the Deletion API scope, backup restores and the approval steps for each request type. No duration is set for this topic, so ask any partner to state one in a written scope. DeployOpen agrees deliverables and timelines in writing before fixed-scope work starts, which gives you a document to check against.
What do we need to provide for an erasure engagement?
You provide people and access. Name a data owner for each store that holds customer personal data, including the card vault, the database, logs, analytics exports and any connector that sends data to a third party. Give the implementation team access to the architecture, deployment manifests, database schemas, backup configuration and the Hyperswitch version you run. A legal reviewer must confirm retention periods and Article 17(3) exceptions, because engineers should not make those decisions alone. Your security team should confirm how encryption and key handling apply to deleted data. Review the transfer map as well, since remote access from a third country, including a support session that only displays data, can count as a transfer under EDPB Guidelines 05/2021. Agree in advance who approves each deletion request and who records it.
What should a quote for GDPR erasure work include?
A quote should follow from a written scope and list what each price covers. Ask for the systems in scope with their owners, the deletion path for each (Deletion API calls, database procedures and backup purge), and the testing for each path, including restore tests. It should also name the retention and exception rules the legal reviewer will confirm, the runbooks and documentation for your staff, and any training. Separate one-time work, such as mapping and building deletion paths, from recurring work, such as request handling, re-testing after upgrades and retained support. Ask which tasks stay with your team, such as change approvals and legal sign-off, and what is excluded. State the assumptions about your infrastructure and Hyperswitch version. DeployOpen does not publish a price list, so a written quote based on your scope is the route to a figure.
Does GDPR erasure cost less when a team already self-hosts Hyperswitch?
Cost depends on what your team already has and what it must add. A team that already runs the stack has the infrastructure in place, so the new spend is mostly labour: mapping personal data, building deletion paths, testing backups and writing procedures. Costs rise with the number of stores, the number of transfers that need legal review, and the depth of retention analysis. They fall when the data inventory is current and the backup design is simple. Recurring costs include staff time for each request, re-testing after upgrades and any retained support. No price is given here. Ask for a quote that separates people, tooling, testing and legal review, and that states which costs continue after go-live.
What evidence will auditors expect for erasure, and can DeployOpen certify it?
Auditors and supervisory authorities look for evidence: a documented process, a log of requests and decisions, proof that deletion ran, and results from backup restore tests. The GDPR requires no audit, attestation or certificate, so the evidence is what you show. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Article 42 certification is voluntary and does not reduce the responsibility of the controller or processor. Keep request records, exception decisions and restore test results together so an independent reviewer can follow each case from request to completion.
How DeployOpen scopes and delivers erasure and retention work for self-hosted Hyperswitch
DeployOpen approaches erasure for a self-hosted Hyperswitch by treating every component as the operator's responsibility, from the Router and Scheduler through PostgreSQL, Redis, the card vault and backups. Engagements are fixed-scope, so the written scope sets which stores, Deletion API calls and retention rules are covered before work starts. Ongoing support is available as a retainer.
How we scope
- The written scope lists each data store holding customer personal data, including PostgreSQL, Redis and the card vault.
- Scope records which erasure grounds under Article 17(1) apply and which Article 17(3) exceptions your retention rules rely on.
- Scope also covers logs, analytics copies, backups and exports, with the handling for each agreed in writing.
How we build
- Build the erasure workflow around the published Deletion API, with requests logged, authorized and traceable to each customer record.
- Confirm which stores the Deletion API reaches, and build jobs for any personal data it does not cover.
- Test erasure in staging against a restored backup, since regulators have flagged deletion in backups as a recurring gap.
How we hand over
- Handover includes the erasure runbook, the record of each deletion check, and the retention schedule mapped to each store.
- Documentation covers Router, Scheduler, PostgreSQL, Redis and vault configuration, so your team can rerun deletions without us.
- Evidence packs support your assessors, since independent auditors and certification bodies issue any audit report.
How we support
- Retainers can cover Hyperswitch minor release upgrades, which ship roughly monthly and each publish a compatibility matrix.
- Upgrade checks cover required dependencies, such as the Superposition service that v1.124.0 requires running before upgrading to it.
- Ongoing support can also include periodic erasure tests, control reviews and scope updates as your processing changes.
