HighFile-scopeJavaScript / TypeScript Plug & play

Use client tokenization; backend never receives PAN

For web/mobile payment forms, send PAN and CVV directly to the PCI-compliant gateway to obtain a single-use token; submit only the token to your backend. Validate that backend APIs reject requests containing PAN/SAD. (PCI DSS scoping & SAQ A)

Add to Mesrai Open workspace

Why this matters

Keeping PAN out of your environment reduces PCI scope and breach impact.

Bad vs. good

Side-by-side examples engineers can pattern-match during review.

Avoid

// ❌ raw PAN sent to backend
await fetch('/api/pay', { method:'POST', body: JSON.stringify({ pan, cvv }) });

Prefer

// ✅ tokenize in client; backend sees token only
const token = await gateway.tokenize({ pan, cvv });
await fetch('/api/pay', { method:'POST', body: JSON.stringify({ token }) });

More snippets

Bad

formData.append('pan', cardNumber)

Good

const token = await gateway.tokenize({pan, cvv}); formData.append('token', token)

Related rules

From the same buckets as this rule.

Critical
Disallow CVV/CVC persistence anywhere
Never store CVV/CVC or other SAD after authorization in databases, caches, files, or telemetry. Schema/models must not define fields for CVV/CVC; reject writes containing cvv/cvc keys. (PCI DSS 4.0 Req. 3.2.1)
compliance-pci-dsssecurity-hardening+1
Critical
Mask PAN and exclude SAD from logs
Never emit Primary Account Number (PAN) or Sensitive Authentication Data (SAD: CVV/CVC, full track data, PIN) to application or audit logs. Per PCI DSS 4.0 Req. 3 and 10, always mask PAN as first6last4 and fully redact SAD before logging.
compliance-pci-dssobservability-logging+1
High
Block real PAN/SAD in fixtures and test data
Reject PRs adding real PAN/CVV in fixtures, seeds, or mocks. Only use Luhn-valid test PANs from the gateway or opaque tokens (e.g., tok_) and never include CVV. Add a check to fail if a PAN regex is matched. (PCI DSS data minimization)
compliance-pci-dsstesting-quality+1

Bad vs. good

Side-by-side examples engineers can pattern-match during review.

Avoid

// ❌ raw PAN sent to backend
await fetch('/api/pay', { method:'POST', body: JSON.stringify({ pan, cvv }) });

Prefer

// ✅ tokenize in client; backend sees token only
const token = await gateway.tokenize({ pan, cvv });
await fetch('/api/pay', { method:'POST', body: JSON.stringify({ token }) });

More snippets

Bad

formData.append('pan', cardNumber)

Good

const token = await gateway.tokenize({pan, cvv}); formData.append('token', token)

Related rules

From the same buckets as this rule.

Critical

Disallow CVV/CVC persistence anywhere

Never store CVV/CVC or other SAD after authorization in databases, caches, files, or telemetry. Schema/models must not define fields for CVV/CVC; reject writes containing cvv/cvc keys. (PCI DSS 4.0 Req. 3.2.1)

compliance-pci-dsssecurity-hardening+1

Critical

Mask PAN and exclude SAD from logs

Never emit Primary Account Number (PAN) or Sensitive Authentication Data (SAD: CVV/CVC, full track data, PIN) to application or audit logs. Per PCI DSS 4.0 Req. 3 and 10, always mask PAN as first6last4 and fully redact SAD before logging.

compliance-pci-dssobservability-logging+1

High

Block real PAN/SAD in fixtures and test data

Reject PRs adding real PAN/CVV in fixtures, seeds, or mocks. Only use Luhn-valid test PANs from the gateway or opaque tokens (e.g., tok_) and never include CVV. Add a check to fail if a PAN regex is matched. (PCI DSS data minimization)

compliance-pci-dsstesting-quality+1