Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

PCI DSS compliance levels categorize merchants and service providers based on annual card transaction volume, determining their validation requirements. Merchants fall into four levels, with Level 1 requiring the most rigorous assessment through a Qualified Security Assessor, while Levels 2 through 4 typically complete self-assessment questionnaires. Service providers follow a separate two-tier system.

Maintaining a secure external attack surface is no longer just about finding vulnerabilities; it’s about proving your resilience to partners, auditors, and regulatory bodies. Today, we are excited to announce Detectify’s PCI ASV Scanning, delivered in partnership with Clone Systems.

PCI-DSS is one of the most widely used security frameworks around the world. Unlike frameworks like FedRAMP or CMMC, PCI-DSS is a global security standard, not a standard issued by the US Government. It’s the Payment Card Industry Data Security Standard, and it’s required for any business or entity that handles cardholder or authentication data. Merchants, payment providers, gateways, banks; they all need it.

Here on the Ignyte blog, we talk a lot about general information security frameworks like ISO 27001 and government frameworks like CMMC and FedRAMP. But that doesn’t mean that’s all we understand. One of the most broadly used security standards in the world is PCI DSS. The Payment Card Industry Data Security Standard is the standard that must be upheld by any and all entities that handle, process, or store cardholder data and authentication data for payments.

The skimmer doesn’t go inside the iframe. It doesn’t need to. In every significant payment page compromise of the last decade, the malicious code sat on the merchant’s page, outside the payment component entirely, watching form submissions, intercepting keystrokes, reading values before they ever reached the provider’s sandbox. This is the architecture SAQ A-EP merchants live in.

PCI DSS compliance is a mandatory, revenue-critical requirement for fintech companies that touch cardholder data—directly or indirectly. This guide is written for fintech founders, CISOs, CTOs, and security leaders building or scaling payment-enabled platforms in the US and globally. If your fintech stores, processes, or transmits cardholder data, PCI DSS compliance for fintech companies is not optional—it is a baseline operating requirement. With PCI DSS v4.0.x now fully in force.

Ask five compliance leads in the gaming industry how 6.4.3 applies to their payment flows, and you’ll get five different answers. Ever since PCI v4.0.1 has come into effect, gaming and iGaming operators have been struggling to identify where they fall in scope, which SAQ paths apply to their specific architecture, and if Requirement 6.4.3 and 11.6.1 apply to them or their payment processors.

Nearly 70% of online purchases now happen on mobile, yet PCI scoping decisions are still often made as if mobile is just a smaller browser. It is not. A native in-app payment flow and a mobile web checkout trigger materially different obligations under PCI DSS 4.0.1. In one case, risk concentrates inside the application runtime through SDKs, platform storage, and release controls.

Very few people know this, but passing a PCI audit has very little to do with having defensible evidence. Your processor passed its last PCI assessment. Three months later, a merchant using your payment forms gets hit with a Magecart attack. Card brands start asking: What monitoring did you have on that checkout page? When did you detect the compromise? What evidence can you provide? That’s when the gap becomes obvious.