Fintech · PCI DSS
PCI DSS compliant software development for products that take card payments
We design and build payment features and fintech products so they meet PCI DSS 4.0 with the smallest possible scope: card data kept off your servers, secure development evidence your assessor can read, and the logging, change control and testing the standard asks for. We prepare you for your QSA; we are not one.
Short answer
PCI DSS compliant software development means keeping card data out of your own systems wherever possible and building the parts that remain in scope to the standard's twelve requirements, especially Requirement 6 on secure software. Innovation Insight builds payment features with hosted fields and tokenisation to keep you on SAQ A, and delivers the threat model, secure SDLC evidence and logging an assessor expects. Fintech MVPs cost $40k to $80k; discovery is $3k to $8k.
Reviewed by Zain Khalid Malik, CTO & Co-founder · Updated
What PCI DSS 4.0 requires of software
PCI DSS applies to every organisation that stores, processes or transmits cardholder data, and to any system that can affect the security of that data. Version 4.0 became the only active version in 2024 and 4.0.1 is the current revision; the requirements that were future-dated in 4.0 have been mandatory since 31 March 2025. The standard has twelve requirements grouped under six goals. For a product team, most of the day-to-day work sits in Requirement 6, with 3, 4, 8, 10 and 11 close behind.
| Goal | Requirements | What it means for a product team |
|---|---|---|
| Build and maintain a secure network and systems | 1. Network security controls; 2. Secure configurations | Segmented VPCs and security groups, no default credentials, hardened images, infrastructure as code |
| Protect account data | 3. Protect stored account data; 4. Protect data in transit | Do not store PANs at all if you can avoid it; where you must, render them unreadable; TLS 1.2 or higher everywhere; never log card data |
| Maintain a vulnerability management programme | 5. Protect against malicious software; 6. Develop and maintain secure systems and software | Dependency scanning, secure coding standards, code review, vulnerability fixes by severity, change control, and the payment page script controls in 6.4.3 |
| Implement strong access control | 7. Restrict access by business need; 8. Identify and authenticate users; 9. Restrict physical access | Least-privilege roles, MFA for every administrative and cardholder-environment login, no shared accounts, cloud provider physical controls |
| Regularly monitor and test | 10. Log and monitor access; 11. Test security regularly | Audit logs for every access to in-scope systems, time sync, alerting, quarterly vulnerability scans, annual penetration tests, and the payment page change detection in 11.6.1 |
| Maintain an information security policy | 12. Support security with policies and programmes | Written policies, risk analysis, third-party service provider management, incident response, training |
Three parts of Requirement 6 matter most to developers. Bespoke and custom software must be developed securely, with training, code review and secure coding against common weaknesses such as injection and broken access control. Vulnerabilities must be identified and fixed by severity, including those in third-party components. And public-facing web applications must be protected and their changes controlled. Two requirements added in 4.0 are easy to miss:
- Requirement 6.4.3: every script that runs on a payment page in the customer's browser must be authorised, its integrity assured (for example with Subresource Integrity or a Content Security Policy), and listed in an inventory with a written justification. Analytics tags and chat widgets on a checkout page count.
- Requirement 11.6.1: a change- and tamper-detection mechanism must alert on unauthorised changes to the HTTP headers and script contents of payment pages as received by the browser, evaluated at least weekly or at a frequency set by a documented risk analysis.
Scope reduction: hosted fields, tokenisation and the SAQ you end up with
The cheapest control in PCI DSS is not having card data. Which self-assessment questionnaire you qualify for depends on how the card number reaches the processor, and the difference between them is weeks of work versus months.
| Questionnaire | How card data flows | What the product team must do | Relative effort |
|---|---|---|---|
| SAQ A | Payment fully outsourced: the customer is redirected to the provider's page, or the provider's iframe or hosted fields render inside your page. Card data never touches your servers or your JavaScript. | Keep the integration as the provider documents it, manage and monitor scripts on the payment page (6.4.3 and 11.6.1), TLS, vendor management, policies | Lowest; a few dozen questions |
| SAQ A-EP | Payment processed by a provider, but your own page or JavaScript collects or can affect the card data, for example a form you built that posts directly to the provider's API. | Most of the standard applies to the web server and the page: hardening, logging, vulnerability scans, penetration testing, change control | High; well over a hundred questions |
| SAQ D | Card data is stored, processed or transmitted by your systems: your API receives PANs, you run your own vault, or you take cards by phone into your own software. | The full standard for every in-scope system, plus network segmentation to limit it | Highest; comparable to a full assessment |
Our default is SAQ A: hosted fields or checkout from Stripe, Adyen or Braintree, and a tokenisation vault such as Spreedly when several processors are needed. Service providers that handle card data for others, and merchants above the transaction thresholds set by the card brands, need a Report on Compliance from a QSA rather than a questionnaire. We design the same way for them, because a small scope makes that assessment cheaper too. The payment gateway integration page covers the integration details.
Architecture patterns that keep scope small
- Card data boundary: PANs are entered only into provider-hosted components. Your API handles tokens and the last four digits, which are out of scope.
- Separate payment service: the code that talks to the processor lives in its own service with its own secrets, network rules and logs, so the rest of the product is not in scope.
- Payment page hygiene: a strict Content Security Policy, Subresource Integrity on third-party scripts, a script inventory in version control and a monitor that fetches the page and compares headers and scripts to the approved baseline.
- Secrets in a vault: processor keys and webhook secrets in AWS Secrets Manager, Azure Key Vault or similar, rotated and never in code or CI logs.
- Logging without card data: structured logs with request IDs, redaction of card and personal fields at the logging layer, and retention set in policy.
- Phone and in-person payments: DTMF capture or PCI-validated P2PE terminals, so agents and voice systems never hear or store the number.
- Segmentation: the in-scope service in its own subnet and account, with access by MFA and audited sessions.
What we deliver
| Deliverable | What it covers | Requirement |
|---|---|---|
| Data-flow diagram and scope statement | Where card data enters, which systems touch it, which SAQ applies and why | Scoping; 12.5 |
| Threat model | Attack paths against the payment flow, scripts, webhooks and admin tools, with mitigations | 6.2, 6.4 |
| Secure SDLC evidence | Coding standard, code review records, dependency and SAST scanning in CI, developer training log, change tickets linked to releases | 6.2, 6.3, 6.5 |
| Payment page controls | CSP, SRI, script inventory with justifications, change and tamper detection with alerts | 6.4.3, 11.6.1 |
| Access and authentication | Role model, MFA on admin and cloud consoles, unique accounts, session rules | 7, 8 |
| Logging and monitoring | Audit logs for in-scope systems, time sync, alert rules, retention | 10 |
| Testing coordination | Quarterly ASV scans arranged, penetration test scoped with a third party and findings fixed | 11.3, 11.4 |
| Policy templates | Information security, change management, incident response and vendor management policies adapted to your product | 12 |
| Assessor pack | Everything above organised against the SAQ or ROC, with gaps listed and owners named | Attestation |
What we do not do
We are not a Qualified Security Assessor and do not issue attestations. We do not run Approved Scanning Vendor scans ourselves; we arrange them with an ASV and fix what they find. We do not decide which SAQ you must file; your acquirer or the card brands do, and we help you make the case. What we do is build the product so the answer is SAQ A wherever possible, produce the evidence, and sit in the room when the assessor asks how the payment page is protected.
What PCI compliant app development costs
| Engagement | Price | What you get | Timeline |
|---|---|---|---|
| Discovery and scoping | $3k to $8k | Data-flow diagram, SAQ determination, threat model, architecture, backlog and estimate | 1 to 2 weeks |
| Fintech MVP | $40k to $80k | A payments product with hosted fields, tokenisation, webhooks, reconciliation, the controls above and an assessor pack | 4 to 6 months |
| Fintech platform | $80k to $180k | Wallets, payouts, lending or multi-processor routing, a separate payment service, segmentation, pen-test cycle | 6 to 12 months |
| Dedicated engineer | From $4,000 a month | A senior engineer embedded with your team to bring an existing product into scope | Ongoing |
QSA assessments, ASV scans and penetration tests are paid to those providers and are not included; we scope them so you are not paying to test systems that should be out of scope. The fintech app development cost guide and the cost to build a payment app like Cash App show how the figures break down, and pricing lists every published rate.
Timeline
- Weeks 1 to 2: discovery, data-flow diagram, SAQ determination and threat model.
- Weeks 3 to 8: payment service, hosted fields or tokenisation, webhooks and reconciliation, with CI scanning and code review from the first commit.
- Weeks 9 to 12: payment page controls, logging, access model, secrets, policies.
- Weeks 13 to 16: penetration test, ASV scan, fixes, assessor pack and SAQ walkthrough.
- After launch: quarterly scans, dependency updates and annual re-attestation on a support retainer.
Payment work we have shipped
- Zeuss: a telehealth storefront and CRM on Azure where card tokenisation runs through Spreedly, so the platform's 20-plus microservices never handle a card number, alongside Key Vault secrets, a complete HTTP audit trail and PII masking in API responses.
- Paint Nite: checkout rebuilt as a six-stage pipeline with idempotent Stripe payments and separate Stripe accounts, keys and webhook secrets for the US and Canada.
- TamTracker: Stripe Connect billing for an agency portal on serverless AWS, with organisation-scoped multi-tenancy and audited access.
Our security page describes the practices we apply to every project, and if your product also handles health data, see HIPAA compliant software development for how the two frameworks overlap. The wider fintech app development page covers KYC, ledgers and open banking.
Sources and further reading
Next step
Tell us what you're building and get a written estimate.
A senior engineer replies within one business day. NDA on request.
Products we've shipped, and what happened next.
Case studies written from the technical documentation of each project: the stack, the scale and the outcome.
Questions we get asked a lot.
Is PCI DSS compliance required for a small app that takes card payments?
Yes. PCI DSS applies to every merchant regardless of size. Small merchants validate with a self-assessment questionnaire; the smallest, SAQ A, applies when card data is fully outsourced to hosted fields or a redirect and your payment page scripts are controlled.
What is the difference between SAQ A and SAQ A-EP?
SAQ A applies when the provider's hosted page, iframe or hosted fields collect the card data and your code cannot touch it. SAQ A-EP applies when your own page or JavaScript collects the card details and sends them to the provider, which puts your web server in scope for most of the standard.
What does PCI DSS Requirement 6 ask of developers?
Secure development of bespoke software, with developer training and code review. Vulnerabilities are identified and fixed by severity, including in third-party components. Public-facing web applications are protected and changes are controlled. Since 2025 every script on a payment page must be authorised, integrity-checked and inventoried (6.4.3).
Do you provide the PCI certificate?
No. Attestations come from your own self-assessment or from a Qualified Security Assessor. We build the product to the standard, produce the evidence and support you through the assessment.
Can we store card numbers for repeat payments?
Store a token from your processor instead. Tokens and the last four digits are out of scope. Storing PANs yourself moves you to SAQ D or a full assessment and is almost never worth it.
How much does PCI compliant software development cost?
Discovery is $3k to $8k. A fintech MVP built to PCI DSS with an assessor pack costs $40k to $80k, a larger platform $80k to $180k, and a dedicated engineer from $4,000 a month. Assessor, scanning and penetration testing fees are paid to those providers.