PCI DSS Compliance for Engineers

By Kokil Thapa | Last reviewed: September 2026

If your application touches card payments, PCI DSS compliance for engineers is not a security-team handoff. It is architecture, code, infrastructure, and evidence. A checkout that stores a PAN in a log table, a misconfigured TLS cipher suite, or a cron job that emails receipts with full card numbers can expand scope and fail an audit. This guide maps what working developers must implement, test, and document—grounded in production eCommerce and payment integrations I have shipped with Laravel, WooCommerce, and hosted payment fields.

What is PCI DSS and why must engineers own part of it?

PCI DSS (Payment Card Industry Data Security Standard) is a set of twelve requirement areas published by the PCI Security Standards Council. Merchants and service providers that store, process, or transmit cardholder data must comply. Engineers do not sign the Attestation of Compliance, but auditors trace failures to application design.

Requirement 3 covers stored data. Requirement 4 covers encryption in transit. Requirements 7, 8, and 10 cover access and logging. Your choices in routing, database schema, and third-party SDKs decide whether the business qualifies for a lighter Self-Assessment Questionnaire (SAQ) or a full onsite audit.

On a real client project integrating Khalti, eSewa, or Stripe, the engineering goal is the same: minimize what enters your Cardholder Data Environment (CDE). Many Nepal-facing stores never touch raw card numbers because wallets and bank redirects handle authentication. That is valid scope reduction—not a loophole, if your code and logs prove it.

For background on developer-facing obligations, see our companion piece on PCI DSS essentials for developers. Cryptographic details sit in cryptography requirements in PCI DSS and HIPAA.

How do you define and reduce PCI DSS scope in your application?

Scope is every system component that stores, processes, or transmits cardholder data—or can affect its security. A common mistake is treating "we use Stripe" as automatic out-of-scope status while logging request bodies that contain PANs.

Map data flows before writing checkout code

Draw four paths: browser to your app, your app to the gateway, gateway callbacks, and back-office exports. Label each hop with data elements: Primary Account Number (PAN), cardholder name, expiration, CVV, track data. CVV, full track contents, and PIN blocks must never be stored after authorization—even encrypted storage is forbidden under PCI DSS.

Prefer hosted fields and redirect flows

Stripe Checkout, PayPal Smart Buttons, and many regional gateways offer hosted pages or JavaScript that posts card data directly to the PSP. Your Laravel controller receives a token or payment intent ID—not a PAN. That pattern often supports SAQ A or SAQ A-EP instead of SAQ D.

On production Laravel carts like Quick And Easy Nepalese Grocery, wallet-first checkout reduced card exposure entirely for local buyers. International card checkout used tokenized references only.

Segment networks and accounts

Even with tokenization, production servers that call payment APIs usually sit in scope. Put them on restricted subnets. Block outbound traffic except to known PSP endpoints. Separate production DB credentials from staging. Staging must not use live keys or real PANs—use vendor test cards only.

Official SAQ eligibility rules live on the PCI Security Standards Council document library. Read the SAQ instructions for your exact flow before promising leadership a "simple checkbox."

What technical controls does PCI DSS require from engineering teams?

Auditors translate the twelve requirements into concrete configs and code paths. Below are the controls I verify first on payment-enabled deployments.

Protect stored cardholder data (Requirement 3)

If you must store PAN, render it unreadable: truncate display (show last four only), tokenize at the gateway, or encrypt with strong cryptography and documented key management. Never store sensitive authentication data after authorization. Hashing PAN for lookup without salt is weak; use a dedicated token from the PSP instead.

// Laravel: safe order record — token only, never PAN/CVV
Schema::create('payments', function (Blueprint $table) {
    $table->id();
    $table->foreignId('order_id')->constrained();
    $table->string('gateway')->index();
    $table->string('gateway_payment_id')->unique();
    $table->string('card_last_four', 4)->nullable();
    $table->string('card_brand', 20)->nullable();
    $table->unsignedInteger('amount_cents');
    $table->string('currency', 3)->default('NPR');
    $table->string('status', 32)->index();
    $table->timestamps();
    // No column for pan, cvv, track, or pin
});

Encrypt transmission (Requirement 4)

Use TLS 1.2 or higher everywhere cardholder data crosses public networks. Disable weak ciphers on load balancers and origin web servers. HSTS with includeSubDomains reduces downgrade risk. For internal service mesh traffic that carries tokens, encrypt east-west links or keep tokens off internal buses entirely.

I've encountered production deployments where Apache still negotiated TLS 1.0 for legacy clients. Payment pages need modern cipher suites only. Our Linux system administration work often starts with an SSL Labs scan and a tightened vhost.

Restrict access and authenticate strongly (Requirements 7–8)

Apply least privilege to databases, admin panels, and CI secrets. Multi-factor authentication is required for all access into the CDE for personnel with non-console access. Break-glass accounts need extra logging and quarterly review.

• Separate DB roles: app user cannot ALTER TABLE; migration user not used at runtime.
• Admin routes behind MFA and IP allowlists where practical.
• No shared SSH keys across production and developer laptops.
• Rotate API keys on a schedule; revoke on staff departure the same day.

Log, monitor, and retain evidence (Requirement 10)

Log authentication events, privileged actions, and access to cardholder data. Sync time with NTP. Protect logs from tampering—append-only storage or SIEM forwarding. Retention must meet your policy and local law; PCI expects at least one year online with three months immediately available.

# Nginx log format — avoid logging request bodies on payment routes
location /checkout/ {
    access_log /var/log/nginx/checkout.access.log combined;
    proxy_pass http://php-fpm;
    client_max_body_size 64k;
}

# Strip or redact Authorization headers in upstream logs
log_format pci_safe '$remote_addr - $request_method $uri $status';

Pair logging guidance with API rate limiting and abuse prevention so brute-force attacks on payment endpoints generate alerts, not silent failures.

How do you implement PCI DSS compliance in Laravel and eCommerce stacks?

Framework choice does not exempt you. Laravel 13 on PHP 8.3+, WooCommerce 11.1 on WordPress 7.1, and custom carts all need the same data discipline. Implementation details differ.

Laravel payment integration checklist

1. Load PSP keys from .env; never commit secrets. Use strong random secrets for webhooks.
2. Validate webhooks with signed payloads; reject replayed events via idempotency keys.
3. Queue receipt emails without card numbers—order ID and last four only.
4. Disable APP_DEBUG in production; exceptions must not dump request input.
5. Run composer audit (Composer 2.10) in CI; block deploy on known CVEs in payment libraries.
6. Store uploaded invoices in private disks; scan with AV if staff upload payment proofs.

// Webhook handler — verify signature, idempotent update
public function handle(Request $request, PaymentGateway $gateway)
{
    $payload = $request->getContent();
    if (! $gateway->verifyWebhookSignature($payload, $request->header('Signature'))) {
        abort(401);
    }

    $event = $gateway->parseEvent($payload);

    Payment::where('gateway_payment_id', $event->id)
        ->whereNull('captured_at')
        ->update(['status' => $event->status, 'captured_at' => now()]);
}

For broader Nepal regulatory context—VAT, consumer rules, local gateways—read eCommerce legal compliance in Nepal. PCI sits alongside those obligations; it does not replace them.

WooCommerce and WordPress hardening

WooCommerce sites often fail PCI reviews on plugin sprawl and weak admin passwords. Keep payment plugins official and updated. Remove file editors. Block xmlrpc.php if unused. Use a Web Application Firewall rule set tuned for checkout paths.

Compare with WordPress GDPR compliance checklist—privacy and PCI overlap on retention and breach notification, but PCI adds stricter prohibitions on sensitive auth data.

APIs and mobile clients

Mobile apps must not embed secret keys. All card capture goes through PSP SDKs. Your REST API exposes order status and tokens—not decryption keys. Rate-limit token endpoints. Document PCI scope in your OpenAPI description so partners know what they must not send.

Cryptography you can defend in an audit

Requirement 3 expects industry-standard algorithms and key management. Use AES-256 for data at rest only when tokenization is impossible. Protect keys in HSMs or cloud KMS—not in Git. Rotate keys on compromise and on schedule.

Our cryptography fundamentals for engineers article explains block modes and IV misuse. Pair it with compliance as code so Terraform and CI pipelines enforce encryption flags before merge.

How do you maintain PCI DSS compliance after go-live?

Compliance is quarterly and continuous—not a launch-week checklist. ASV vulnerability scans run every ninety days on external-facing CDE IPs. Penetration testing is required annually for many merchants. Change management must document every production deploy that touches checkout.

Automate evidence in CI/CD

GitLab CI pipelines I maintain for legal-tech and eCommerce sister sites run lint, dependency audit, and deploy through Deployer 7. Add jobs that fail builds when:

• composer audit or npm audit (npm 12) reports critical issues in payment paths.
• TLS scan configs drift below PCI-approved cipher lists.
• Secrets scanners find high-entropy strings in diffs.

See automate SOC 2 compliance evidence in CI for reusable patterns. SOC 2 and PCI differ, but evidence collection mechanics overlap.

Incident response and breach rules

Requirement 12 expects a written incident response plan. Engineers need runbooks: isolate affected systems, preserve logs, notify the payment brands within required timeframes, and rotate keys. Do not wipe disks before forensic copies exist.

For data location questions—hosting in Singapore vs Mumbai vs US regions—data residency and compliance for Nepali companies covers practical constraints. PCI does not mandate a country, but cross-border transfers must match your privacy policy and contract terms.

Vendor and shared responsibility

Cloud providers offer PCI-attested infrastructure; you still own application config. Request AoC or responsibility matrix from hosting, PSP, and SMS providers. A cheap shared host without isolated tenants can invalidate segmentation claims.

Our hosting and domain services and support and maintenance engagements include patch cadence documentation auditors expect.

Compare frameworks in ISO 27001 basics for engineers if your org pursues dual certification. ISO covers broader ISMS; PCI is prescriptive on card data. Map controls once; collect evidence twice.

Testing and QA gates

Before each release touching payments, run scripted tests: successful charge, declined card, webhook retry, refund, partial capture if supported. Use PSP test PANs—never production cards in staging. Our testing and optimization service adds regression suites auditors appreciate because they show change control in action.

Validate that error pages and JSON responses never echo submitted card fields. Use Base64 tools only on non-production sample data when debugging encoding—not live PANs.

Key Takeaways

• Draw your CDE boundary first; keep PAN, CVV, and track data off your servers via hosted checkout or tokenization.
• Never store sensitive authentication data after authorization—no exceptions, no encrypted columns.
• Enforce TLS 1.2+, MFA on CDE access, least-privilege DB roles, and tamper-evident logging on payment paths.
• Automate dependency scanning and config checks in CI so compliance evidence is continuous, not quarterly panic.
• Match your SAQ type to the real data flow; read official PCI SSC guidance before signing attestations.
• Treat PCI as part of shipping payments—same priority as uptime, backups, and custom software delivery.

People Also Ask

Does using Stripe or PayPal mean we are automatically PCI compliant?

No. Using a major PSP reduces scope when card data never touches your systems, but you must still secure your site, admin access, and integrations. Misconfigured webhooks, logged PANs, or compromised WordPress plugins can fail PCI requirements and enable fraud regardless of PSP choice.

Can engineers store encrypted CVV for recurring billing?

No. PCI DSS forbids storing sensitive authentication data—including CVV/CVC, full track contents, and PIN blocks—after authorization, even if encrypted. Recurring charges use tokens or network tokens from the payment gateway, not retained CVV values.

What is the difference between SAQ A and SAQ D?

SAQ A applies when all cardholder data functions are fully outsourced to PCI-validated third parties and your site only redirects or embeds their checkout. SAQ D is the full questionnaire for merchants with broad in-scope systems or direct card handling—far heavier for engineering and operations teams.

How often must vulnerability scans run for PCI DSS?

External ASV scans are required at least quarterly and after significant network changes. Internal vulnerability scanning and annual penetration testing apply to many Level 1 and Level 2 merchants. Engineering must remediate critical findings within the deadlines your acquirer sets.

Ship payments without expanding your audit surface

PCI DSS compliance for engineers boils down to disciplined data handling, hardened infrastructure, and provable controls in every deploy. Scope reduction beats heroic encryption. Tokenized checkout beats custom card forms. Automated scans beat spreadsheet promises.

If you are launching or refactoring a payment flow—Laravel cart, WooCommerce store, or client portal with card-on-file—map your data flows before the next sprint. I have integrated Stripe, PayPal, and Nepal gateways on production systems since 2010 and can help you design a CDE that passes QSA review without overbuilding.

Review payment-enabled work in our portfolio, read more on the blog, or contact us to discuss architecture review, remediation, and ongoing eCommerce development with PCI-aware engineering from day one.