Card-Data Responsibility Questions for POS Buyers

Sales demos can treat card security as a badge: the provider handles it, so the merchant can stop worrying. The PCI Security Standards Council says otherwise. Its guidance on outsourced processing warns that handing payments to a provider does not automatically mean the merchant has no responsibilities. The buyer's job is to find out, before signing, which ones are left. The rule below is evaluated against published criteria; this guide does not assess any merchant's setup or declare anyone compliant.

The walk-away rule

Two requests sort providers quickly.

First, ask for a written statement of which PCI DSS responsibilities the provider takes on and which remain with your business, for each way you take payments. A provider that has thought this through can produce it. One that answers with "we're PCI compliant, you're covered" has not answered the question.

Second, ask to see how its support team handles a payment problem: what a support agent can see, which reference numbers they ask for, and what they tell staff never to send. This should happen in a demo, before launch, not during a live incident.

If a provider will not do either one, walk away, however good the rest of the proposal looks. A missing answer now becomes your problem later, when a staff member under pressure photographs a receipt or types a card number into a chat window to get a refund unstuck.

Who decides your validation: your acquiring bank

The PCI DSS standard sets the requirements. It does not tell an individual merchant which form to fill in or how to prove compliance. That validation path runs through your acquiring bank, the bank that holds your merchant account, often through the processor acting for it. PCI SSC merchant resources help a business find its likely starting point, such as which self-assessment questionnaire might apply, but the acquiring bank and your actual setup decide.

So the order of questions matters. Get the provider's written split of responsibilities first. Then take it to your acquiring bank and ask: given this setup, what do you expect me to complete each year, and how do I submit it? If the POS provider and the acquiring bank are the same company, ask anyway, and get the answer from the part of the business that handles merchant compliance, not from sales.

Questions to ask, in plain words

Go channel by channel. For each way you take money (counter, phone or tablet, card typed in by hand, online, over the phone, a kiosk), ask:

• Where does the card number first enter: a card reader, a screen where staff type it, a web form, or a person reading it out loud?
• Can anyone on our staff ever see a full card number? If so, where, and why?
• Is the card number ever stored, printed, logged, or exported on any device or system we control?
• Which device, app, and network does this payment pass through, and who maintains each one?
• Which of our add-ons, such as online ordering, loyalty, or an accounting connector, touch payment data or the systems that carry it?
• If support needs to look at a payment, which reference do they use instead of the card number?
• If a reader is lost or a manager leaves, who removes access, and how quickly?
• When we add a location, a new device, or a new way to pay, who tells us whether our responsibilities changed?

Answers that point back to "the provider handles it" without saying how are the same as no answer.

A support case that goes wrong

A card payment shows as approved on the reader, but the order on the screen is still open. The guest is waiting. A server takes a photo of the screen, pastes details into a group chat, and calls two support lines. Nobody knows which number is safe to share, so people share everything.

The fix is decided before launch. Staff should know which reference to read out, what they must never photograph or type, who refunds, and which support team answers first. If the provider cannot show that flow in a demo, the walk-away rule applies.

Which arrangement to prefer

Between providers that both pass the walk-away rule, prefer the one where card data touches the fewest things you control. A setup where the card is read on the provider's device and your staff never see the number leaves fewer questions for you to answer than one where staff type card numbers into a tablet you maintain. Prefer the provider whose written split is specific to your channels over one that sends a generic document.

When this rule does not settle it

A clean written split from the provider does not cover what you add yourself. If you plan to take card numbers by phone and type them in, build custom software around the POS, or connect your own network gear, part of the setup sits outside anything the provider can vouch for. In that case the provider's answers are only half the picture, and the acquiring bank conversation, and possibly a qualified security assessor, matters more than any choice between POS products.

And if every provider on your shortlist fails the walk-away rule, none of them fits. Widen the shortlist rather than signing with the least evasive one.