PCI DSS for adult classifieds: what actually decides how much compliance work you carry
Getting a payment processor to accept an adult classifieds site is its own fight, and once it's won, most operators assume the hard part is over. It isn't. The account that finally says yes comes with an ongoing obligation attached to it, one that has nothing to do with age verification, moderation, or any of the rules a state or a search engine might impose. It is a security standard written by the card networks themselves, and it applies the moment a card number touches any part of your business, regardless of how small that business is.
What follows is not legal advice, and a Qualified Security Assessor should review anything that touches real cardholder data. It is the shape of a decision that most operators never realize they are making, because someone else, usually a developer trying to build a nicer checkout page, makes it for them before the question ever reaches the business side of the company.
The rule you agreed to without reading
PCI DSS, the Payment Card Industry Data Security Standard, is not a government regulation and no state agency enforces it. It is a contractual obligation written into the agreement every merchant signs with an acquiring bank or payment facilitator, and it exists because Visa, Mastercard, and the other networks require their acquirers to pass it down to every business that stores, processes, or transmits a card number. The standards body itself is explicit that this applies to any entity handling cardholder data, whether that handling happens directly or through a third party, with no exception carved out for size or transaction volume.
This is a different question from the one a processor asks before opening the account. What a processor wants to know before it agrees to work with you is about the business itself: who owns it, how listings are reviewed, how advertisers are verified. PCI DSS starts after that account exists, and it never really stops. It is renewed every year for as long as the business accepts cards, and it changes shape whenever the way cards are accepted changes.
Transaction volume does matter, just not in the way people assume. It sets a merchant "level," from one to four, and that level decides how compliance gets validated: a small operator fills out a self-assessment questionnaire, while a business processing millions of transactions a year needs an outside auditor. What volume does not do is exempt anyone. A high risk merchant running a few hundred transactions a month is bound by exactly the same underlying standard as a national retailer, just validated through a shorter form.
The one decision that sets your workload for years
The form that applies to a given business is not chosen freely. It is determined entirely by a technical fact: does the card number, at any point, pass through a system the operator controls. Send the customer to a payment page hosted by the processor, or embed a properly isolated payment iframe supplied by that processor, and the card number never touches the operator's own server. Build a checkout form that collects the card number and sends it to the operator's own backend before forwarding it on, even briefly, and it does.
That single fact separates the lightest questionnaire from the heaviest one by an order of magnitude. The fully outsourced path, known as SAQ A, runs to roughly twenty requirements. The path where the operator's own page delivers or influences part of the payment process, even without directly touching the card number, such as a self-hosted form whose fields post the data onward, lands in SAQ A-EP, closer to two hundred requirements. Actually storing, processing, or transmitting card data on the operator's own systems lands in SAQ D, which covers the standard's full set of controls: encryption, key management, network segmentation, logging, access control, all of it, running to several hundred items.
There's a common misunderstanding worth heading off directly. Using an iframe from a compliant provider does not automatically drop a site into the heavier SAQ A-EP tier; a correctly isolated third-party iframe, one where the operator's own page contributes no code that can see or touch the payment fields, still generally qualifies for the light SAQ A path. What pushes a business up a tier is the operator's own code reaching into that page, whether that's a self-built form, a script added to "improve" the checkout, or an older-style integration where the browser posts card data through code the operator wrote rather than code the processor supplied.
What the light path still requires, since last year
It's worth correcting a belief that used to be true and no longer is. Operators who chose the outsourced route learned, correctly, that it kept them out of most of the standard's technical burden, and some still believe that means no ongoing security testing at all. As of PCI DSS version 4.0.1, enforceable since April 2025, that's no longer accurate. SAQ A now includes a requirement for quarterly external vulnerability scans by a PCI Approved Scanning Vendor, run against the operator's own website, the one hosting the redirect or the iframe, even though that site never sees a card number itself.
The reasoning behind the change is straightforward once it's stated: the page that sends a customer to the payment processor is still part of the attack surface. A compromised checkout page can redirect a customer somewhere other than the real payment processor, or load a malicious script that reads card details straight out of the browser before the iframe ever loads, an attack pattern that has hit real retailers. Two related requirements follow from the same logic: the operator has to keep an inventory of every script that runs on the payment page, and detect unauthorized changes to that page's content, obligations that apply in SAQ A specifically because the checkout page is the operator's, even when the card number itself never was.
What the light path still avoids, and this is the gap that actually matters, is the annual penetration test required under SAQ A-EP and SAQ D, along with the deep internal controls those tiers require: encrypting stored card data, managing the keys that protect it, segmenting the network around any system that touches it, and logging access to all of it in detail. Choosing the outsourced path doesn't mean no security work. It means a few hours of scanning and script hygiene a year instead of a standing security program built around data the business would otherwise be storing.
What it costs to get this wrong
None of this is enforced by a court or a regulator, which is part of why it's easy to underestimate. The card networks fine the acquiring bank when a merchant under its portfolio isn't compliant, and the acquirer passes that cost straight down through the merchant agreement, typically starting modestly and increasing the longer noncompliance continues. No published table sets these figures for every acquirer, because the arrangement sits inside private contracts rather than public rules, but the direction is consistent: the fine grows with time, not with how the business explains the delay.
That's the cost of simply being out of compliance. An actual breach, where stored card numbers are exposed because an operator was handling data SAQ A was designed to avoid, is a different order of expense entirely. The card networks can require a forensic investigation by a specialist firm before anyone is allowed to reopen the account, paid for by the merchant regardless of outcome, and the affected cards get reissued at the merchant's cost. Cyber liability insurance rarely closes this gap for a business like this one, since adult content sits on the excluded-industry list of more than one major carrier's cyber policy, which means the exposure described here is very often uninsured rather than merely expensive.
The most durable consequence isn't the fine or even the investigation. It's the acquirer's decision, once a breach or a sustained compliance failure is on file, to close the account rather than keep underwriting the risk, and to record that closure in a way other acquirers can see before they open a new one. A processing relationship that took months to build the first time is considerably harder to rebuild with that history attached to the business.
What to do this month
Start by finding out, in writing, which questionnaire actually applies today. Ask the payment processor directly rather than assuming: confirm whether the current checkout is a redirect, a properly isolated iframe, or something that touches the operator's own server at any point, because the answer to that question is the entire compliance program in one sentence. Get it in an email, not a phone call, since it's the reference point for every decision that follows.
Treat any request to change how cards are collected as a compliance question before it's a design question. A developer who wants to build a custom checkout form because the hosted page looks generic, or who adds a chat widget or an analytics script to the same page that hosts the payment iframe, is making a PCI decision whether or not anyone frames it that way. Review that kind of change before it ships, not after a scan flags it.
File the annual attestation on schedule and keep the scan results from every quarter, even the boring ones where nothing changes, because a lapsed attestation reads the same to an acquirer as never having filed one. None of this is difficult when the underlying architecture is right. A checkout built once around a hosted page or a properly isolated iframe turns this into an afternoon of paperwork, repeated once a year. A checkout that quietly grew a habit of touching card data turns the same obligation into a standing security program the business didn't plan to run.
