PCI DSS for Customer-Facing Staff: Taking Card Payments Safely

If you take card payments at a reception desk, on the phone or across a counter, the Payment Card Industry Data Security Standard (PCI DSS) asks a few simple things of you: never write card details down, never keep the three-digit security code, check your card terminal for tampering, and report anything odd straight away. This guide turns those rules into everyday habits for finance receivables teams and clinic front-desk staff.

Why the people who take payments matter most

PCI DSS is the security standard that card brands require of any organisation that stores, processes or transmits cardholder data. The current version is PCI DSS v4.0.1, published in June 2024 (PCI Security Standards Council, 2024). Much of it covers systems and networks, but several requirements land squarely on the person holding the phone or the terminal. If you want the wider picture of what the standard means for your organisation, our overview of PCI DSS compliance for finance and accounting teams covers it. This post stays at the desk.

The risk is real at the point of payment. Across the European Economic Area, remote card payments (online, phone and mail order) made up only around 28% of card payment value in 2024, yet accounted for around 83% of card fraud (European Banking Authority and European Central Bank, 2025). Card-not-present payments are where criminals prefer to work, and phone payments are part of that picture.

Taking card payments over the phone

Phone payments are common in accounts receivable and in clinics collecting deposits or outstanding balances. The PCI Security Standards Council's guidance on telephone payments recommends keeping anything that could record card data, such as notepads and personal phones, out of the area where payments are taken (PCI Security Standards Council, 2018). In practice:

• Key the details straight into the approved system. Never jot the number down "just for a second", even if the system is slow.
• Do not repeat the full card number out loud where others in the office or waiting room can hear.
• Follow your call-recording procedure. If your organisation pauses recordings or uses a keypad-entry service so you never hear the digits, use it every time.
• If the line drops mid-payment, call back on the number held on file and start again. Do not keep the half-taken details.

Never write it down, never keep the security code

The three- or four-digit card verification code must not be stored once a payment has been authorised (PCI DSS v4.0.1, Requirement 3.3.1.2, 2024). That rules out sticky notes, spreadsheets, email drafts and "call back later" lists that include the code.

A few related rules are worth knowing:

• Screens should show no more than the opening bank identification digits and the last four digits of a card number, unless your role has a genuine business need to see more (Requirement 3.4.1).
• Card numbers must not travel unprotected by email, chat or text. PCI DSS requires strong encryption whenever a card number is sent using messaging technologies, including when a customer asks you to send it (Requirement 4.2.2). If a patient or client emails their card number, do not reply with it quoted; follow your organisation's process for deleting it and taking payment another way.
• Paper with card data must be cross-cut shredded, incinerated or pulped, and kept in a secure container until then (Requirement 9.4.6). Old paper authorisation forms in a drawer are a common finding.

Checking your card terminal for tampering

Card readers can be swapped or fitted with skimming overlays. PCI DSS requires organisations to keep a list of their payment devices, inspect them periodically and train staff to spot and report tampering (Requirement 9.5.1). The training must cover checking the identity of anyone claiming to be a repair or maintenance technician before they touch a device, not accepting replacement devices without verification, and reporting suspicious behaviour (Requirement 9.5.1.3).

A quick start-of-shift check might include:

• Is the device the one you expect, in the usual place, with the same serial number or asset label?
• Are there loose parts, extra layers over the keypad or card slot, unusual cables or broken seals?
• Has anyone you do not recognise asked to "service" or "update" the terminal?

If a visitor says they are from the payment provider, ask them to wait, then ring your manager or the provider on a number you already hold. A genuine engineer will not mind.

Spotting social engineering at the desk and on the phone

Since 31 March 2025, PCI DSS security awareness training must include phishing and social engineering (Requirement 12.6.3.1, 2024). For customer-facing teams, the common tricks look like this:

• A caller claiming to be from your bank or card processor asking you to "confirm" a recent transaction or read back card details.
• Someone pressing you to process a refund to a different card from the one used to pay.
• An urgent email asking you to update the payment link sent to customers.
• Pressure, flattery or a story designed to make you skip a step.

For more practical examples, see our guide to recognising phishing and social engineering. The rule of thumb is simple: slow down, verify through a channel you trust, and never let urgency override procedure.

What to do if something looks wrong

You do not need to investigate. You need to report quickly and preserve what you know.

1. Stop using the device or process you are worried about, if it is safe to do so.
2. Do not unplug, open or "fix" a terminal that may have been tampered with.
3. Tell your manager or the named security contact straight away, and note the time, what you saw and who was involved.
4. Do not contact the customer or caller about a suspected scam unless your procedure says to.

PCI DSS expects every organisation to have an incident response plan ready for suspected incidents (Requirement 12.10.1), so your report starts a process that already exists. Reporting a false alarm is always better than staying silent.

This guide is general information about PCI DSS and is not legal or compliance advice. Always follow your organisation's own payment procedures.

Frequently asked questions

Can I write down a card number if the system is down?

No. Ask the customer to call back, take payment another way, or follow your organisation's documented downtime procedure. Writing card details on paper creates stored card data that then has to be protected and securely destroyed.

Can a patient or client email me their card details?

They may try, but you should not process payments from an unencrypted email. Follow your process for deleting the message securely and offer an approved payment route instead.

How often should I check the card terminal?

Your organisation sets the frequency based on its own risk analysis, as PCI DSS v4.0.1 allows. Many teams build a quick visual check into opening up for the day. Ask your manager what your schedule is.

Does PCI DSS apply to healthcare clinics?

Yes, if the clinic accepts card payments. It sits alongside data protection rules such as the General Data Protection Regulation (GDPR), which covers the patient information you also handle.

Small habits at the point of payment do more to protect customers than any policy document on a shelf. If you want to build confidence in this and related areas, Learnsignal's compliance CPD courses offer practical, bite-sized learning for professionals who handle sensitive data every day.