PCI DSS Basics for Online Merchants: Scope, the SAQ and the Non-Compliance Fee

PCI DSS reaches an online merchant through the merchant agreement; the acquirer decides how you validate. A hosted or tokenized checkout keeps card numbers out of your systems and earns the shortest self-assessment questionnaire. You complete it once a year, run quarterly external scans only when it requires them, and sign the attestation. Miss it and a monthly non-compliance fee runs on your statement until you validate.

PCI DSS (the Payment Card Industry Data Security Standard) is the card brands' security standard for every business that stores, processes or transmits cardholder data, and it reaches you through your merchant agreement as a contractual obligation. For a small online merchant it comes down to four practical items: keep card numbers out of your own systems with a hosted or tokenized checkout, complete the self-assessment questionnaire your acquirer assigns once a year, run the quarterly external scan when that questionnaire requires one, and return the signed attestation so the monthly non-compliance fee never appears on your statement.

How PCI DSS reaches an online merchant

The standard is published by the PCI Security Standards Council and enforced by the card brands through the acquirers. Your acquirer answers to the brands for its merchants, so the merchant agreement passes the obligation to you: validate compliance in the form the acquirer prescribes, by the deadline it sets, or pay the fee on its pricing sheet until you do. The largest merchants, measured in millions of transactions a year, are assessed on site by a Qualified Security Assessor or a trained internal assessor. Nearly every online merchant below that level self-assesses: a questionnaire, a scan when the questionnaire calls for one, and a signed attestation.

Two definitions decide everything that follows. Cardholder data is the card number, together with the cardholder name, the expiry date and the service code that travel with it. Sensitive authentication data is the security code, the PIN and the full contents of the magnetic stripe or chip; it may be used to authorize a payment and must never be stored afterwards, anywhere. Your PCI scope is every system that touches either category, plus any system connected to those. The less of your own infrastructure sits in scope, the shorter your questionnaire and the cheaper your year.

Scope: why a hosted checkout or a tokenized gateway keeps card data away from you

Scope is set by one question: where does the card number go when a customer pays? Three designs cover almost every online store. In a hosted checkout, the customer is redirected to a payment page run by the gateway, or types into an iframe the gateway serves inside your page; the number travels from the customer's browser to the gateway and your servers never see it. In a merchant-page checkout, your own page collects the number and a gateway script or a direct post carries it away; you never store it, but your page controls how it leaves, so your website is in scope. In a self-managed checkout, the number reaches your server, your database, your inbox or your phone system; everything it touches is in scope, and you are running a full security program.

Tokenization is what makes the first design work for subscriptions and refunds. The gateway stores the card and hands you a token, a reference that means nothing outside that gateway. You keep the token, charge the rebill against it, refund against it, and your database holds no card numbers. The two decisions that keep a small merchant in the lightest category are therefore simple: let the gateway's page or iframe collect the card, and store only the token. Never accept card numbers over email or chat, and never keep a spreadsheet of cards to rebill by hand; one such file puts the whole business in scope.

The self-assessment questionnaire, in practice

The self-assessment questionnaire (SAQ) is a yes-or-no checklist tailored to how you take cards. Its first pages list eligibility criteria: the shortest version is reserved for merchants whose card handling is fully outsourced, the longer versions for merchant-page and self-managed checkouts. The acquirer, or the compliance vendor running its program, usually assigns the type from the checkout description you gave at application. It is completed once a year, and again when the checkout changes. Answer honestly: a no is a gap to close before you sign, not a box to reword, and a not applicable needs a reason the acquirer would accept. Even the shortest questionnaire asks for real things:

• A list of the third parties that handle card data for you, with the responsibilities agreed and their own compliance status on file; most gateways publish their attestation or provide it on request.
• No card data on your side: nothing stored, printed, emailed or pasted into a support tool, and a rule for staff when a customer offers a card number over the phone.
• Controlled access to anything that could change the checkout page: individual accounts, strong passwords, vendor defaults removed, and leavers removed the day they leave.
• Knowledge of your own payment page: which scripts load on it, who may change them, and how you would notice a change you did not make.
• A named person and a short plan for the day something goes wrong, including the acquirer's contact for reporting a suspected compromise.

The quarterly scan, when your questionnaire requires it

An external vulnerability scan is an automated test of the public side of your systems, run from the internet by an Approved Scanning Vendor (ASV), a company approved by the Council. It probes the domains and public addresses you list for known weaknesses and returns a pass or a fail. A passing scan is needed every quarter, and a fail is fixed and rescanned, not filed. Common reasons for a fail on a small store include outdated encryption settings, an exposed administration panel and unpatched components on the store platform. Whether the scan applies to you depends on the questionnaire assigned: the merchant-page and self-managed designs need it, and the fully hosted design may not. Your acquirer's program tells you which. Do not buy scans you are not required to run, and do not skip the ones you are.

The attestation, the portal and the non-compliance fee

The Attestation of Compliance (AOC) is the signed summary of your result: which questionnaire, whether the scans passed, and a declaration by an officer of the merchant entity that the answers are true. Acquirers typically run the cycle through a compliance portal: the questionnaire, the scan reports if any, an electronic signature, and a status that reads compliant until the next anniversary. Miss the deadline and two lines matter on your statement. The PCI fee is the recurring charge for the program itself, billed whether you validate or not. The non-compliance fee is a monthly penalty charged until you validate; it is the one avoidable line in the monthly group of the pricing sheet, and do not expect past months to be refunded once you catch up. The guide on reading a pricing sheet places both lines among the others.

On a merchant account opened with an IBOCore package, two practical details matter. Acquirer notices, including the enrolment link and the reminders, go to the business email on the application; when that is the professional email on the company domain that came with the package, make sure someone reads it. And where the acquirer requires an officer's signature on the attestation, the director signs, the same way the director handles verification calls and other acquirer signatures; the technical answers stay yours, because the checkout is yours. Route the request through your private Telegram group and the signature comes back without anyone stepping into the business.

1. At MID approval, find the PCI enrolment link and the validation deadline in the welcome pack; ask the acquirer if neither is there.
2. Describe your checkout exactly as it runs, so the right questionnaire is assigned.
3. Complete the questionnaire, closing every gap that produced a no before you submit.
4. Run the external scan if your questionnaire requires one, and rescan after fixes until it passes.
5. Sign the attestation, or pass it to the director for signature when the acquirer asks for an officer, and keep a copy with the merchant agreement.
6. Put the anniversary and the quarterly scan dates in a calendar, and re-validate when the checkout changes.

What PCI DSS does not cover

PCI DSS is about card data and nothing else, and merchants waste time mixing it with the other items on a merchant file. It is not underwriting: KYB, the acquirer's review of the entity, its ownership, the website and the policies, happens before the MID and is judged on different evidence. It is not fraud prevention: a compliant checkout can still see stolen cards and disputes, the territory of the 3-D Secure guide. It is not the checkout policy layer: the terms, refund policy and pricing that must be visible before payment belong to the checkout checklist guide. And it is not beneficial-ownership reporting: a US-formed LLC or corporation is a domestic reporting company, and under FinCEN's interim final rule of March 2025 domestic companies and US persons are exempt from BOI reporting at the time of writing, while companies formed under foreign law that register in a US state remain subject to it; verify current FinCEN guidance, and take contract, data-protection and tax questions to a professional, because this guide is not legal advice.

Questions merchants ask

Do I still need to validate PCI DSS if the gateway handles every card number?

Yes. Outsourcing shrinks the scope, not the obligation. A merchant whose checkout is fully hosted and tokenized still completes the shortest questionnaire each year, keeps the list of providers with their compliance status, confirms that no card data is stored on its side, and signs the attestation. The work is small, and the non-compliance fee applies just the same if the attestation is never returned.

Is the PCI fee on my statement the same as the non-compliance fee?

No. The PCI fee is a recurring charge for the acquirer's compliance program and is billed whether or not you validate. The non-compliance fee is a penalty charged every month you remain unvalidated, and it stops once you are. The IBO package costs $999 setup, then $2,999 per month from 30 days after delivery, whatever the vertical or the billing model.

Who signs the attestation when the merchant account sits on an IBOCore package?

The answers belong to whoever runs the checkout, which is you. The signature belongs to an officer of the entity when the acquirer requires one, and on an IBOCore package that is the director, an IBO (Independent Business Operator) qualified in-house, who collaborates on acquirer signatures and verification calls throughout the life of the package without stepping into the business. Send the request through your private Telegram group with the completed questionnaire attached, and keep the signed attestation with your merchant agreement.

Compliance touchpoints that survive audit

Clean setups disclose beneficial ownership, file BOI, use genuine IDs, and keep the IBO informed of website and descriptor changes. Processors re-scan for prohibited products, undisclosed aggregation, and transaction laundering. Violations land on MATCH and kill future MID applications.

• AML / CDD: customer due diligence on the merchant entity.
• PEP screening: politically exposed persons get enhanced review.
• OFAC / SDN: sanctions lists checked on owners and signers.
• Website compliance: refund policy, terms, pricing visible before checkout.

Compliance shortcuts that trigger MATCH

Fake guarantors, borrowed SSNs, cloaked websites, and third-party processing through your MID are the fastest paths to MATCH listings. Recovery requires legal work and years of delay. Disclose, document, and keep the IBO in the loop.

FAQ: quick answers

How fast can I get an IBO package on IBOCore?

Available inventory ships the same day after payment. You receive Articles, EIN letter, registered agent details, bank onboarding pack and signer contact through your merchant dashboard. Processor onboarding typically follows over the next one to two weeks.

Where can I look up payment-processing jargon?

Use the Resources glossary on IBOCore (/resources) for 580+ definitions: MID, chargeback ratio, MATCH, rolling reserve, MCC, RDR, KYB and high-risk vertical vocabulary.