TokeniPCI and the CDE
Where card data is allowed to exist, and what Tokeni never writes to disk.
Tokeni is designed as PCI DSS Level 1 tokenization infrastructure. The cardholder data environment (CDE) is isolated in a separate AWS account. Non-CDE services (gateway, dashboard, this docs site) never define types for a raw PAN or CVV.
What may exist where
| Data | CDE | Gateway / your app |
|---|---|---|
| PAN (plaintext) | Volatile memory during tokenize / detokenize | Never, unless you are yourself in PCI scope and called tokenize/detokenize |
| PAN at rest | AES-256-GCM only | Never |
| CVV / track / PIN | Volatile memory only, then gone | Never stored |
| Token ID | Yes | Yes. This is what you persist |
| BIN + last four | Yes | Yes. Display as 411111******1111 |
Gateway to CDE is gRPC with mTLS. Production can use PrivateLink. Tokens flow out. Raw card data does not.
Hosted fields
The iframe is the CDE-hosted input. Your origin should not receive a PAN from postMessage, your analytics, or your error tracker. If you see a full card number in your logs, that is a bug in your page, not a Tokeni display format.
Audit
Auditable actions log correlationId, UTC timestamp, actor, action, resource, source IP, and success/failure. They do not log PANs, CVVs, or secrets.
What we do not claim here
This page is not an Attestation of Compliance. Ask compliance@tokeni.io for the current evidence package and certification status. Tokeni does not document 3-D Secure, network tokens, or account updater on this site because those products are not what this API is.