PCI compliance for high-risk merchants, without the mythology

What PCI DSS actually is

The Payment Card Industry Data Security Standard is a contract obligation that flows from the card networks through your acquirer to you. It has 12 requirement families covering how card data is stored, transmitted, and protected. Enforcement is contractual: fail an audit or leak card data, and your acquirer passes network fines to you, typically $5,000 to $100,000 per incident, and can terminate the account. There's no PCI police; there's your processor, holding your money, with a fine schedule.

Validation level depends on volume. Under 20,000 e-commerce transactions a year is Level 4, validated by self-assessment questionnaire. Over 6 million is Level 1, requiring an on-site audit by a QSA. Most merchants reading this are Levels 3 to 4 and will never see an auditor, which is exactly why the self-assessment gets treated carelessly, and why it bites later.

Your SAQ type is your workload

The self-assessment questionnaire you file depends on how card data touches your systems, and the difference in workload is enormous:

The single highest-leverage PCI decision is architectural: use your processor's hosted checkout or hosted fields so you qualify for SAQ A. The difference between 30 questions and 300 is whether your engineers spend a week or a quarter on this.

What changes when you're high-risk

The standard is identical for everyone; the validation isn't. High-risk acquirers routinely require quarterly ASV vulnerability scans even at levels where the standard doesn't mandate them, demand SAQ D where SAQ A would technically apply, and treat lapsed attestation as a hold trigger rather than a paperwork issue. After any breach, a merchant of any size can be escalated to Level 1 audits. High-risk merchants should assume the strict reading of every requirement, because their acquirer already does.

The five mistakes that actually cost money

Breach post-mortems and fine letters repeat the same handful of causes:

• Storing card data 'temporarily' in logs, order notes, or support tickets, which converts you to SAQ D retroactively and makes any leak catastrophic
• Taking card numbers by phone or email 'just this once', which is unencrypted card data transmission, scope you never assessed
• Letting the attestation lapse, then having a dispute or incident while out of compliance, which voids your defense on fines
• Treating the SAQ as a checkbox and attesting to controls that don't exist, which turns a breach into a misrepresentation problem with your acquirer
• Forgetting third-party scripts on the checkout page; a compromised analytics tag skimming cards is your PCI failure, not the vendor's

Shrinking the problem to zero

PCI scope exists wherever card data flows. The corollary: payments with no card data have no PCI scope. Crypto payments never involve a PAN, so the crypto share of your volume carries no SAQ, no scan, and no skimming surface. It can't replace your card rail's obligations, since whatever card volume you keep stays in scope, but every dollar shifted changes your risk arithmetic, and for card volume, hosted checkout keeping you at SAQ A is the whole game.

Flint handles the no-card-data rail with same-day settlement and setup in minutes, which pairs naturally with a hosted-checkout card setup: SAQ A on one side, no scope at all on the other. The security tradeoffs between rails are covered in the spec sheet.