Security and compliance
The security posture WinkPG runs on, the compliance frameworks it is assessed against, and how to obtain the evidence behind each claim.
The WinkPG platform default. An operator may replace it with their own text. Last reviewed 20 September 2026.
What this page is and is not
This page states the platform's posture. It does not publish the evidence behind it, and that is deliberate: an evidence set names internal systems and configuration in the detail an attacker would want.
The evidence is published through the trust document library, where a signed-in developer account can retrieve it and every retrieval is recorded. Nothing is claimed here that the library cannot back with a document.
PCI DSS
The platform is designed against the PCI DSS v4.0 baseline. An internal control matrix maps every applicable sub-requirement to the control that implements it, the evidence for it and a status, and the matrix is honest about what is still open. It is available through the trust document library as part of the compliance evidence set.
Formal validation by a Qualified Security Assessor is performed per customer environment. It can run through the operator's assessor or through one a customer already engages. Multi-tenant service provider controls are covered in the same matrix.
Cardholder data is encrypted at the field level with AES-256-GCM under a key hierarchy held in a managed key vault, and a primary account number is masked wherever it is displayed. Card verification values, PINs and full magnetic stripe or chip data are never stored.
SOC 2
A deployment the operator hosts inherits the SOC 2 certification of the cloud platform it runs on. Material covering the operational layer above that is provided separately, through the trust document library, and a bridge letter is listed there when one is current.
Where the library lists no SOC 2 entry yet, the honest answer is that the operational layer report is not on file, rather than that it exists and is withheld.
Testing
The platform runs an authenticated API fuzzing suite daily against its own published surface, and the findings it raises are triaged.
An independent penetration test summary is published through the trust document library when one is on file. This page states no testing cadence the library cannot evidence.
Data protection in transit and at rest
TLS 1.2 is the minimum on every public domain, on every host and on every data store, and strict transport security is asserted. A primary account number never leaves the platform inside a notification message.
Secrets are held in a managed key vault and reached through workload identities rather than through credentials in configuration.
Access control
Access follows a role ladder with per operation checks and a default of deny. A user may not hold roles from two rungs of that ladder, and the platform enforces that in three places rather than relying on the administrator who assigns them.
Multi-factor authentication and step-up re-authentication for sensitive actions are available and configurable per tenant. The shipped defaults for password length, lockout and multi-factor enforcement are deliberately not presented here as meeting the PCI DSS values: the control matrix records exactly where they sit and what an operator must raise them to.
Logging and monitoring
Administrative and security relevant actions are recorded in an audit log with the values before and after a change. Application logs are structured, enriched with correlation identifiers and shipped centrally, and every timestamp is UTC.
Redaction of sensitive data from logs is unconditional. There is no environment gate and no configuration switch that turns it off, because a safety property that depends on a setting is not a safety property.
Secure development
Changes ship through reviewed pull requests against a closed dependency feed. Input validation is enforced from a single declarative source rather than scattered through handlers, and a content security policy with per request nonces protects the card entry surface.
Environments are separated, and an interactive tool in the developer portal refuses a live credential structurally rather than by configuration.
Other frameworks
ISO 27001: the principles are followed; formal certification depends on an audit that has not been completed.
HIPAA: not in scope. The platform handles payment data.
GDPR: the platform supports the right of access through a structured export, the right of erasure through an event-driven cascade delete, consent tracking, data portability in a standard format, and per category retention. The data processing addendum carries the processor terms.
Reporting a vulnerability
Report a suspected vulnerability to the operator of this instance through the support contact in the footer. Include enough detail to reproduce it, and please give the operator a reasonable period to remediate before disclosing publicly.
Do not test against a production environment, and do not use another customer's data to demonstrate a finding. A sandbox account is available for the purpose.
Customer-specific requirements
Requirements beyond this baseline are accommodated per deployment: mutual TLS, certificate pinning, a customer-owned key vault, a customer-owned observability stack, additional encrypted fields, extra identity providers and regional data residency are all configurable or extensible. Some need a service order.
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.