Security · Card data
PCI DSS for startups
If your product stores, processes or transmits payment card data, the Payment Card Industry Data Security Standard applies. For most startups, the biggest decision is architectural: how little card data to touch. This guide explains scope, the self-assessment questionnaires and the current version of the standard.
Checked September 2026. Your acquirer or payment brand decides your validation requirements. Confirm yours with them before choosing a path.
Who sets the rules
PCI DSS is published by the PCI Security Standards Council, which was founded by the major card brands. The Council maintains the standard and the assessment documents. It does not enforce them. Enforcement runs through contracts: the card brands require acquiring banks to make merchants and service providers comply, and those banks, or the processors acting for them, decide how each business must validate compliance.
That split matters for a fintech. A company that accepts cards for its own products is a merchant. A company whose platform stores, processes or transmits card data for other businesses, or can affect the security of it, is likely a service provider, with a different set of expectations.
The current version
- PCI DSS v4.0.1 was published in June 2024 as a limited revision that clarified v4.0.
- PCI DSS v4.0 was retired on December 31, 2024, leaving v4.0.1 as the active version.
- New requirements that v4.0 introduced as future-dated became effective on March 31, 2025, and are now assessed like any other requirement.
- The Council updated SAQ A in January 2025, effective March 31, 2025, removing some payment-page script requirements and adding an eligibility criterion that the merchant confirm its site is not susceptible to attacks from scripts that could affect its e-commerce systems.
Scope: the decision that matters most
Every system that stores, processes or transmits cardholder data, and every system that can affect the security of those systems, is in scope. The fewer systems in scope, the smaller the assessment. The common ways startups keep scope small:
| Approach | How it works | Effect on scope |
|---|---|---|
| Hosted payment page or redirect | The customer enters card details on the processor's page | Card data never reaches your servers; your website still matters |
| Embedded fields (iframes) | Card fields are served by the processor inside your page | Similar to a hosted page, if implemented as the processor documents |
| Direct post or JavaScript on your page | Your page's code handles or sends the card data | Your web servers come into scope |
| Tokenization | The processor returns a token that you store instead of the card number | Tokens that cannot be used to recover card numbers reduce what you hold |
| Point-to-point encryption (P2PE) | Validated devices encrypt card data at the terminal | Can reduce scope for in-person payments |
| Storing card numbers yourself | You hold primary account numbers | Full scope, including encryption and key management |
Sensitive authentication data, such as full magnetic stripe or chip data, card verification codes and PINs, must not be stored after authorization, even if encrypted.
Self-assessment questionnaires
Smaller merchants usually validate with a self-assessment questionnaire (SAQ) and an attestation of compliance. Which SAQ you use depends on how you accept cards:
| SAQ | For |
|---|---|
| A | Card-not-present merchants that fully outsource card handling, such as via a hosted page or iframe, and meet the eligibility criteria |
| A-EP | E-commerce merchants that outsource processing but whose website can affect the security of the payment transaction |
| B / B-IP | Merchants using imprint machines or standalone dial-out terminals (B), or standalone IP-connected terminals (B-IP) |
| C-VT | Merchants that key transactions into a provider's web-based virtual terminal |
| C | Merchants with payment application systems connected to the internet |
| P2PE | Merchants using only a validated point-to-point encryption solution |
| SPoC | Merchants using a validated software-based PIN entry on a commercial device solution |
| D | All other merchants, and service providers eligible to self-assess |
Larger businesses, and many service providers, validate through an on-site assessment by a Qualified Security Assessor, which produces a Report on Compliance. Transaction-count thresholds for each level are set by the card brands, not by the Council.
Getting to compliance, step by step
- Draw the card data flow. Where card data enters, which systems touch it, and where it leaves.
- Reduce scope. Move card entry to your processor's hosted or embedded fields, and store tokens instead of card numbers.
- Ask your acquirer or processor which validation method and SAQ they expect.
- Read the SAQ's eligibility criteria before answering any requirement. If you do not meet them, you are using the wrong questionnaire.
- Close the gaps, then collect evidence: configurations, scans, policies and records.
- Run the required scans. Many SAQs require external vulnerability scans by an Approved Scanning Vendor.
- Sign the attestation and repeat the cycle each year, and whenever the payment flow changes.
Where PCI DSS fits in the wider program
PCI DSS covers card data only. Non-bank financial companies may also need a written information security program under the FTC Safeguards Rule, and partner banks commonly ask for an independent security report as well. Texas has its own breach notification law; see the Texas privacy and breach guide. Bank partners will ask for your PCI status during sponsor bank due diligence.
Common questions
Do I need PCI compliance if I use a payment processor?
Yes, in most cases, but the work can be much smaller. A merchant that fully outsources card handling may qualify for SAQ A, which is the shortest questionnaire. The processor's own compliance does not replace yours.
Is PCI DSS a law?
No. It is an industry standard enforced through contracts with acquirers and card brands. Failing to meet it can bring fees, higher costs or the loss of the ability to accept cards.
What changed on March 31, 2025?
The requirements PCI DSS v4.0 introduced as future-dated became effective, including several aimed at e-commerce payment pages, and the revised SAQ A took effect.
Does a fintech that issues cards need PCI DSS?
Card issuers and their processors handle card data, so PCI requirements reach them too, usually through the card program's issuing processor and the network's rules. Confirm the scope with your issuing partner.
For the full list of obligations, see the fintech compliance checklist.
Last reviewed 2026-09-17