PCI DSS v4.0 Merchant Attestation for Trade Businesses
Why this matters
Every trade business that accepts credit cards is a "merchant" under PCI DSS (Payment Card Industry Data Security Standard) and is required to annually attest to compliance. Most owners have never seen the attestation form; the payment processor sends a reminder, the owner ignores it or clicks through without reading, and the business is in technical non-compliance. The exposure shows up at a card breach: the card networks impose fines, the processor passes them through, and the business that thought it was compliant is on the hook for substantial penalties. PCI DSS v4.0 (active as of March 31, 2024, with some requirements phased in through March 31, 2025) sharpens the requirements. This is the working reference for what a trade-business owner has to know.
What PCI DSS is
PCI DSS is a contractual standard set by the PCI Security Standards Council, an organization formed by Visa, Mastercard, AmEx, Discover, and JCB. The standard defines requirements for any organization that stores, processes, or transmits cardholder data.
Compliance is contractual, not legal. The merchant agreement with the payment processor includes a PCI DSS compliance obligation. Violation of the merchant agreement triggers fees, fines, and potentially termination of payment-processing privileges.
After a breach, the card networks (not government regulators) impose fines, typically in defined penalty bands. The penalties can run into hundreds of thousands of dollars for material breaches at smaller merchants, and into millions for larger merchants. The processor passes the fine through to the merchant per the merchant agreement.
Merchant levels
PCI DSS classifies merchants by annual card transaction volume:
- Level 1. Over 6 million card transactions annually (or a previously breached merchant at any volume). Requires annual third-party Report on Compliance (ROC) by a Qualified Security Assessor (QSA).
- Level 2. 1 to 6 million transactions. Requires annual Self-Assessment Questionnaire (SAQ).
- Level 3. 20,000 to 1 million e-commerce transactions. Requires annual SAQ.
- Level 4. All other merchants (typically under 1 million transactions). Requires annual SAQ.
Most trade businesses are Level 4. The annual obligation is the SAQ and quarterly external network scans (for some SAQ types).
SAQ types
Nine SAQ types exist; the right one depends on how the merchant processes cards. Key types: SAQ A (e-commerce, card data captured by PCI-compliant third party via iframe or redirect, lowest complexity); SAQ A-EP (merchant page contributes to payment form but does not handle card data); SAQ B (imprint or standalone dial-out terminals); SAQ B-IP (standalone IP-connected payment terminal); SAQ C-VT (web-based virtual terminal); SAQ C (payment application connected to internet, no card storage); SAQ P2PE (validated point-to-point encryption solution, lowest complexity in-person); SAQ D-Merchant (all other merchants, highest complexity).
For a trade business using a payment terminal or CRM-integrated card processor where the processor tokenizes the card and the merchant does not store it, SAQ A or SAQ P2PE applies (lowest complexity). For typing card numbers into a virtual terminal in a browser, SAQ C-VT. For storing card data anywhere on merchant systems (even encrypted), SAQ D-Merchant applies; avoid this case by not storing card data.
The simple rule: do not store card data
The most important PCI DSS principle: do not store cardholder data on merchant systems. If the merchant never stores PAN (16-digit card number), cardholder name combined with PAN, expiration date combined with PAN, service code combined with PAN, or full track data / CVV / CVC / PIN, then most PCI DSS requirements do not apply. The merchant uses a processor (Stripe, Square, Authorize.net, Worldpay, Heartland) that tokenizes at point of capture; the merchant stores only the useless-to-attacker token.
The achieving workflow: card payments captured via the processor's hosted form (iframe, redirect, or processor-provided terminal); the token is stored in the CRM for future charges; the card number is never typed into the CRM, FSM platform, or any business-owned system; receipts and customer-facing payment pages reference only the last 4 digits. This makes the business eligible for SAQ A or SAQ P2PE (lowest complexity).
PCI DSS v4.0 changes and the SAQ workflow
PCI DSS v4.0 became active March 31, 2024, with some requirements phased through March 31, 2025. Key SMB-relevant changes: customized approach option (compliance via documented compensating controls; SMBs typically still use defined approach); MFA required for all cardholder-data-environment access (not just remote); targeted risk analysis for some requirements like password expiration; quarterly anti-skimming inspection of in-person terminals; anti-phishing training and detection; expanded logging with daily review of in-scope systems. For SAQ A or SAQ P2PE merchants the v4.0 impact is modest because the in-scope environment is small.
Annual SAQ workflow: confirm SAQ type with the payment processor; download from PCI SSC; complete (yes/no questions about controls); sign the Attestation of Compliance (AOC); submit to the processor (most have a portal; some use a third-party vendor like Trustwave or ControlScan); quarterly external network scan by an Approved Scanning Vendor for SAQ A-EP, B-IP, C, C-VT, D (typically not required for SAQ A or SAQ P2PE).
Common compliance failures and breach response
Common failures: storing card data in customer notes ("Customer authorized 1234... for monthly auto-pay" in the CRM brings PCI scope to the CRM); photographing the card on a customer tablet (image syncs to cloud); emailing card numbers (inbox falls under PCI scope); faxing card numbers (physical exposure); skipping the SAQ (processor flags the account, fees increase). Fix: process card data only through the processor's secure channel; tokenize, never store.
If a breach is suspected: contain immediately; notify the processor within the merchant-agreement window (often 24 hours); engage a PCI Forensic Investigator if directed by card networks; notify affected customers per state breach-notification laws; cooperate with the card brand investigation. Post-breach forensic engagement plus card-network fines plus state breach-notification costs run into substantial six-figure SMB exposure; prevention via "do not store card data" is the cost-effective approach.
Storing customer credit card numbers in a CRM custom field, spreadsheet, scanned paper, or email attachment converts the entire system to a PCI DSS in-scope environment. The SAQ jumps from A to D (penetration testing, audit logging requirements). A breach exposes the business to card-network penalties. Audit the business's data, purge stored card data, rely on processor tokenization.
References
- PCI Security Standards Council, PCI DSS v4.0.1 (current version as of release)
- PCI Security Standards Council, Self-Assessment Questionnaires A, A-EP, B, B-IP, C, C-VT, D, P2PE
- PCI Security Standards Council, Attestation of Compliance documents
- Payment processor merchant agreements (binding for fines and penalties)
- State data breach notification laws (state-specific; consult counsel)
- 15 USC 6801-6809 - Gramm-Leach-Bliley Act (related to financial data; sometimes touched by trade-business AR data)