SAQ B-IP: who qualifies, what it covers, and how to confirm it

Most merchants land in SAQ B-IP the ordinary way: the old dial-up terminal got replaced with one that uses the store’s internet connection, and nobody mentioned that the questionnaire changed too. The setup still feels simple, a box on the counter that takes cards, but the transaction now rides your network, and PCI DSS accounts for that.

Who SAQ B-IP fits

SAQ B-IP is one of the eight PCI DSS Self-Assessment Questionnaires published by the PCI Security Standards Council (PCI SSC). Completing one ends in a signed Attestation of Compliance (AOC) that goes to your acquiring bank or the card brands. B-IP is the version for merchants whose entire card operation is standalone payment hardware talking to the processor over a network. It tends to sound like this:

• “The terminals are on the broadband.” A café’s countertop terminal sends each transaction straight to the processor over the shop’s internet connection. No POS software ever touches the card.
• “We upgraded from dial-up years ago.” A hardware store swapped its phone-line terminals for Ethernet models and changed nothing else about how it takes cards.
• “Three lanes, three terminals, each on its own.” A grocer’s standalone terminals each talk to the processor directly; staff key the amount into the terminal itself.
• “Pay-at-table, same idea.” A restaurant’s wireless terminal rides the local network to the processor, standalone all the way.

The common thread: cardholder data moves from the customer’s card to a PTS-approved standalone device to the processor over an IP connection. Your computers never see it, no payment software runs in your environment, and nothing stores card numbers electronically. If that’s not quite your picture, the guide to all 8 SAQ types maps every acceptance pattern to its questionnaire.

The exact eligibility criteria

Per the PCI SSC’s SAQ Instructions and Guidelines for PCI DSS v4.0, SAQ B-IP is for merchants using only standalone, PTS-approved terminals with an IP connection to the payment processor, with no electronic storage of cardholder data. Each term earns its place:

• Only. Every card channel you have, across every location. Add a website checkout or a keyed virtual-terminal payment and your environment spans more than this one questionnaire.
• Standalone. The terminal is not connected to any other system you run: no POS integration, no inventory link, no back-office software. It talks to the processor and to nothing else.
• PTS-approved. The terminal model is validated under the PCI SSC’s PTS program (PIN Transaction Security) and appears on the Council’s approved-devices list. Your processor or terminal supplier can confirm your model’s status, and it’s worth getting that in writing, because the questionnaire is written around approved hardware.
• IP connection. Transactions travel to the processor over a network connection rather than a dial-out telephone line. That transport difference is the entire boundary with SAQ B.
• No electronic storage of cardholder data. No database, no spreadsheet, no card numbers in files, logs, or recordings. Paper receipts are expected and must be protected, but paper isn’t electronic storage.

The SAQ B-IP document opens with an eligibility checklist you attest to item by item, including how the terminals are set up and connected. Answer it against how things actually are, because your signature on the AOC says the checklist is true.

What disqualifies you: the adjacent-SAQ traps

SAQ B-IP has neighbors on both sides, and the differences are specific. Five things to check before you attest:

The terminal dials out over a phone line: that’s SAQ B

The boundary between SAQ B and SAQ B-IP is the connection type, nothing more. If the terminal reaches the processor over a telephone line rather than your network, SAQ B is the questionnaire written for it, and it carries less network-facing content because there’s no network in the card’s path. Mixed fleet? A dial-out terminal at one counter and an IP terminal at another is a multi-SAQ conversation for your acquiring bank.

Payment software in the path: that’s SAQ C territory

SAQ B-IP is hardware talking to the processor. The moment card processing runs through a payment-application system connected to the internet, POS software on a till, a checkout app on a tablet or PC, you’re describing SAQ C, not B-IP. Integration is the tell: a terminal wired into your POS is no longer standalone, and “standalone” is the load-bearing word in B-IP’s eligibility.

The device isn’t PTS-approved, or you can’t show that it is

B-IP’s eligibility is written around PTS-approved hardware. If the model can’t be matched to the PCI SSC’s approved-devices list, ask your processor before attesting. An aging or unbranded device is exactly the case to confirm rather than assume.

Your terminals are part of a P2PE solution: different door

If your terminals belong to a point-to-point encryption solution listed by the PCI SSC and you have no access to clear-text cardholder data, SAQ P2PE is the questionnaire written for that arrangement. It’s less a trap than an adjacent door: listed P2PE solution, P2PE questionnaire.

Other channels, or anything stored electronically

A checkout page on your website points to SAQ A or SAQ A-EP; keyed phone orders point to SAQ C-VT; more than one channel can mean your validation spans more than one SAQ. And the override that outranks all of it: if any system you control stores cardholder data electronically, a database, a spreadsheet, an app log, a call recording, the reduced SAQs are off the table and SAQ D generally applies.

What you answer, at a high level

Every SAQ draws from the same standard: the 12 PCI DSS requirements, organized under six goals (secure networks and systems, protect account data, vulnerability management, access control, monitoring and testing, and an information security policy). You’re validating against PCI DSS v4.0: v3.2.1 retired on March 31, 2024, and v4.0’s future-dated requirements became mandatory on March 31, 2025.

Compared with SAQ B, expect more network-facing content, because your terminals live on a network: how they connect, how that connection is protected, and how the terminal environment is kept separate from everything else you run. Alongside it, the same physical-world material:

• The terminals. Where the devices sit, and periodic checks that nobody has tampered with them or swapped one for a lookalike.
• The connection. How the terminals reach the processor and what keeps that traffic apart from your office computers, guest Wi-Fi, and everything else.
• The paper. Receipts with card data: where they live, who can reach them, how long you keep them, how they’re destroyed.
• The people. Who may use the terminals and handle card data, kept to those whose job needs it.
• The providers and the policy. Which third parties touch cardholder data on your behalf, with responsibilities in writing, and a security policy that matches what you actually do.

We don’t quote question counts, because the exact set varies by SAQ version. The honest summary: B-IP asks more than SAQ B because a network is involved, and far less than SAQ D, because you run no payment software and store nothing.

How to confirm SAQ B-IP is yours

Eligibility is defined by the PCI SSC, but the confirmation isn’t yours to make alone. Your acquiring bank or the card brands assign your validation level from your annual card volume and confirm which questionnaire they’ll accept. Most small and mid-size merchants validate with an SAQ; the highest-volume merchants go through a QSA-led Report on Compliance instead.

If your setup has an ambiguous edge, a terminal you can’t match to the approved list, a network you’re not sure counts as separate, a Qualified Security Assessor can rule on it formally. And if you want a defensible starting point before either conversation, our free check asks how you accept cards and computes your likely SAQ on screen in about two minutes, no email needed to see the result. It’s indicative, not a QSA assessment, and it’s built to make the bank conversation shorter.

Frequently asked questions

Related guides