# Card Data Desk for PCI DSS > Read which PCI DSS v4.0.1 Self-Assessment Questionnaire (SAQ) applies to a business, and review the code, configuration, payment-page markup, schema and logs that touch card data. The free check runs in the browser and uploads nothing: six answers (merchant or service provider, channels, how each channel takes cards, whether card data is kept, annual Visa transactions) give the SAQ each channel points at, the merchant or service-provider level and the validation it asks for, and every contradiction between the answers and the pasted code. A card-data scan (23 rules) finds unmasked card numbers, track data, stored or logged card verification codes, card numbers in logs and URLs, unkeyed hashes, http:// and TLS below 1.2, card fields on your own page, servers that send raw card fields to the processor and unmanaged payment-page scripts. Card numbers, track data, card codes and secrets are masked before anything is sent. The paid scope lane reads the SAQ, level, systems in scope, data flows, key requirements and scope reductions; the paid review lane gives findings with exact before/after edits. The page checks every quote and number against the input, applies every edit and scans again. App: https://pci-desk.skillsafe.ai/ API tutorial: https://pci-desk.skillsafe.ai/api.html ## Input - The questionnaire: merchant or service provider; channels (online, in person, mail or phone); how each channel takes cards; whether card data is kept electronically after payment; paper with card numbers; third-party scripts on the checkout page; annual Visa transactions (all channels, e-commerce) or, for service providers, annual transactions. - A description of how payments work (optional for the review). - The code, config, page markup, schema or logs, pasted into one box with a `// file: ` (or `# file:`, `-- file:`, ``) line above each file; dropped files are joined that way. Keys and certificates are never read. ## The SAQ reading (free) - Online: the processor's own page (redirect) or its fields in iframes -> SAQ A; a form the processor's script builds on your page, or your form posted straight to the processor -> SAQ A-EP; your server receives the card -> SAQ D. - In person: imprint machines or standalone dial-out terminals -> SAQ B; standalone IP terminals -> SAQ B-IP; a PCI-listed P2PE solution -> SAQ P2PE; a PCI-listed SPoC solution -> SAQ SPoC; a POS or payment application connected to the internet -> SAQ C. - Mail and phone: the processor's web virtual terminal -> SAQ C-VT; a terminal -> as that terminal; your own order system -> SAQ C. - Card data kept electronically makes every channel SAQ D. Service providers use SAQ D for Service Providers. Channels on different SAQs read as "multiple": ask the acquirer whether it takes one SAQ per channel. - Each SAQ is listed with the conditions it holds only under (for SAQ A, the January 2025 criterion that the site is not susceptible to script attacks). - Level, on Visa's thresholds: over 6 million Visa transactions -> 1; 1 to 6 million -> 2; 20,000 to 1 million e-commerce -> 3; otherwise 4. Service providers: over 300,000 -> SP1, else SP2. The acquirer assigns the level. - Contradictions: card data kept or logged in the paste although the answers say it is not; card fields on your own page, or a server sending card fields, although the answers say redirect or iframe; Authorize.net Accept.js with a redirect/iframe answer. ## Flags the scan raises - PC-01 (high, 3.5.1): a Luhn-valid card number with a known brand, not a published test number. - PC-02 (low, 6.5.6): a published test card number. - PC-03 (high, 3.3.1.1): full magnetic-stripe track data. - PC-04 (high, 3.3.1.2): a card verification code logged, kept in a column or model field, or saved. - PC-05 (high, 3.3.1.3): a PIN or PIN block kept. - PC-06 (high, 3.5.1): a card-number column or field with nothing on the line that encrypts, tokenizes, truncates or hashes it. - PC-07 (high, 3.4.1): a log statement that writes a card-number value. - PC-08 (medium, 3.5.1.1): a plain (unkeyed) hash of a card number. - PC-09 (medium, or low for 11-12 digits, 3.4.1): a masked number that shows more than the BIN and last four. - PC-10 (high, 4.2.1): payment traffic over http://. - PC-11 (high, 4.2.1): SSL or TLS 1.0/1.1 allowed. - PC-12 (medium, 4.2.1): certificate verification turned off. - PC-13 (medium, high when the answers say redirect or iframe, 12.5.2): a card field in your own page's markup. - PC-14 (medium, 6.4.3): a third-party script on a payment page without integrity=. - PC-15 (low, 6.4.3): a payment page and no Content-Security-Policy anywhere in the paste. - PC-16 (medium, 8.6.2): a secret, key or password written into the code. - PC-17 (medium, 2.2.2): a default or trivial password. - PC-18 (high, 4.2.1): card data in a URL query string. - PC-19 (high, 3.5.1): card data in browser storage or a cookie. - PC-20 (medium, 3.4.1): a whole request logged on a payment path. - PC-21 (medium, 8.3.6): a password minimum under 12 characters. - PC-22 (high, 12.5.2): server code that sends raw card fields to the processor (SAQ D). - PC-23 (medium, 3.5.1): card data kept in a server session or cache. - PC-00 (info): a processor-hosted component seen (Stripe Elements or Checkout, Braintree, Adyen, Square, PayPal, Checkout.com Frames, Authorize.net Accept.js). ## Output contract (the paid lanes) Every run input field is a string: `task` (`scope` or `review`), `facts` (JSON: the answers, the SAQ reading, files, components, flags), `code` (the masked paste), `description`, `note`, `scope_handoff` (review only), `retry_note`. The reply is one JSON object. - scope: `headline`, `saq`, `saq_agrees`, `saq_reason`, `level`, `level_note`, `channels[{channel, saq, why}]`, `components[{name, category: cde|connected|security|out_of_scope|third_party, why, evidence}]`, `data_flows[{step, data: PAN|PAN+SAD|token|masked|none, where}]`, `requirements[{req, applies: yes|no|check, why, evidence}]`, `reductions[]`, `flag_answers[{flag, status, reason}]`, `questions[]`, `summary`. - review: `verdict` (blocked|needs_work|ready), `headline`, `system`, `areas[{area: storage|transmission|software|access|logging, status: sound|fragile|broken, note}]`, `findings[{id, flags, req, file, line, severity, title, why, evidence, edits[{before, after}]}]`, `flag_answers`, `plan[]`, `questions[]`, `summary`. ## What it does not do - It reads text, not running systems: key vaults, WAFs, CSP headers set by a CDN and network segmentation are outside the check. - It is a guide, not an assessment: the acquirer assigns the level and accepts the SAQ; a QSA makes assessment decisions. - The model never sees a full card number, track data, a card code value or a secret value from the paste. ## Sources - Derived from the `pci-compliance` agent skill by Seth Hobson, github.com/wshobson/agents (MIT): https://skillsafe.ai/skill/@wshobson/pci-compliance - PCI DSS v4.0.1 and its Self-Assessment Questionnaires are published by the PCI Security Standards Council (pcisecuritystandards.org). Merchant levels follow Visa's published thresholds. - Runs on gpt-terra through SkillSafe (https://skillsafe.ai/).