PCI DSS for software teams
What PCI DSS asks of any system that touches card data, how to keep that system as small as possible, and the controls inside it.
What PCI DSS is
Payment Card Industry Data Security Standard, v4.0.1
PCI DSS is the security standard for card payments. It is run by the PCI Security Standards Council, which the major card brands founded. It is not a law. It is enforced through contracts: card brands and acquiring banks require it of merchants and service providers.
It protects account data. That is cardholder data (the card number, or PAN, plus name, expiry date and service code) and sensitive authentication data (full magnetic stripe or chip data, the card security code and PINs).
The systems that store, process or send account data, and anything connected to them, form the cardholder data environment (CDE). The standard applies to the CDE, so the most useful design decision is usually to make the CDE as small as possible.
Who it applies to
Merchants
Any business that accepts card payments, online or in person. Small merchants often self-assess with a Self-Assessment Questionnaire (SAQ).
Service providers
Payment gateways, processors, hosting providers and software vendors that store, process or send card data for others, or could affect its security.
Validation by level
How you prove compliance depends on card brand rules and transaction volume: an SAQ, or a Report on Compliance from a Qualified Security Assessor (QSA).
Using a payment provider does not take you out of PCI DSS, but it can shrink your part to a short questionnaire. If card data never touches your servers, because the provider hosts the payment fields or page, your scope is far smaller than if your servers ever see a card number.
Key requirements, and what they mean for the build
Each row links the official text. Read the source for the exact wording before you rely on it.
Network security and secure configuration
Network security controls around the CDE, and no vendor defaults or unneeded services on its systems.
Segment the CDE from everything else, and build its servers from hardened, reviewed images.
Protect stored account data
Keep as little as possible. Never store sensitive authentication data after authorisation. Mask the PAN on screen, and make it unreadable wherever it is stored.
Store a provider token instead of the PAN. If you must show a card, show no more than the BIN and the last four digits.
Encrypt in transit
Strong cryptography whenever card data travels over open, public networks.
TLS on every hop that carries card data, with weak protocols and ciphers turned off.
Malware protection and secure software
Protect systems from malware, build software securely, fix vulnerabilities, and control scripts on payment pages.
Secure code review, dependency patching, and an inventory of every script on the payment page with a reason it is there.
Access by need to know, strong authentication
Limit access to the CDE to those who need it, give everyone a unique ID, and use MFA for all access into the CDE.
Role-based access, no shared accounts, MFA on every route into the CDE, and service accounts that are reviewed.
Physical access
Restrict physical access to card data and to devices that capture it.
Mostly your hosting provider's job. For in-person payments, track and inspect card terminals.
Log and monitor
Log all access to system components and card data, review the logs, and keep them.
Central, tamper-resistant logs for the CDE, with automated review and alerts, and no card numbers inside the logs themselves.
Test security regularly
Vulnerability scans, penetration tests, and change and tamper detection on payment pages.
Quarterly external scans by an approved scanning vendor, a yearly penetration test, and monitoring that alerts when a payment page changes.
Policies and programme
Security policies, risk analysis, staff awareness, service provider management and a documented, yearly-confirmed scope.
Write down what is in scope and why, and update it when the architecture changes.
Engineering controls for PCI DSS
How the rules change the way the software is designed.
- 01
Keep card data off your servers
Use the payment provider's hosted fields, page or SDK so the card number goes straight to them. This is the biggest scope reduction there is.
- 02
Tokens, not card numbers
Store the provider's token and the last four digits for display. Refunds and repeat charges work from the token.
- 03
Segmentation
If you do handle card data, keep it in a separate network segment and account, with tight rules on what can reach it.
- 04
Scrub logs and errors
Filter card numbers out of logs, error reports and analytics before they are written, and test the filter.
- 05
Payment page script control
A Content Security Policy, an approved list of scripts and alerts when the page changes, to stop card skimming.
- 06
MFA into the CDE
Every person and admin path into the CDE goes through MFA, with no shared accounts.
- 07
Key management
Encryption keys in a managed key service or HSM, with rotation and split access.
- 08
Scope document
A diagram of where card data flows and which systems are in scope, kept current and confirmed every year.
Key dates
- 31 March 2024PCI DSS v3.2.1 retired. v4.0 became the standard in use.
- June 2024PCI DSS v4.0.1 published, a limited revision of v4.0.
- 31 December 2024v4.0 retired. v4.0.1 is the only active version.
- 31 March 2025Requirements marked as future-dated in v4.0 became mandatory, including payment page script controls.
Checked against the official sources on 2026-10-25.
32 OceanLab product builds cite PCI DSS
Counted from our published case studies: a build counts when PCI DSS is in the list of rules it was built for.
Cenote - Merchant Dashboard for a Mexican Payment Gateway
Designed and built a clickable merchant dashboard for a Mexican online payment gateway that takes cards with meses sin intereses, SPEI transfers and OXXO cash vouchers in MXN: every payment from authorisation to settlement, declines in plain language, refunds with approval limits, chargebacks sorted by deadline and payouts that break down to the last fee.
Contrepoint - Three-Way Reconciliation Engine for Orders, PSP Payouts and Bank Lines
Designed and built a clickable reconciliation engine for a Lyon-based marketplace group paid through Adyen, Stripe, PayPal and SEPA: it matches orders to PSP transactions, payouts and bank statement lines, explains every suggestion, turns what is left into a worked exceptions queue and traces each match to the journal entries it posts.
Parley - Chargeback Manager with One Dispute Desk Across Every PSP
Designed and built a clickable chargeback manager for a US merchant group with four online brands on Stripe, Adyen and Braintree: one inbox for every dispute with deadline countdowns, evidence gathered per reason code, a fight or accept recommendation with its reasons, pre-dispute alerts and dispute ratios tracked against network thresholds.
Rastro - Corporate Cards and Spend Management with IVA-Ready Receipts
Designed and built a clickable spend-management platform for a Valencia fintech that gives Spanish SMEs company cards: budgets and card controls checked at authorisation, every transaction matched to its receipt, IVA marked recoverable or not from the invoice type, and a keyboard-driven review queue that turns card spend into bookable entries.
Bloomwright - Coffee Subscription Platform with Honest Cancellation
Designed and built a clickable subscription platform for a specialty coffee roaster shipping across the contiguous US: a care workspace to skip, swap, pause, refund and cancel for subscribers, a cancel log that replays every screen a subscriber saw, and fulfilment batches that hold boxes with an unverified address, a failed payment or short stock.
Almendro - Direct Booking Engine and Rates Console for a Costa Rican Hotel Group
Designed and built a clickable hotel console for a Costa Rican group of seven boutique hotels and eco-lodges: a dashboard of direct business, every booking with its price, payments and policy snapshot, a rates and availability grid where derived plans follow the best available rate, and a refund queue with approval limits.
Every build that cites PCI DSS
- Almendro - Hotel booking engine
- Bloomwright - Subscription box
- Calçada - B2B wholesale portal
- Cayuco - Voice AI call centre
- Cenote - Payment gateway dashboard
- Contrepoint - Reconciliation engine
- DriveLuxe - EV ride-hailing app
- Dufaa - Alumni network
- Garita - Log search (SIEM-lite)
- Ichu - Customer self-care app
- Kalafat - Short-term rental manager
- Kaudi - Family money app
- Kranich - Donation checkout
- Lakour - Table reservations
- Parley - Chargeback manager
- Pasje - Card issuing & controls
- Paws at Rest - Pet cremation tracker
- Pitline - Voice agent
- Quartet - BNPL checkout
- Rastro - Corporate cards & spend
- Returnable - Reusable packaging
- Ruins Guide - Heritage visitor app
- Setback - Permits & licences
- Setwise - Personal trainer app
- Soroban - Spend analytics
- Stožiar - EV charging app
- Tambora - Ticketing platform
- Taquara - Point of sale
- Tartera - Headless storefront
- Thila - Guest experience app
- Towpath - Course platform (LMS)
- Zarpe - Employee onboarding
Check your product
Other frameworks and industries
Build with PCI DSS in mind from day one
Project build
We design and build the system as one project. It starts with a clickable prototype your team tries before any production code is written. Pay per milestone (outcome-based) or hourly at $30-50/hr, depending on role and seniority.
Embedded engineers
Our engineers join your team on a flexible monthly retainer. Part-time is fine and it runs month to month, with hours that overlap the US, UK and Europe, the Middle East, and Australia and Asia. Outcome-based or $30-50/hr.
PCI DSS questions
Do we need PCI DSS if we use Stripe or another payment provider?
Yes, but your part can be small. If the provider hosts the payment fields or page and card numbers never reach your servers, merchants often qualify for the shortest questionnaire, SAQ A. You still have to protect the page that loads the payment form.
Can we store the card security code (CVV)?
No. Sensitive authentication data, including the card security code, must not be stored after authorisation, even encrypted.
What is the difference between an SAQ and a ROC?
An SAQ is a self-assessment questionnaire for smaller merchants and service providers. A Report on Compliance (ROC) is a full assessment by a Qualified Security Assessor, required at higher volumes. Which one you need depends on the card brands and your acquirer.
How do we make our PCI scope smaller?
Keep card numbers out of your systems with hosted fields and tokens, segment any system that must touch card data, and remove card data from logs and support tools. Every system you keep out of the CDE is one you do not have to assess.
