Is QuickBooks PCI compliant? Intuit's part, and the part in your books

The answer in Intuit's words

Intuit says yes, for its own products. Its Security Center states that “Intuit’s accounting offerings are PCI compliant and allow you to collect card payments from your customers.” The same page then turns to you: “If your business accepts, stores, or transmits payment card data, you have to be PCI compliant.” Set Intuit's sentence beside the one the standard itself uses:

A TPSP is a third-party service provider, and Intuit is yours the day you switch on QuickBooks Payments. The Intuit pages we read make no promise that you are spared any paperwork. Its terms put the job on you in plain words: “You must ensure you have data security policies and processes in place to protect cardholder and payor payment and personal data in compliance with PCI DSS and NACHA security requirements.” The NACHA half covers bank debits; what Nacha asks you to keep from a customer is on the ACH authorization form page. Compare all of that with how Square frames its own answer.

The proof you can check

You do not have to take a sentence on trust. Visa keeps a public registry of service providers that shows each one's PCI DSS validation, and Intuit's own PCI page links to it. When we searched it, these Intuit entries carried a PCI DSS validation:

What the registry does not tell you is which requirements Intuit handles for your setup and which stay with you. That lives in Intuit's Attestations of Compliance: its PCI page says “The links below give you access to our Attestations of Compliance, and Attestations of Validation,” and points to the Intuit compliance portal. When we opened its PCI section, it asked for an Intuit account sign-in.

How cards reach QuickBooks

The question that decides your paperwork is not “is QuickBooks compliant” but “whose hands touch the card number.” QuickBooks offers several ways in, and each one leaves you a different amount of work. Here they are in Intuit's words, with where each points you:

Two patterns stand out. When the customer types the number into Intuit's page, it never passes through your hands. When you type it, you are the one handling it, and the rules for that are stricter. Intuit's in-person payments page adds a line about the phone itself: “Apple doesn’t store card numbers on your iPhone or on Apple servers.” If you use more than one way in, the SAQ type finder sorts the mix in a few questions.

Keying cards in: the SAQ C-VT test

Phone orders are where QuickBooks users most often handle card numbers. The Council wrote one questionnaire for exactly this, SAQ C-VT: “Merchants that manually enter payment account data a single transaction at a time via a keyboard into a PCI DSS validated and compliant third-party virtual payment terminal solution, with an isolated computing device and a securely connected web browser. No electronic account data storage.” Its criteria are strict, and they read differently for the two versions of QuickBooks:

The Desktop column is not a verdict on Intuit. It is what the Council's wording says: C-VT is built around a web browser, and Intuit's Desktop help tells you to “Connect the card reader to the computer with the provided USB cable,” which is the exact thing the criteria rule out. If you key cards in Desktop, ask Intuit in writing which SAQ it expects, and keep the reply. The virtual terminal comparison shows how other providers map keyed payments.

Card numbers in the books

Here is the risk nobody sells you a product for. QuickBooks is accounting software first, so it is full of free text: memos, notes, attachments. A card number typed into any of them sits there in plain sight, and in any report or backup made while it is there. That is the one thing the standard is firmest about: “PAN is rendered unreadable anywhere it is stored.” And the security code may never be kept at all: “The card verification code is not stored upon completion of the authorization process.”

Intuit's terms say the same in their own words: “You may not retain or store magnetic stripe or CVV2, CVC2, or CID data after authorization.” The sweep below walks the places numbers hide in a set of books. It never asks you to type a card number; you look in your own file.

A clean file also keeps your questionnaire short. SAQ C-VT and SAQ C both describe merchants with “no electronic account data storage”; one number left in a memo is enough to break that. If you do need to keep cards for repeat billing, our guide on how to store credit card information explains why a processor's token beats your own copy.

If you keep someone else's books

Bookkeepers and accountants sit in an odd spot. The business that takes the cards is the merchant, and the compliance is theirs. But if you can see their card data, or change the systems that hold it, you are part of their picture. Requirement 12.8.1 asks every merchant to keep “A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data.” Intuit's terms go further for its own merchants:

The simplest way to stay out of that is never to handle a client's card numbers. Do not take them by phone on the client's behalf, do not accept them by email, and clear any you find while you work. If a client asks you to run their cards, that is a business decision with paperwork attached: you would sit on their provider list, and Intuit's terms say such agents are registered and Intuit is told about them.

What stays yours

Whatever Intuit covers, these stay on your side of the line. None of them takes long once it is a habit.

Quick reference

Questions