PCI Compliance Overview
Gatelithix is built as a PCI DSS 4.0.1 Level 1 Service Provider from day one. This page explains what that means, how the system protects cardholder data, and what it means for your PCI compliance posture as a merchant.
Short version for merchants: If you use our Hosted Fields or tokenize cards client-side with our SDK, your servers never touch raw card numbers. This typically qualifies your integration for SAQ-A — the simplest PCI self-assessment questionnaire. We carry the compliance burden for the card data itself.
What Is PCI DSS?
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements established by the major card brands (Visa, Mastercard, American Express, Discover, JCB) and managed by the PCI Security Standards Council. Any entity that stores, processes, or transmits cardholder data — card numbers, expiry dates, CVVs — must comply.
PCI DSS 4.0.1 (the current version) contains 12 requirement families covering:
| Requirement Family | What It Covers |
|---|---|
| 1 — Network Security | Firewalls, network segmentation, CDE isolation |
| 3 — Stored Data | Encryption of PANs at rest, prohibition on storing CVV |
| 4 — Data in Transit | TLS 1.2+ on all paths carrying cardholder data |
| 6 — Secure Development | Code review, dependency scanning, change control |
| 7–8 — Access Control | Least privilege, MFA, service account management |
| 10 — Logging & Monitoring | Audit trails, tamper-proof log retention |
| 11 — Security Testing | Vulnerability scans (quarterly ASV), penetration testing |
Non-compliance can result in card brand fines, increased transaction fees, and loss of the ability to accept card payments. For service providers like Gatelithix, registration on the Visa Global Registry and Mastercard SDP requires a valid Attestation of Compliance (AOC).
Our Compliance Level
Gatelithix targets Level 1 Service Provider — the highest and most rigorous validation level.
| Property | Value |
|---|---|
| Level | Level 1 Service Provider |
| Standard | PCI DSS 4.0.1 |
| Approach | Defined Approach |
| Assessment | Annual QSA-conducted ROC (Report on Compliance) |
| Scanning | Quarterly ASV external vulnerability scans |
| Output | AOC (Attestation of Compliance) provided to card brands |
Why Level 1 from day one? Level 1 requires an annual on-site assessment by a certified QSA (Qualified Security Assessor). We build to this standard from the start because it avoids costly re-architecture later, satisfies the highest-scrutiny acquiring bank requirements, and provides the most credible compliance signal to enterprise merchants.
CDE Architecture Overview
The Cardholder Data Environment (CDE) is the boundary containing all systems that store, process, or transmit cardholder data. Defining this boundary tightly is the foundation of PCI compliance — everything inside is in scope, everything outside is not.
Gatelithix uses strict CDE isolation: the entire CDE is confined to a single GCP project (gatelithix-pci) with its own VPC, IAM policies, and Cloud SQL instance. The core platform project (gatelithix-core) handles everything else and never stores raw card numbers.
Zone summary:
- Red (CDE): The vault service, PCI Cloud SQL, and Cloud KMS. These are the only systems that ever touch raw or encrypted PANs. Strictly isolated in
gatelithix-pciGCP project. - Yellow (Connected-to): The gateway API and connector services. They route payments and communicate with the CDE, but only exchange gateway tokens — never raw card numbers.
- Green (Out of scope): Dashboard, docs, billing, reporting. These services have no CDE connectivity and are entirely out of PCI scope.
How We Protect Cardholder Data
Encryption at Ingress
When a card is tokenized, the PAN is encrypted before it leaves the vault request handler using AES-256-GCM via Cloud KMS HSM (FIPS 140-2 Level 3). The raw PAN exists only in vault process memory for the duration of the encrypt operation, then the Go byte slice is zeroed with defer. It is never written to a database in plaintext, never included in any log, and never passed to another service.
The ciphertext, wrapped DEK, and KMS key version are stored in PCI Cloud SQL (private IP, no public endpoint, TLS-only). The Cloud KMS master key material never leaves the HSM boundary.
Token-Based Architecture
After tokenization, the card is represented everywhere outside the CDE as a gateway token (tok_live_... or tok_test_...). Tokens are not cardholder data — they cannot be reversed to a PAN without access to both the encrypted ciphertext in PCI Cloud SQL and the KMS key. All of your API calls, payment intents, refunds, and webhook events use gateway tokens, never card numbers.
No PAN in Logs or Errors
The gateway applies a PAN filter to all structured log output. Application audit entries record the gateway token, BIN (first 6 digits), last4, and merchant ID. The full PAN never appears in logs, error responses, webhook payloads, or any API response.
Key Management
Encryption keys are managed by Google Cloud KMS backed by Cloud HSM:
pan-encryption-key— AES-256-GCM symmetric key, HSM-protected, 90-day auto-rotationpan-fingerprint-key— HMAC-SHA256 key, HSM-protected, used for deduplication fingerprinting- IAM-restricted: only the vault service account has
cloudkms.cryptoKeyEncrypterDecrypterandcloudkms.signerVerifierroles on these keys - No key material is ever exported or used outside the HSM
Network Segmentation
The PCI VPC (10.1.0.0/20) has a deny-all firewall baseline. Explicit allow rules permit only:
- Inbound TCP 443 from the core VPC range (
10.0.0.0/20) — gateway to vault calls only - Outbound TCP 443 to PSP APIs and Google restricted APIs (
199.36.153.4/30) for KMS
The vault service has no public IP. All vault traffic transits via VPC peering from the core project. PCI Cloud SQL has ipv4_enabled = false — private IP only.
Shared Responsibility
PCI compliance is shared between Gatelithix, Google Cloud Platform, the PSPs, and you as a merchant. Understanding what each party is responsible for prevents gaps.
| Control Area | GCP Provides | Gatelithix Provides | Merchant Responsible For |
|---|---|---|---|
| Physical security (Req 9) | Data center security, hardware | N/A (cloud) | N/A (cloud) |
| Network segmentation (Req 1) | VPC infrastructure, firewall engine | VPC config, rules, project isolation | Your own server firewall |
| Encryption at rest (Req 3) | Cloud KMS/HSM platform | Key management, envelope encryption, PAN handling | Encrypting any card data you store yourself |
| Encryption in transit (Req 4) | TLS termination, cert management | sslmode=require, identity tokens | Using HTTPS for all API calls |
| Access control (Req 7/8) | IAM, Cloud Identity | Role definitions, least privilege, MFA | Restricting who holds your Gatelithix API keys |
| Logging (Req 10) | Cloud Logging, Audit Logs | Application audit logging, audit trail | Logging your own application events |
| Vulnerability management (Req 6/11) | OS patching (Cloud Run managed) | App dependencies, container scanning | Patching your own servers and dependencies |
| PCI assessment | GCP Compliance docs (shared) | Annual QSA ROC + AOC | Your own SAQ or QSA engagement |
Merchant obligation: Even with Gatelithix handling vault and encryption, you have PCI obligations for how you handle API keys, how you build your checkout flow, and whether you ever log or store card numbers in your own systems. See What Merchants Need to Know below.
What Merchants Need to Know
PCI Scope Depends on Your Integration
Your PCI compliance scope — and therefore the effort and cost of your own PCI assessment — depends directly on how you integrate with Gatelithix.
| Integration Pattern | Card Data Touches Your Servers? | Your PCI Scope | Likely SAQ Type |
|---|---|---|---|
| Hosted Fields (recommended) | No — card data goes directly to Gatelithix vault | Minimal | SAQ-A |
| Client-side SDK tokenization | No — PAN sent from browser to Gatelithix | Minimal | SAQ-A |
| Server-side tokenization | Yes — PAN transits your server before vault | Significant | SAQ-D (full scope) |
SAQ-A eligibility: Merchants that outsource all cardholder data handling to a PCI-compliant service provider and never receive card data on their own servers can typically self-assess with SAQ-A — the simplest questionnaire, covering about 20 requirements rather than the 250+ in SAQ-D. Using our Hosted Fields or client-side SDK achieves this.
Rules for Keeping Your Scope Small
Follow these rules to maintain SAQ-A eligibility and the smallest possible PCI footprint:
-
Use Hosted Fields or client-side tokenization. Never build a form that submits card numbers to your server. The PAN should flow directly from the browser to Gatelithix.
-
Never log gateway tokens alongside card metadata that could reconstruct a PAN. Gateway tokens (
tok_live_...) are not cardholder data on their own, but logging them alongside BIN, last4, and expiry together may bring them into scope. Log only what you need. -
Never store card numbers, CVVs, or expiry dates. Gatelithix’s vault handles storage. If your application ever captures and stores card data — even temporarily — you expand your PCI scope significantly.
-
Protect your API keys. Your
sk_live_...key can trigger charges. Treat it as you would a password: store it in a secrets manager, never commit it to version control, rotate it if compromised. -
Verify webhook signatures. Process only webhooks you have cryptographically verified originate from Gatelithix. See Webhooks for implementation details.
See the Security Checklist for a full integration security reference.
Compliance Documentation
Detailed technical compliance documentation is available in the following pages:
| Document | Audience | Contents |
|---|---|---|
| PCI Architecture | Engineers, QSAs | CDE boundary definition, PAN data flow, encryption scheme, audit logging, access controls, evidence for each control |
| PCI Self-Assessment Checklist | Internal, QSA prep | Control-by-control mapping to PCI DSS 4.0.1 requirements |
| PCI Verification Evidence | QSAs, Engineering | Deployed verification commands and expected outputs per requirement |
| Security Checklist | Merchants, Engineers | Integration security best practices and PCI scope reduction guide |
| Architecture Overview | Engineers | Full infrastructure diagram with PCI zone callouts |