PCI DSS 4.0 is a few hundred pages long, and most of it isn't yours to implement - physical access controls to a data center, vendor management contracts, and network segmentation are someone else's job even at a small company. This is the version scoped to what a developer actually writes code for, stripped of audit terminology, mapped to concrete tasks instead of requirement numbers. For the requirement-by-requirement compliance view, see our PCI DSS web application requirements guide.

"We Use Stripe/PayPal, So This Doesn't Apply to Us" - Mostly True, Not Entirely

If your checkout redirects to Stripe Checkout or PayPal, or uses Stripe Elements/PayPal's hosted fields so card numbers never touch your server or even your own JavaScript, your PCI scope drops enormously - typically to SAQ A, the lightest self-assessment tier. But "we use a payment processor" and "our scope is zero" are not the same claim. The page that embeds the payment form, and every script that loads on it, is still in scope under PCI DSS 4.0's newer script-integrity requirements (6.4.3 and 11.6.1) - a compromised third-party analytics tag on your checkout page can skim card data via a fake overlay even when the real payment fields are hosted elsewhere.

Your Actual Task List

  1. Inventory every script that loads on any page touching payment. Analytics, chat widgets, A/B testing tools, ad pixels - each one is a potential injection point for a Magecart-style skimmer, and PCI DSS 4.0 now explicitly requires you to know what's there and be alerted when it changes. See our Requirement 11.6.1 guide for the specific script-monitoring mechanics.
  2. Never log raw card data, even accidentally. A card number typed into a form field that gets captured by a generic "log the request body" error handler, or a support tool that screenshots a customer's browser session, is a PCI violation regardless of how it happened. Explicitly redact card-shaped fields before anything touches a log file, error tracker, or session-replay tool.
  3. TLS 1.2 minimum, no exceptions on the payment path. Confirm this with an actual connection, not by reading a config file - a load balancer or CDN in front of your app can silently downgrade what you think is enforced end to end.
  4. Session timeout on any authenticated area tied to payment history. PCI DSS 4.0 requires idle session timeout (15 minutes for admin/back-office access to cardholder data environments); for customer-facing account pages showing payment history, a shorter idle timeout than your general session policy is a reasonable, defensible default.
  5. Dependency and component scanning, on a schedule, not just at launch. Requirement 6.3.2 expects you to maintain an inventory of software components and their known vulnerabilities on an ongoing basis - npm audit / composer audit in CI on every build, not a one-time check before your last audit.
  6. Multi-factor authentication for anyone with access to the cardholder data environment. This includes admin panels that can view (not just process) payment records, and any production database access - not just the checkout code path itself.
  7. A documented process for what happens when a dependency vulnerability is found. Not a folder of Dependabot emails - a real, written process: who triages it, what the patch SLA is by severity, and where that gets recorded. Auditors ask for the process, not just evidence that a patch eventually happened.

What You're Explicitly Not Responsible For (Usually)

Network firewall rule review, physical data center access logs, and vendor due diligence questionnaires are typically owned by infrastructure/IT or handled entirely by your cloud provider and payment processor's own compliance posture - worth confirming explicitly with whoever owns your PCI program rather than assuming, but not something a web application developer needs to personally implement.

The Part That's Genuinely Continuous, Not a One-Time Project

The most common real-world PCI gap isn't a missing control - it's a control that existed at the time of the last audit and quietly stopped being true afterward: a script added to the checkout page six months later without anyone updating the inventory, a dependency scan that was set up once and never wired into CI, a session timeout that got "temporarily" extended for a debugging session and never reverted. Requirement 11.6.1's continuous script monitoring and scheduled vulnerability scanning exist specifically because a point-in-time audit can't catch drift that happens afterward.

Building This Into Your Pipeline

Shieldome's e-commerce security scanner checks PCI-relevant headers, JavaScript supply chain integrity, and checkout page configuration on a schedule, with alerts when something changes - covering the "continuous," not "one-time," part of the task list above. See our full pricing for PCI-focused monitoring plans, or start a free trial to get your first baseline.