PCI DSS

This page provides what your organisation needs in order to determine its PCI DSS scope: Lunixi's controls over cardholder data, how the card storage procedure operates, and the consequence of your integration path.

Certification status

Lunixi's controls are designed against PCI DSS v4.0 as a Level 1 Service Provider, and the certification process is under way.

Allocation of roles

PCI DSS places obligations on every party that handles cardholder data. In this relationship Lunixi is the service provider and your organisation is the merchant. Lunixi's compliance does not extend to your organisation; it can only narrow your scope.

Protection of cardholder data

Cardholder data is protected through a dedicated encryption infrastructure isolated from the application layer.

• Encryption and decryption are performed by a hardware security module (HSM); the application does not perform these operations itself.
• Encryption keys never reach the application layer. They are not held in application memory, configuration files or the database.
• The database holds only the ciphertext of the card number.
• Decryption occurs solely in flows that require the PAN to be transmitted to an acquirer; the decrypted value is never persisted.
• Connections to the encryption infrastructure are protected by TLS, and certificate pinning is mandatory for remote configurations.

What is retained, and what is not

Encrypted card numbers may be held in three distinct records, according to how the card was captured: a short-lived temporary card record, a single-use tokenisation record, and the merchant card vault. All three hold ciphertext only.

Card storage procedure

Card storage is a controlled process that allows your customers' cards to be reused on subsequent payments. The steps below define the control points that are material to a PCI DSS assessment.

1. Authorisation — disabled by default

Card storage is disabled by default for every merchant and must be explicitly enabled from the panel (Payments → Form Settings → Card Storage). Until it is enabled, no card is stored and requests to charge a stored card are rejected. The only supported vault provider is Lunixi's own encryption infrastructure; no third-party vault is used.

2. Creation of the record — only after a successful 3D Secure charge

A card is not written to the vault unless all three conditions are met:

1. Card storage was requested on the payment,
2. Card storage is enabled for the merchant,
3. The payment completed through 3D Secure.

The card is written to the vault only after the charge has succeeded. No stored card can therefore originate from an unauthenticated or failed transaction.

3. Determination of the customer key

The key that binds a card to a customer is resolved server-side; it is not read from the request body. This control prevents a caller from writing a card into, or reading, another customer's vault. If the key cannot be resolved, the card is not stored and the payment flow continues without interruption.

4. Deduplication

Where the same card is submitted for storage more than once, no additional record is created; the token of the existing record is returned. Uniqueness is established by decrypting candidate records through the encryption infrastructure and comparing full card numbers. During this operation the cleartext values exist only in process memory for the duration of the comparison and are never persisted.

5. Use of the token

Following storage, your organisation receives only an opaque storedCardToken. The token does not contain the card number, is not derived from it and cannot be reversed. Subsequent charges are made with the token; no card number reaches your systems.

6. End of life

• A card may be deleted by the customer or by your organisation; the token of a deleted record is invalidated.
• Cards past their expiry date are deactivated automatically: they are excluded from listings and cannot be charged.
• Temporary card and tokenisation records are cleared automatically on expiry.

For the endpoint contracts and integration steps, see Stored Cards.

Log hygiene

The absence of cardholder data in application logs is enforced by a central redaction layer. Candidate card numbers in log content are validated with the Luhn algorithm before redaction, and the redaction layer is wired into both the application logging pipeline and the error tracking pipeline. For detail, see KVKK.

Shared responsibility

Integration checklist

• API keys are held in a secrets management solution, not in source code or logs
• All calls are made over HTTPS — Lunixi rejects unencrypted connections
• The Authorization header is written to no logging pipeline
• If using the Direct API, your PCI DSS obligation has been confirmed with your assessor
• Where the narrowest scope is required, the hosted payment form is in use
• Cardholder data is not written to your application logs, crash reports or analytics
• Audit records are retained for the period your PCI DSS requirements specify

Contact

For scope assessment, definitions of encryption and key management, or questions on certification status: [email protected]