Do you need PCI SSF or PCI DSS? Here’s the difference

Let’s keep it simple: PCI SSF is for the software, and PCI DSS is for everything else.

If you’re building or selling payment-related software, PCI SSF applies to you. If you’re storing, processing, or even touching cardholder data in any way (your website, server, or hosting stack included) you’re looking at PCI DSS.

These two frameworks come from the same council (PCI SSC), but they tackle very different problems in the ecosystem.

Most people only hear about PCI DSS because it’s the one that impacts merchants, SaaS companies, and pretty much anyone running a payment page. But PCI SSF? That one’s for the companies writing the actual payment software powering those systems.

Let’s break it down.

What is PCI SSF?

PCI SSF stands for Payment Card Industry Software Security Framework. It’s the newer, more flexible replacement for PA-DSS, the older version.

Where PCI DSS focuses on protecting data, PCI SSF is all about protecting the software that touches that data. That means the code running your point-of-sale system, mobile wallet app, or browser-based checkout module.

PCI SSF is actually two standards:

Secure Software Standard: Focuses on the security of the software itself. Is it hardened? Does it protect cardholder data? Does it have proper access control built in?
Secure Software Lifecycle (Secure SLC): Looks at how the software is made. Is your SDLC (software development lifecycle) secure? Do you patch vulnerabilities fast? Is security a first-class citizen?

In other words: PCI SSF cares about how your software is written, maintained, and updated. If your codebase is choppy, don’t expect to pass an SSF assessment.

Who is PCI SSF for?

Here’s the test:

Do you sell or distribute payment applications?
Does your software handle payments directly (even if it never stores cardholder data)?
Are you hoping to get listed on the PCI SSC’s list of validated payment software?

If you answered yes to any of these, PCI SSF requirement is needed.

What kind of software is in scope?

If you're building tools that are distributed and involved in the flow of cardholder data, you're likely in scope.

Here’s what typically qualifies:

POS systems:Software installed at physical checkout terminals.
Mobile payment apps: Apps that accept card payments through a mobile interface.
Checkout SDKs: Drop-in payment components or libraries that merchants embed in their sites or apps.
Thin clients: Lightweight apps that handle transaction routing or user input but rely on external APIs.
Kiosk or terminal software: Any code powering public-facing systems that accept cards.

And here’s what usually isn’t in scope:

Internal-only applications: Tools developed for and used within your own organization, with no distribution.
Back-office systems: ERPs or analytics tools that don’t touch the payment flow.
Hosted pages with no embedded logic: If your software simply redirects or frames a PCI-compliant hosted page, that alone might not trigger SSF.

If your software is sold, white-labeled, or distributed, and supports card payments, SSF almost certainly applies.

Examples of need PCI SSF required companies:

Here some examples. Note that we have no affiliation with the companies listed below:

POS system vendors

Example: Toast, Lightspeed, Square (hardware software stack).

They create distributed software installed on physical devices in retail and hospitality environments.
The software accepts card payments and interfaces directly with card readers.
Typically falls under the Secure Software Standard.

Mobile payment app developers

Example: SumUp, Zettle (by PayPal), Revolut Business.

Mobile apps that allow small businesses or individuals to accept card payments.
These often involve Bluetooth card readers and handle card data entry via phone or tablet.
Software security in these apps must be verified end-to-end.

Checkout SDK or payment library providers

Example:

These companies provide embeddable components that merchants use to accept payments.
Even if the card data is tokenized quickly, the SDK still handles sensitive logic.
Validation proves the SDK doesn’t create new attack surfaces.

Commerce platforms with embedded payments

Example: Shopify, BigCommerce, Ecwid.

Platforms offering embedded checkout modules that merchants use "out of the box."
The underlying software facilitating that checkout often needs SSF validation if it’s distributed.

Kiosk & terminal software companies

Example: Nayax, Ingenico, Verifone (for custom software builds)

Used in vending machines, ticketing kiosks, and self-checkout terminals.
Software must meet tamper resistance, update integrity, and secure communications requirements.
These environments are often "unattended," making SSF even more relevant.

White-labeled gateway solutions

Example: Payrix, BlueSnap, Corepay

Offer payment infrastructure that other platforms embed or resell.
The distributed software component (hosted fields, SDKs, plugins) often needs validation.
Also helps enterprise customers with their own PCI scope reduction.

Security-focused payment tools

Example: Very Good Security (VGS), Basis Theory, TokenEx

These companies handle sensitive data in proxy-like environments or vaults.
Their client-side SDKs or browser libraries may require SSF validation depending on how card data flows.

What does PCI SSF actually require?

Being PCI SSF-compliant isn’t just about clean code or good intentions. The framework sets out clear security objectives your software must meet. And they’re verified through assessment.

Some key expectations:

No sensitive data storage: The software must never store full card numbers, CVV codes, or magnetic stripe data in plaintext.
Cryptography done right: Industry-accepted algorithms with proper key management are required.
Update integrity: Software updates must be authenticated and signed to prevent tampering.
Secure defaults: Admin passwords, config settings, and access policies must ship in a hardened state.
Tamper protection: Your app must detect and respond to attempts to alter runtime behavior (e.g. injection, memory scraping).
Access control: Roles and permissions must be clearly defined, enforced, and logged.
Logging and traceability: Audit logs must be available, secure, and resistant to modification.
Documented SDLC: Your dev lifecycle needs to show security is embedded throughout. From design to delivery.

In short: assessors will expect you to prove security isn’t an afterthought.

What does the validation process look like?

PCI SSF validation is formal and structured. It’s done by a Secure Software Assessor (SSA). Not a self-assessment! This results in your product being listed on the PCI SSC website.

Here’s a high-level view of the process:

Scoping: Define which products or components are being submitted. You’ll need to clarify what functionality is in-scope and how it fits into payment flow
Gap Analysis (Optional): Some vendors start with a pre-assessment to identify major gaps before the formal process begins. This isn’t required but can save time later.
Formal Assessment: The assessor reviews your:

Source code (or binaries, if applicable)
Architecture and threat modeling
Development policies and procedures
Documentation and user guides

Remediation (if needed): If issues are found, you fix them, update documentation, and submit evidence of changes.
Submission to PCI SSC: Once your assessor is satisfied, they file a report to the PCI SSC for review.
Listing: If approved, your software is published on the official list of validated payment applications.

Timelines vary, but most assessments take a few weeks to a few months depending on the scope, maturity of the codebase, and clarity of documentation.

What is PCI DSS?

PCI DSS (Payment Card Industry Data Security Standard) is the one most have probably heard of and is targeted at all other companies having transactions on their site.

At its core, PCI DSS says:

If you touch cardholder data, you need to protect it, ..., and here are 12 ways how.

And if you’ve read our deep dive into PCI DSS 4.0.1, you’ll know those 12 ways aren’t exactly “just check a box” items. We’re talking:

Network security controls
Anti-malware protection
Vulnerability management
Monitoring and logging
Secure software development
Script inventory (hi, 6.4.3 👋)
Securing payment headers (hello again, 11.6.1 👋)

Whether you’re a merchant with SAQ A, a service provider, or a Shopify app developer using hosted fields, PCI DSS is the framework that applies to your live, card-processing environment.

Here are some links to previous info we wrote on PCI DSS, in order of how you should read them:

So what’s the difference?

Let’s lay it out, side by side:

Area	PCI SSF	PCI DSS
Main Audience	Payment software vendors	Merchants, SaaS providers, service providers
Scope	Secure software + secure SDLC	Secure storage, processing, and transmission of card data
What it protects	The application and its code	Cardholder data and the environments it lives in
Assessment Type	Secure Software Assessor (SSA) reviews	Self-assessment (SAQ) or QSA audits
Example	A company selling a POS system or checkout SDK	An online store accepting cards with a hosted checkout
Goal	Prevent software-based vulnerabilities	Prevent data theft, leakage, and breaches
Touchpoint	Dev team + product + compliance	DevOps + security + legal + customer experience

Can a company fall under both?

Absolutely. Let’s say you build and sell a checkout plugin (PCI SSF), but you also use that plugin on your own eCommerce site (PCI DSS). Now you’ve got to handle both: secure your codebase, and also secure your infrastructure.

Even if you don’t handle card data directly (e.g., SAQ A merchants using Stripe or competitor's with hosted fields), you still fall under PCI DSS, Likely version 4.0 requirements like 6.4.3 and 11.6.1 that make you accountable for 3rd-party scripts and DOM integrity.