pci-dss-compliance
Meet PCI-DSS payment security requirements by scoping your environment correctly, selecting the right SAQ, and implementing required controls
What this skill does
# PCI-DSS Compliance
## Overview
PCI-DSS (Payment Card Industry Data Security Standard) applies to any merchant that accepts card payments. The scope and complexity of your compliance obligations depend almost entirely on how card data flows through your systems. Merchants who use hosted payment forms (Shopify Payments, Stripe Checkout, PayPal hosted) can qualify for the simplest assessment (SAQ A, ~22 controls). Merchants who run custom payment pages face the most complex assessment (SAQ D, ~330 controls). The single most important PCI decision is: choose a payment method that minimizes your scope.
## When to Use This Skill
- When accepting credit card payments and need to determine your PCI compliance scope
- When selecting between SAQ A, SAQ A-EP, SAQ D, or other questionnaire types
- When implementing tokenization to reduce PCI scope
- When setting up logging, monitoring, and alerting infrastructure for PCI audit readiness
- When preparing for a QSA (Qualified Security Assessor) audit or completing an SAQ
## Core Instructions
### Step 1: Determine your PCI scope based on payment method
The most important decision in PCI compliance is how card data flows through your environment:
| Integration Method | SAQ Type | Approx. Controls | Who This Applies To |
|-------------------|----------|-----------------|---------------------|
| Fully hosted checkout (Shopify Payments, Stripe Checkout, PayPal hosted) | **SAQ A** | ~22 | Card data never touches your server; customer is redirected to the processor's payment page |
| JavaScript tokenization on your page (Stripe Elements, Braintree Drop-in) | **SAQ A-EP** | ~191 | Card data is entered in an iframe on your page; your server never sees raw card numbers |
| Your server touches card data | **SAQ D** | ~330 | Card data passes through your application server |
**Recommendation: Always choose SAQ A when possible.** Use Shopify Payments, Stripe Checkout, or a PayPal-hosted checkout. Moving from SAQ D to SAQ A reduces your annual compliance effort by ~85%.
### Step 2: Platform-specific PCI setup
---
#### Shopify
Shopify is a PCI-DSS Level 1 Service Provider. When you use Shopify Payments or any payment gateway through Shopify's checkout, Shopify handles PCI compliance for the payment processing environment.
**Your PCI scope as a Shopify merchant:**
- Using Shopify's hosted checkout and Shopify Payments: **SAQ A** — Shopify handles everything
- You are responsible only for: ensuring your Shopify admin access is secured (strong passwords, 2FA), not storing cardholder data in apps or spreadsheets, and vetting third-party apps for security
**Completing your SAQ A on Shopify:**
1. Download the SAQ A from the PCI Security Standards Council (pcisecuritystandards.org)
2. Shopify's merchant PCI compliance documentation is at help.shopify.com/en/manual/payments/pci-compliance
3. Shopify provides an Attestation of Compliance (AoC) for their platform — use this as evidence for your acquirer
**Key controls you still own:**
- Admin account security: 2FA for all Shopify staff accounts (Settings → Users → require 2FA)
- Not storing card numbers anywhere outside Shopify (no spreadsheets, no third-party databases)
- Vetting installed apps for data security practices
---
#### WooCommerce
WooCommerce itself is not PCI-compliant — compliance depends on your hosting, payment gateway, and implementation choices.
**Minimize scope: use a hosted payment gateway:**
Option A — **Stripe Checkout (hosted redirect)** → SAQ A
```php
// Use WooCommerce Stripe Gateway in "Stripe Checkout" mode
// In WooCommerce → Settings → Payments → Stripe → Stripe Checkout: enable
// Customer is redirected to stripe.com for payment; SAQ A applies
```
Option B — **Stripe Elements in WooCommerce** → SAQ A-EP
- The official WooCommerce Stripe plugin uses Stripe Elements by default
- Card data is captured in a Stripe iframe; your server receives only a payment token
- This is SAQ A-EP (more controls than SAQ A but far fewer than SAQ D)
**WooCommerce hosting requirements for SAQ A-EP:**
Your web hosting must meet minimum PCI requirements:
1. **SSL/TLS**: Ensure your hosting provider uses TLS 1.2+ and an up-to-date certificate
2. **Patching**: Keep WordPress, WooCommerce, plugins, and PHP up to date
3. **Managed hosting**: WP Engine, Nexcess, and Kinsta are PCI-aware managed hosts with relevant controls
4. **Wordfence**: Install Wordfence Security for malware scanning and WAF protection (Requirement 5, 6)
**What to verify for WooCommerce PCI:**
- No credit card numbers logged in WooCommerce order notes or custom fields
- WooCommerce debug logging does not capture payment data (disable debug logging in production)
- All admin accounts have strong, unique passwords and 2FA
- All plugins updated within 30 days of available security patches
---
#### BigCommerce
BigCommerce is a PCI-DSS Level 1 certified platform. Using BigCommerce's hosted checkout and supported payment gateways puts you in SAQ A territory.
**Completing compliance on BigCommerce:**
- BigCommerce provides an AoC for their platform infrastructure
- For merchants using BigCommerce Payments or a supported payment gateway through BigCommerce checkout: SAQ A applies
- For custom payment integrations or custom checkout pages: the scope increases; consult a QSA
**Key BigCommerce settings:**
1. Go to **Store Settings → Security** — ensure HTTPS is enforced on all pages
2. Go to **Account Settings → Users** — ensure all admin accounts have unique IDs and strong passwords
3. Enable 2FA for admin accounts under account security settings
4. Review installed apps — only grant apps the minimum permissions they need
---
#### Custom / Headless
For custom storefronts, your PCI scope is determined by how you integrate payment processing. Use Stripe Elements or Braintree Drop-in UI to stay in SAQ A-EP territory.
**SAQ A-EP implementation with Stripe Elements:**
```typescript
// Client-side: Stripe handles card data in an iframe — your code never sees card numbers
const stripe = await loadStripe(process.env.NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY!);
const elements = stripe.elements({ clientSecret });
const paymentElement = elements.create('payment');
paymentElement.mount('#payment-element');
// On submit — Stripe creates a PaymentMethod on their servers
const { error, paymentIntent } = await stripe.confirmPayment({
elements,
confirmParams: { return_url: `${window.location.origin}/order-confirmation` },
});
// Your server never receives a card number — only a paymentMethodId or paymentIntentId
```
**Key controls for SAQ A-EP (custom storefronts):**
```nginx
# Requirement 4: TLS 1.2+ only, strong cipher suites
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
```
**Content Security Policy for payment pages (Requirement 6.4.3 in PCI-DSS v4.0):**
```typescript
// Strict CSP on checkout pages — only authorized scripts allowed
const csp = [
`default-src 'self'`,
`script-src 'self' 'nonce-${nonce}' https://js.stripe.com`,
`frame-src https://js.stripe.com https://hooks.stripe.com`,
`connect-src 'self' https://api.stripe.com`,
`object-src 'none'`,
].join('; ');
response.headers.set('Content-Security-Policy', csp);
```
**Audit logging (Requirement 10):**
```typescript
// Log every authentication event, admin action, and access to payment data
interface AuditEntry {
timestamp: string;
userId: string;
userIp: string;
action: string;
resource: string;
outcome: 'success' | 'failure';
}
// Ship logs to an immutable store: CloudWatch Logs, Datadog, or S3 with Object Lock
// Requirement 10.7: Retain logs for 12 months; 3 months immediately available
```
**PCI-DSS controls checklist:**
| Requirement | Key Engineering Task |
|-------------|---------------------|
| Req 3: Protect stored data | No raw card numbers stored; use Stripe/BraRelated in security-compliance
financial-compliance-sox
IncludedImplement SOX-compliant financial controls for ecommerce with audit trails, segregation of duties, access controls, and compliance-ready transaction logging
secure-checkout
IncludedHarden your checkout against attacks with HTTPS enforcement, Content Security Policy headers, input sanitization, and card data tokenization
financial-audit-trail
IncludedBuild immutable audit trails for all financial transactions with user attribution, change logging, tamper detection, and compliance-ready export for external audits
bot-protection
IncludedBlock automated bots from scraping your catalog, scalping limited inventory, and abusing checkout flows using CAPTCHA and behavioral detection
gdpr-ecommerce
IncludedMake your store GDPR-compliant with cookie consent, customer data export on request, right-to-deletion workflows, and data processing agreements
data-retention-policies
IncludedAutomate the lifecycle of order and customer data — archive old records, anonymize personal data on request, and purge expired data on schedule