Taking Card Payments in the Field Without Exposing Card Data

Why this matters

Most card data that leaks out of a small shop does not leak from a hacked server. It leaks from a sticky note on a dashboard, a work order with sixteen digits in the margin, a photo of a card a customer texted the tech, or a voicemail from someone reading their number slowly so the office can write it down. Each of those is a stolen card waiting to happen, and each one also drags your whole operation into the part of the card industry's rules you were trying to stay out of. Field payments can be fast and clean at the same time. The trick is that the card number should go from the customer to your processor and touch nothing of yours on the way.

What "scope" means, in two paragraphs

The card industry's security standard, PCI DSS (the Payment Card Industry Data Security Standard), applies to anything that stores, processes or transmits cardholder data, or could affect the security of something that does. That set of people, devices, papers and processes is called your scope. The bigger it is, the more of the standard you have to meet and attest to each year. When a customer taps or dips their own card on a reader supplied by your processor, and the reader encrypts the number before it ever reaches your phone, the card data passes through your hands as an unreadable blob, and your scope stays small: mostly the reader itself, the habits of the people using it, and your processor's paperwork.

The moment someone writes a card number down, types it into a notes field, or saves a photo of it, that paper, that field and that phone are now storing cardholder data, and they are in scope. So is the truck the clipboard rides in, the office file the ticket lands in, and the cloud backup of the phone's camera roll. One habit can turn a shop that answers a short questionnaire into one that is supposed to be protecting stored card data. And the card security code, the three or four digits on the back, may never be stored after authorization in any form, encrypted or not. See related: PCI Compliance Explained for a Small Shop.

The field habits, as steps

1. Make the processor's flow the only flow

Pick one way of taking a card in the field and give every tech the same one: a card reader from your processor paired to the work phone or tablet, the processor's tap-to-pay feature on the phone itself where it supports it, or a payment link sent to the customer. Set it up before the busy season, not on a job.

Why: a tech improvises when the official method is missing, broken or unfamiliar, and improvisation is how numbers get written down. What breaks if you skip it: the first time a reader's battery is dead, the tech asks the customer to read the card aloud and copies it onto the ticket "for the office to run later".

2. Hand the card to the reader, not the reader to your hand

The customer taps, dips or swipes their own card. The tech does not take the card out of the room, does not carry it to the truck, and does not turn the screen away while it processes. On a reader that prompts for a PIN or a signature, the customer enters it.

Why: a card out of the customer's sight is how skimming accusations start, true or not, and a tap-capable card never needs to leave their hand. What breaks: a customer whose card is later compromised elsewhere remembers the tech walking off with it.

3. Never write a card number down, anywhere, for any reason

Not on the work order, not on a sticky note, not on a hand, not in the job notes in your field-service software, not in the "payment info" field some systems still have. If the office needs to run a card later, the answer is a payment link sent to the customer, not a number carried back.

Why: paper and free-text fields are the two places card data gets stored most often in small shops, and neither has the controls the standard requires for stored data. What breaks: the paper lives on in a clipboard, a filing box and a truck, and a free-text field shows up on every printed ticket and every export, visible to everyone with a login.

4. Never take a card number by text, email, photo or voicemail

When a customer sends a photo of their card or texts the number, the tech replies with the payment link and deletes the message and the photo. Deleting is not enough on its own: tell the customer you have deleted it and that they should delete their copy too, because the message now sits on their phone, your phone, the carrier's systems and any cloud backup on either end.

Why: these channels keep copies in places you cannot reach or purge. What breaks: a lost or synced phone hands someone a camera roll with cards in it. See related: The Lost or Stolen Field Device SOP.

5. When the payer is not there, send them the link

The adult child paying for a parent's repair, the landlord paying for a tenant's call: send a payment link from the processor to the payer's email or phone. If the processor's app genuinely requires keying a number the payer reads over the phone, the tech keys it directly into that app as it is read, does not repeat the digits aloud, and does it out of earshot of others in the house.

Why: a link keeps the number out of your hands entirely and lets the processor authenticate the cardholder where it supports that; keying a number read aloud is a card-not-present transaction with the fraud risk that carries. See related: Card-Not-Present Fraud on Phone Bookings. What breaks: a number read on speaker in a kitchen is heard by whoever is in the kitchen.

6. Let the processor send the receipt

Use the processor's emailed or texted receipt, which shows only the last four digits. Do not write card details onto your own invoice or job ticket, and do not photograph the reader's screen or the customer's card to "prove" the payment.

Why: the transaction ID and the last four are all you ever need to find a payment later. What breaks: a homemade proof-of-payment photo is stored card data with a timestamp.

7. Know what offline mode does before you use it

Some readers can accept payments without a signal and send them later. That convenience has a cost: the reader cannot check the card at the time, so a declined or stolen card is only discovered when the batch uploads, after the tech has left. If your reader has an offline mode, set a shop default for it, a sensible starting point being off, or capped at the price of a service call, and require techs to get back in signal and confirm the payment cleared before close of day.

Why: offline payments are approved by your hope, not by the card issuer. What breaks: a full replacement collected offline on a card that declines at upload, with the customer now unreachable.

8. Lock the device the reader lives on

The work phone or tablet that runs the payment app needs a passcode, automatic screen lock within a minute or two, and the ability for the office to locate and wipe it remotely. The reader itself goes in the truck's locked compartment overnight, not on the seat.

Why: a phone that unlocks with a swipe lets anyone issue refunds from the payment app. What breaks: a stolen unlocked phone becomes a refund machine against your account. See related: Setting Up Field Phones and Tablets So a Lost One Is a Nonevent.

A worked example

A shop with 12 field techs ran a one-afternoon sweep before its annual questionnaire, checking every truck clipboard, every work phone's photos and messages, and the job notes field for anything that looked like a card number. The sweep found:

• 3 paper work orders with full card numbers in the margin, two of them with the three-digit security code beside it,
• 2 card photos in work-phone camera rolls, both sent by customers, one already synced to the shop's cloud photo backup,
• 1 text thread with a number typed out,
• 4 job records in the field-service software with a card number in the notes.

That is 10 instances across 12 techs. Every one of them was data the shop was storing and had no business storing, and the two security codes were a flat violation of the rule that security codes are never stored after authorization.

The trace came down to three causes. The three paper orders and the text thread all came from two techs whose readers had failed months earlier and had never been replaced, which is step 1. The two photos were customers sending them unprompted, which step 4 handles. The four notes-field entries came from the office, which had been taking numbers by phone for repeat customers and parking them "for next time", which is step 3 and a habit the office had never been told was a problem.

The fix took a week. Cross-cut shred the paper. Delete the photos from the phones, from the cloud backup and from its trash folder. Delete the text thread on the work phone and ask the customer to delete theirs. Edit the four notes, and ask the software vendor whether edited notes are kept in a version history and how to purge it. Replace the two readers. And switch repeat customers to the processor's card-on-file feature, which stores a token the processor issues, not the number, so the office can charge an authorized customer again without ever holding the card. See related: Getting the Card on File.

What would change the answer. If any of those numbers had been used fraudulently, or the shop had reason to think the photos had been seen by someone outside, this stops being a cleanup and becomes a possible breach, with your processor to notify and, depending on your state and what else was exposed, possibly customers too. That fork belongs to the breach SOP and an attorney. See related: The First Hour After a Suspected Breach SOP.

How to verify you got this right

Repeat the sweep once a year, on a day nobody is warned about, and compare counts. The target is zero, and the useful number is not the total but the cause behind each one: a reader that failed, an office habit, a new tech who was never shown. Add one line to new-hire training: "We never write down, text, photograph or store a card number. If the reader will not work, call the office for a link." Then make sure the office has a link to send.

References

• PCI Security Standards Council, PCI DSS, requirement on not storing sensitive authentication data after authorization
• Your processor's documentation for its reader, tap-to-pay, payment links, card-on-file tokens and offline mode
• See related: PCI Compliance Explained for a Small Shop
• See related: Card-Not-Present Fraud on Phone Bookings
• See related: Setting Up Field Phones and Tablets So a Lost One Is a Nonevent