PCI DSS Engineering for Payment Software
The checkout looked simple until the assessor asked which scripts run on the payment page and who approved each one. Agnotic Technologies designs and builds payment features that keep card data out of your systems where possible, and produces the evidence your PCI DSS assessment will ask for.
Trusted by global innovators
What does PCI DSS ask of teams that build payment software?
PCI DSS asks teams that build payment software to protect cardholder data wherever their code stores, processes or transmits it, or could affect its security. Agnotic Technologies designs checkout so card data stays with the payment provider where possible, builds secure development practices into delivery and keeps the evidence an assessor will request.
Decision table
Which checkout design keeps your PCI scope smallest?
The way card details enter your checkout decides most of your scope. These are the likely outcomes for common e-commerce designs. Your acquirer or payment brand confirms which SAQ applies to you.
| Checkout design | Likely SAQ | What stays in scope | Engineering controls we build |
|---|---|---|---|
| Redirect to the provider's hosted payment page | SAQ A | The page that sends the customer to the provider, and the integrity of that redirect | Redirect target protected from tampering, change control on the page, provider return messages validated |
| Provider's payment form embedded in an iframe | SAQ A, with the script attack criterion | The parent page and every script on it | Script inventory and authorization, change and tamper detection, or written confirmation from the provider that its form protects against script attacks |
| Your page uses the provider's JavaScript to post card data directly to the provider | SAQ A-EP | The web servers and code that serve the payment page | Secure development, code review, vulnerability management and payment page script controls on your own pages |
| Card data passes through your servers or API | SAQ D, or a full assessment | Every system that touches card data, and the network around it | Tokenize at the first point, encrypt in transit, segment the network, minimize storage and log every access |
Most products we build use a redirect or an embedded provider form, so card numbers never reach the client's servers.
What does Requirement 6 ask of your development process?
Requirement 6 covers how secure systems and software are developed and maintained. These are the engineering practices it touches, and how we run each one on payment features.
Secure development
Bespoke and custom software is built to written secure coding practices, with common attacks such as injection and broken authentication designed against.
Code review before release
Changes to payment code are reviewed by someone other than the author before they ship, and the review is recorded on the pull request.
Vulnerabilities and components
An inventory of custom code and third-party libraries, dependency and vulnerability scans in the pipeline, and fixes ranked by risk.
Public-facing web applications
Payment pages and APIs exposed to the internet are protected against attacks, through testing and automated protection in front of them.
Payment page scripts (6.4.3)
Every script on a payment page is listed, authorized, justified and checked for integrity, using techniques such as Content Security Policy and subresource integrity.
Change and tamper detection (11.6.1)
A mechanism alerts the team when scripts or security-relevant HTTP headers on the payment page change as a customer's browser sees them.
App gallery
View AllLera Health
Health evolve
How does Agnotic keep card data off your servers?
Four steps, from the first data flow to the evidence pack.
Map card data flows
We trace where card details enter, which systems see them and where tokens go, so scope is decided by design rather than discovered at assessment.
Choose the checkout pattern
Redirect, embedded form or direct API, chosen with you and your payment provider against the decision table above.
Build the controls
Tokenization, script inventory, Content Security Policy, tamper detection, code review and scanning in the pipeline.
Prepare the evidence
Data flow diagrams, script authorizations, review records and scan results, organised for your assessor or self-assessment.
Which PCI SSC sources shape this work?
Short facts from the PCI Security Standards Council, each linked to its source.
PCI DSS sets a baseline of technical and operational requirements to protect payment account data, and applies to entities that store, process or transmit cardholder data or sensitive authentication data, or could affect the security of the cardholder data environment.
Source: PCI Security Standards Council, PCI DSSQualified Security Assessors are independent security organizations qualified and trained by the PCI Security Standards Council to perform PCI DSS assessments.
Source: PCI Security Standards Council, PCI DSSPCI DSS v4.x added 64 new requirements, 51 of them future-dated as best practices until 31 March 2025, when they became required. They include Requirements 6.4.3 and 11.6.1 for e-commerce payment pages.
Source: PCI SSC, Coffee with the Council: e-commerce requirements effective after 31 March 2025Requirements 6.4.3 and 11.6.1 focus on making sure payment page scripts are properly authorized, checked for integrity and monitored for tampering, and on managing scripts and security-impacting HTTP headers to prevent unauthorized changes to payment pages.
Source: PCI SSC, Information Supplement: Payment Page Security and Preventing E-SkimmingSAQ A for PCI DSS v4.0.1 requires the merchant to confirm its site is not susceptible to script attacks. That criterion applies to pages that embed a payment provider's form, such as an iframe, not to pages that redirect to the provider.
Source: PCI SSC, FAQ clarifies new SAQ A eligibility criteria
PCI DSS engineering FAQs
Build compliantly