The article
Your team is about to add card payments to an app or a site. Before anyone writes the checkout, one decision settles most of the PCI work: where the buyer types the card number, and whose servers that number passes through. Choose well, and the standard shrinks to a short questionnaire. Choose badly, and every server, log and backup the number touches is in scope.
I have been building software for 18 years, and PCI compliance for software developers mostly comes down to that decision, made early, plus a few habits in the code. Below is how my team designs payment flows, what changed in the rules in 2025, what your bank or your assessor will ask to see, and which parts stay with you.
PCI compliance for software developers: the short version
| Question | Answer |
|---|---|
| Who has to comply | The business that accepts the cards, and any service provider that handles card data for it |
| Who decides how you prove it | Your acquirer, the bank that processes your card payments, or the payment brand |
| The cheapest way to comply | Card numbers never reach your servers: the provider's payment page or hosted fields, then tokens |
| What we do | Design and build the payment flow, secure what remains in scope, prepare the answers and the evidence |
| What we do not do | Assess you, scan you or sign for you |
| Price | Estimated before work starts; the first call and the rough estimate are free |
Who answers for PCI DSS, and where the developer fits
PCI DSS binds the business that accepts the cards, so the developer who builds its checkout files nothing. The code, however, decides how much that business has to prove. Every system that stores, processes or transmits card numbers is in scope, and so is the web page that controls how a card gets collected.
The payment brands decide whether a small merchant validates at all. Which self-assessment questionnaire, or SAQ, fits is confirmed by your acquirer or the payment brand, not by the developer and not by the council that writes the standard. Ask before you choose the integration, with a diagram of the card's path in hand.
Two cases sit outside this page. If you sell payment software to other businesses, the council's standards for the product itself are the Secure Software Standard and the Secure Software Lifecycle Standard, which replaced PA-DSS when it was retired on 28 October 2022. If your platform handles card data for other businesses, ask your acquirer whether you count as a service provider: the only questionnaire open to a service provider is SAQ D for Service Providers.
Where the card number goes decides your scope
This is the table I would walk you through on a first call; send it to whoever builds your checkout. Your acquirer has the last word, and every eligibility criterion of an SAQ has to fit, not most of them.
| How your page takes the card | Where the number goes | What stays in scope for you | The SAQ that may fit |
|---|---|---|---|
| A redirect to the provider's payment page | To the provider, never through your page or servers | The pages that send buyers there, scanned from outside by an Approved Scanning Vendor | SAQ A |
| The provider's form embedded in an iframe (hosted fields) | Into the provider's frame; your servers get a token | Your page, protected from script attacks, and the same external scans | SAQ A, with the script condition added in 2025 |
| Your own form that posts the card from the browser straight to the provider | To the provider, but from a page your server builds | Your web server and everything that can change the page | SAQ A-EP |
| Your API receives the card number | Through your servers, logs, queues and backups | Most of PCI DSS, on every system the number touches | A longer questionnaire or an assessor's report |
We build payment flows on the first two rows. The last two need a reason worth the extra scope, such as a payment provider that offers no hosted fields.
The first row is not free of risk either. An attacker who changes your page can send buyers to a fake payment page, which is why SAQ A, since version 4 of the standard, asks for outside scans of your web pages even when the payment itself is fully outsourced.
What changed on 31 March 2025: the page around the form
Since 31 March 2025, two requirements of version 4.0.1 are in force, and both are about the page that hosts the payment form:
- Requirement 6.4.3. Every script on the payment page is authorized, its integrity is assured, and it sits on a list with a written reason why it is needed.
- Requirement 11.6.1. A change- and tamper-detection mechanism alerts your people to unauthorized changes to the security-impacting HTTP headers and the script contents of the payment page, as the buyer's browser receives them.
Both target e-skimming: a script slipped into a checkout that copies what the buyer types. In January 2025 the PCI Security Standards Council published a revised SAQ A without the two requirements and with an eligibility condition instead: a merchant whose page embeds the provider's form confirms that its site is protected from script attacks that could reach its e-commerce system.
The council's FAQ 1588 names two ways to confirm it. You protect the page with techniques like those of requirement 11.6.1 and of 6.4.3, yourself or through a third party. Or your payment provider, itself validated under the standard, confirms in writing that its embedded form, set up by its instructions, protects your page. A full redirect is outside this condition.
What the payment page rules mean in code
- The checkout page loads only the scripts it needs: no chat widget, heatmap or tag manager next to the payment form.
- A Content Security Policy names every source the page may load scripts from.
- Files loaded from other servers are pinned with Subresource Integrity, so a file changed at its source does not run.
- A change to the payment page goes through code review like any other release.
In October 2026 I read five developer guides from Google's first page for "PCI compliance for software developers". None of them mentions requirements 6.4.3 or 11.6.1, the payment page or the iframe a hosted payment form lives in, and only one mentions tokens. Five pages are a small sample, but if your developer learned PCI from guides like these, ask about the payment page.
No card data where it does not belong
Card numbers leak into places nobody designed for them. The usual ones:
- request logs and error reports that save the whole request body, card fields included;
- support emails and chats, where a buyer types the card number to be helpful;
- analytics and session recordings that capture what is typed into forms;
- database copies and backups moved to test servers.
A quick check you can run on any system: put a test card from your provider's sandbox through the flow, then search the logs, error reports, mailboxes and backups for its number. It should not be anywhere.
One rule surprises product teams: the card's security code may not be kept after the payment is authorized, not even encrypted and not even for subscriptions. Repeat charges run on the provider's tokens.
PCI compliance in software development: access, code and tests
The rest of the scope is ordinary security work, done on purpose and written down:
- Access. Who can reach the payment systems is limited and logged: the provider's dashboard, the API keys, the webhook settings. Secret keys live in a secret store, never in the code; in your cloud that is part of our cloud security work.
- Code. Every change is reviewed before it ships, and libraries are kept updated.
- Webhooks. A message from the provider is checked against its signature before the code trusts it.
- Scans and tests. Outside scans under requirement 11.3.2, run by an Approved Scanning Vendor, and penetration tests where your SAQ asks for them. The scans must come from a vendor on the council's list; penetration tests we run as a separate service.
Ready for your SAQ or your QSA
Smaller merchants usually fill in an SAQ themselves; larger ones are assessed on site by a QSA, a Qualified Security Assessor. We prepare the answers and the evidence for either, and they are made of the same pieces:
- a diagram of the card's path, from the buyer's screen to the provider;
- the list of systems in scope, and why the rest is out;
- the script list of the payment page, with a reason for each script;
- the reports of your Approved Scanning Vendor;
- access lists, review records and the change history of the payment code;
- your payment provider's proof of its own PCI DSS compliance.
What we do not do: we are not a QSA or an Approved Scanning Vendor, and we do not sign. The assessor assesses, the vendor scans, and the attestation carries your company's name.
Our work: apps that move money
Two apps on our case pages take payments. Tarot Fans is a marketplace app for tarot readings: clients top up a wallet and pay per minute for live sessions, calls and chat, and experts earn and withdraw. The hard part was money moving in both directions; the wallet keeps every balance and transaction straight, with Stripe underneath, and the app is live on Google Play.
Mutualz is a city app for restaurants in Germany: diners order and pay from the phone at the table and collect points that bring them back. The hard part was losing nothing on the way, so orders, points and activity are tracked end to end between the app, the restaurant and the backend. It is live on the App Store and Google Play in German and English.
Both are mobile apps; a payment flow inside a web product is part of web application development.
What the price depends on
PCI work has no starting price, because one question, how do you take cards today, has very different answers. The estimate depends on:
- where card numbers go now; if they already reach your servers, the first job is moving them out and cleaning logs, tables and backups;
- how many channels take cards: a site, an app, phone orders;
- your payment provider and the integrations it offers;
- how much of the evidence exists already;
- whether you file a questionnaire or a QSA assesses you.
The first call and the rough estimate are free. If you need an NDA, we sign it before you share any details.
What stays with you
The answers, the diagrams and the evidence are prepared for your questionnaire and your assessor, so they stay with you. Every access and service we touch is documented, so when people change, there is a clear list of what to revoke. The decisions stay with you as well: which provider, which questionnaire and who signs.
Around the card rules
PCI DSS is one of the rules in our regulatory compliance services. The cloud side of card data is in cloud compliance, and banks, lenders and fintech companies start from financial compliance.
Tell us how you take payments today: the provider, the channels and where the buyer types the card number. We answer new requests within 30 minutes on weekdays, 9 am to 6 pm Miami time, and the rough estimate of how we would shrink your scope is free.
