Data retention schedule

How long WinkPG keeps each category of data, and what happens to it at the end of that period.

The WinkPG platform default. An operator may replace it with their own text. Last reviewed 20 September 2026.

How to read this schedule

Each row is a category of data, the period it is kept for and what happens when that period ends. The periods are the platform's configured defaults.

Retention is configurable per deployment, so the instance you integrate with may keep a category for longer than the default where its own regulatory obligations require it. Where a period matters to your own compliance position, confirm it against the agreement rather than against this page.

A retention period is a maximum, not a commitment to keep data that long. An erasure request deletes sooner, subject to the records that have to be retained for a legal obligation.

What is never stored

Card verification values, PINs, full magnetic stripe data and chip data are not written to any store. They are used to complete the authorization and then discarded.

This is enforced structurally rather than by policy. Every container that can hold card data declares those fields as not persisted, and a test fails the build when a new one does not.

Deletion requests

A data subject erasure request is handled through the platform's own data subject request handling, which cascades the deletion across the records that reference the subject. Records the platform must retain for a financial or card network obligation are kept, and the requester is told which.

Retention by data category

Data category	Retention period	At the end of the period
Card verification values, PINs, magnetic stripe and chip data	Never stored	Discarded in memory once the authorization response is received. No container in the platform persists these fields, and a test fails the build if one gains the ability to.
Primary account numbers and payment tokens	For the life of the merchant relationship, unless deleted sooner	Encrypted at the field level while stored. Deleted on a merchant's or a cardholder's erasure request, and on account closure.
Transaction records	7 years by default	Retained for financial reporting, chargeback defense and audit. Card numbers within them are masked to the last four digits once the settlement window closes.
Audit logs and security event records	Configurable per deployment	Expired by the store's own time to live once the configured period passes.
Application and diagnostic logs	30 days by default	Expired automatically. Cardholder data and authentication secrets are redacted before a log line is written, so an expired log never held them.
User accounts and profile data	For as long as the account is active	Deleted on request through the platform's data subject request handling, which cascades the deletion across the records that reference the account.
Sandbox and test data	No guaranteed retention	Sandbox environments are not backed up and may be reset. Do not keep anything in a sandbox that you need later.

Evidence and compliance materials

This surface states posture and publishes no evidence. The attestations, reports and control matrices behind these statements are in the trust documents catalogue, where a signed-in developer account can retrieve them and every retrieval is recorded.