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:

Procedure	Prerequisite	Result
Deletion	The customer has no finalized invoice.	The customer record is removed from the interface.
Anonymization (GDPR)	The customer has finalized invoices.	Personal data is rendered unrecognizable; the documents subject to retention obligations are kept.

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 customer record of their own — with name, address and email address — is kept by Stripe and Unzer. Both procedures — deletion and anonymization — therefore take effect there as well: Kyvento removes the customer record and the stored payment methods, as far as the provider's interface allows. How far that reaches differs:

Provider	Customer record	Stored payment method
Stripe	is removed	is removed along with the customer record
PayPal	the provider does not keep one	the stored access token (vault token) is removed
Unzer	is removed	remains in place — the interface provides no way to delete it

PayPal: maintains no customer record — there is only the stored payment method, whose saved access token (vault token) is removed. Collection is no longer possible after that.

Within Kyvento itself, the customer's payment methods are marked as deleted in all three cases — collection is no longer possible afterwards.

Scope by provider

At Unzer, the customer and the payment method are two independent resources. The customer record with name, address and email address is removed; for an individual payment method, Unzer provides no deletion route. It remains there until you instruct the provider to delete it — the basis is your contract with Unzer, who can carry out the deletion outside the interface. Nothing has failed here; the route simply does not exist.

Kyvento flags the remaining payment method in both procedures:

• With anonymization, the operation is not considered complete: the customer shows the state "Payment method remains with the provider". Once Unzer has confirmed the deletion, you close the operation via the corresponding button with a reason, which is recorded in the change history.
• With deletion, the account administration receives the notification "Payment method remains at the payment provider", naming the provider and the identifier of the remaining payment method — instruct the deletion using that identifier. The customer itself has already been removed at that point and can no longer carry a state.

What stays with the provider

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

Two practical consequences: a refund for a payment already executed is triggered directly at the payment provider after deletion and then recorded in Kyvento — the procedure is described for PayPal in Recording a PayPal refund manually in Kyvento. And if you create the same customer again later, a new customer record is created at the provider; payment methods have to be stored anew.

If deletion at the provider fails

The operation runs in the background and is retried several times if the provider is disrupted. Within Kyvento, the customer is removed immediately after your confirmation.

If deletion ultimately fails, Kyvento reports it: an entry in the change history records the time, the provider and the error message, and the account administration is asked to delete the record at the provider manually. With anonymization, the customer additionally shows the status "Deletion of payment data at the provider failed"; after manual deletion you close the operation via "Mark as handled externally" with a reason.

Retained data

Regardless of the procedure, the following data is retained:

• Invoices and payments with the original recipient details. They are subject to the statutory retention obligations 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 – a paused dunning run still counts as open and does not lift the block.
• No unpaid receivables. Unpaid invoices must first be collected, written off or cancelled – after anonymization, the customer can no longer be reached.
• No customer credit balance. An existing credit balance must first be offset against an invoice or written off: on the customer page, in the "Customer credit" card, via "Adjust credit" with the transaction type "Manual adjustment", a negative "Adjustment amount (signed)" equal to the balance and the required field "Description".
• Archived recipient details on all invoices. If these are missing on older invoices, they must be added by the administrator before anonymization is possible.

Documents with an e-invoice still in retention do not block anonymization. If the customer has such documents, Kyvento shows the notice "Documents of this customer are kept", stating how many such documents there are: the documents are not deleted and keep their recipient details – what is anonymized is the customer record. Whether you carry out the erasure request is your decision. Anonymization can then only be carried out once you have ticked the checkbox "I have read which documents are kept and carry out the erasure."

Before execution, Kyvento displays an overview of the impact: the number of active subscriptions, open dunning runs, finalized invoices, saved payment data and invoices without archived recipient data; where applicable, also the unpaid receivables (number of documents and amount) and the customer credit balance (amount). 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 the dunning run, i.e. pay, cancel or write off the dunned invoice as uncollectible. Pausing is not enough – paused dunning runs deliberately still count as open (for pausing itself, see Pausing or suspending dunning).
• Anonymization blocked by unpaid receivables: collect the unpaid invoices, write them off or cancel them, then run again.
• Anonymization blocked by a customer credit balance: offset the credit balance against an invoice or write it off via "Adjust credit" as a "Manual adjustment" with a negative amount (see prerequisites), then run again.
• 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.
• Notice "Documents of this customer are kept": not a blocker. Tick the checkbox "I have read which documents are kept and carry out the erasure." so that anonymization can be carried out.
• 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