Deleting and anonymizing a customer

Overview

Kyvento provides two procedures for removing a customer: deletion and GDPR anonymization. Both procedures also affect the connected payment provider: if a record for this customer exists at the connected payment provider, it is deleted as well. How far the removal at the provider reaches depends on the provider's API: at Unzer, a stored payment method remains.

This article describes which procedure is available in which case, which data is removed, which data is retained due to statutory retention obligations, and what the deletion at the payment provider means in practice.

Procedures: deletion or anonymization

Which procedure is available depends on the customer's invoice status:

An attempt to delete a customer with finalized invoices is rejected; the message refers to anonymization. The reason is the commercial retention obligation: an invoice must remain attributable to its recipient.

Deletion procedure

1. Invoice check: if at least one finalized invoice exists, the operation is aborted.
2. Termination of active subscriptions: the customer's active subscriptions are cancelled immediately and archived. If a cancellation fails, the entire deletion is rolled back.
3. Removal of the customer record in the Kyvento account.
4. Deletion at the payment provider – asynchronously, see the following section.

Deletion at the payment provider

A separate customer record containing name, address and email address is maintained by Stripe and Unzer. Where such a record exists for the customer, it is removed automatically on deletion and on anonymization:

• Stripe: the customer record is removed through the provider's deletion interface. The payment methods stored there are removed as well.
• Unzer: the customer record is removed through the provider's deletion interface; name, address and email address are therefore no longer held there. If the record is no longer present, the operation counts as completed. A stored payment method remains – see Scope by provider.
• PayPal: the provider maintains no customer record. What is removed is the stored access token of the stored payment method (vault token); collection is no longer possible afterwards.

The payment history at the provider is not affected: payments, refunds and payouts that have already been executed remain in the payment provider's records. They are subject to the provider's retention obligations and are not part of the customer record.

Scope by provider

How far the removal at the payment provider reaches is determined by that provider's API. Kyvento uses the deletion functions that the respective provider makes available through its API:

At Unzer, the customer and the payment method are two separate resources. The customer record containing name, address and email address is removed through the deletion interface; for an individual payment method, Unzer provides no deletion route. It remains there until the provider removes it.

What to do: request the deletion of the remaining payment method directly from Unzer. This is based on your contract with the provider; Unzer can carry out the deletion outside its API.

Kyvento flags the remaining payment method in both procedures:

• Anonymization: the operation does not count as completed but shows the state "Payment method remains at the provider" on the customer record. Once Unzer has confirmed the deletion, close the operation via the corresponding button, providing a reason. The reason is recorded in the change history – see Audit log and change history.
• Deletion: the account administration receives the notification "Payment method remains at the payment provider", stating the provider and the identifier of the remaining payment method. Use that identifier to request the deletion from Unzer. The customer itself has already been removed at that point and no longer carries a state.

Implications

• Payment methods at Stripe: the cards and mandates stored under the customer record are removed with it; collection via these payment methods is no longer possible.
• Payment methods at Unzer: a payment method stored there remains; you need to request its deletion from Unzer. Collection via it is no longer possible from Kyvento: the payment method is marked as deleted in the account.
• Refunds: after deletion, a refund for an already executed payment must be issued directly at the payment provider and then recorded in Kyvento. The procedure is described, using PayPal as an example, in Recording a PayPal refund manually in Kyvento.
• Re-creation: if the customer is created again later, Kyvento creates a new customer record at Stripe or Unzer. Payment methods must be stored again.
• No manual action for the customer record: the customer record at Stripe or Unzer does not need to be deleted separately in the provider's interface. The payment method remaining at Unzer is the exception.

Execution and error handling

Deletion at the provider is executed asynchronously and, in the event of a provider outage, retried up to five times with increasing intervals; the last attempt takes place approximately two and a half hours after the first. Within Kyvento, the customer is removed immediately after confirmation.

If deletion at the provider fails after all attempts, this is logged and reported:

• An entry in the change history records the time, the affected provider and the error message – see Audit log and change history.
• The account administration receives a notification requesting manual deletion of the record at the provider.
• For anonymization, the status "Deletion of payment data at the provider failed" is additionally displayed on the customer. After manual deletion at the provider, the operation is completed via the action "Mark as handled externally" with a reason.

This is distinct from the payment method remaining at Unzer: nothing has failed there – the provider's API does not provide for deletion. The state, the notification and how to proceed are described in the section Scope by provider.

Retained data

Regardless of the procedure, the following data is retained:

• Invoices and payments with the original recipient details. They are subject to the ten-year retention obligation under Section 257 HGB and Section 147 AO and must not be modified retrospectively – see GoBD-compliant archiving.
• The change history of the operation: for deletion, the executing user and the time; for anonymization, additionally the mandatory reason.

The obligation to erase under data protection law is limited by the statutory retention obligations.

Anonymization: prerequisites and procedure

Anonymization is the procedure for customers with finalized invoices. Prerequisites:

• No active subscriptions. Ongoing contracts must be terminated first.
• No open dunning procedure. Ongoing dunning runs must be completed or paused.
• Archived recipient details on all invoices. If these are missing on older invoices, they must be added by the administrator before anonymization is possible.
• No e-invoice within the ten-year retention period. If an e-invoice was generated for the customer less than ten years ago, anonymization is blocked: the generated XML file contains the recipient details and must be retained unchanged.

Before execution, Kyvento displays an overview of the impact: the number of active subscriptions, open dunning notices, finalized invoices and stored payment data. Confirmation requires a reason (e.g. "GDPR request dated 2026-05-09") and entry of the customer number. Anonymization cannot be reversed either.

On execution, name, company name, address, email address and phone numbers are replaced with placeholders; VAT ID and tax number are stored only as a non-reversible hash; stored payment methods and SEPA mandates are removed – at Unzer with the limitation described above; access to the customer portal is revoked; email history and checkout data are cleaned up. The customer then remains visible in read-only mode and is marked as anonymized.

Checks before execution

1. Open items: are there unpaid invoices? After anonymization, the recipient can no longer be contacted.
2. Active subscriptions: on deletion, they are cancelled immediately.
3. Outstanding refunds: refunds must be issued while the payment method is still stored at the provider.
4. Data access request: if the customer requests a copy of their data in addition to deletion, the data export must be created before deletion.

Error messages and blockers

• "This customer has finalized invoices and cannot be deleted. Please use the GDPR anonymization workflow." – Expected behaviour. Use anonymization.
• Anonymization blocked by active subscriptions: terminate the subscriptions, then run again.
• Anonymization blocked by an open dunning procedure: complete or pause the dunning run – see Pausing or suspending dunning.
• Missing archived recipient details: older invoices do not yet contain the recipient details as an archived snapshot. The administrator can add them; anonymization is possible afterwards.
• Anonymization blocked by a generated e-invoice: the ten-year retention period is still running. Anonymization is not possible until it expires.
• Notification of a failed deletion at the provider: delete the customer record manually in the payment provider's interface and then mark the operation as handled externally.
• State "Payment method remains at the provider" (Unzer, after an anonymization): not an error, but the limit of the provider's API. Request the deletion of the payment method from Unzer and then close the operation, providing a reason.
• Notification "Payment method remains at the payment provider" (Unzer, after a deletion): not an error either. The notification states the provider and the identifier of the payment method; use it to request the deletion from Unzer.

Related articles

• Terminating contracts – Managing cancellations
• Retention obligations and audit-proof archiving – GoBD-compliant archiving
• Tracing operations – Audit log and change history