Taking Card Payments by Phone Safely: Virtual Terminals, Paper, and What Not to Write Down

November 13, 2026 · Compliance Assessment Tool

Short answer. If you take card payments by phone, the safest habit is simple: enter the card details straight into your payment provider’s virtual terminal and do not keep the card number, security code, or sensitive notes on paper, in email, or in chat. Most small businesses get into trouble not because they meant to store card data, but because everyday workarounds quietly turn into storage.

Phone payments feel simple, but the risks are usually in the routine

For many small businesses, taking a card payment by phone feels normal. A customer calls, a staff member opens a browser, types the details into a virtual terminal, confirms the payment, and moves on. The process is quick, but the weak point is often what happens before or after the payment.

Problems usually start with convenience. Someone writes the card number on a sticky note to process later, leaves a voicemail with card details in the inbox, copies the number into a text message for a colleague, or keeps a paper order form “just in case.” Those habits can turn a simple phone payment into a bigger PCI DSS problem.

A useful rule is this: if card details come to your business by phone, the goal is to use them once for the payment and not retain them anywhere you do not need to. That means no notebooks, no email drafts, no chat threads, and no photos of order forms.

Use a browser-based virtual terminal provided by your payment provider when taking phone payments.
Train staff to enter the details during the call rather than writing them down for later.
Check voicemails, call recordings, order sheets, and inboxes for places card data may be lingering.
Review your process for refunds, recurring charges, and missed callbacks so staff do not create their own workarounds.

What a virtual terminal is, and why it matters

A virtual terminal is typically a web page from your payment provider where a staff member types card details on behalf of the customer. This is common for mail order and telephone order businesses, service businesses, medical and professional offices, and any merchant that does not have the customer present with a card reader.

That setup matters for PCI because it is different from an online checkout where the customer types their own card details. It is also different from a countertop terminal. Even if all you do is “type it into a website,” the compliance path can be different depending on how the payment is taken.

Small businesses often assume phone payments are low-risk because the card is not stored in their shopping cart or website. But if staff hear the card number, write it down, or handle it in a browser session, the way you validate compliance can change. If you are unsure which questionnaire applies, start with a plain-English guide like Which SAQ do I need?.

A virtual terminal is for staff-entered card payments, usually in a browser.
It is commonly used for telephone orders and mail orders.
It is not the same as a customer-facing hosted checkout or payment page.
The way you take the payment affects which SAQ type may apply.

What not to write down

The safest answer is: do not write down card details unless your process absolutely requires it, and then redesign that process. In everyday small-business operations, paper is often the biggest blind spot because it feels temporary and harmless. It rarely is.

Do not write the full card number on appointment books, intake forms, job tickets, catering sheets, reservation logs, or callback lists. Do not jot the security code on the corner of a document. Do not keep a note with the cardholder name, expiry date, and card number together so you can “run it later.”

Also look beyond paper. A note in a CRM free-text field, an email to accounting, a screenshot saved to a desktop, or a message sent in team chat is still storage. If a staff member can come back later and read the card details, then the business has retained the data.

Call recordings need special attention. If your phone system records calls for quality or training, and customers read card numbers aloud, those recordings may capture account data. That is the kind of operational detail many small businesses miss until someone maps the process end to end.

Do not keep full card numbers on paper forms or notebooks.
Do not store card details in email, text, chat, spreadsheets, or CRM notes.
Do not ask staff to collect card details and process them later from memory aids or handwritten notes.
Review whether call recording, voicemail, or support tickets capture card data.

A safer process for taking payments by phone

The cleanest process is usually the best one. When the customer is on the phone, the staff member opens the payment provider’s virtual terminal, enters the details directly, submits the payment, and then confirms the result. Nothing is copied elsewhere, and no paper record of the card details is kept.

If the customer is not ready, avoid asking them to leave card details by voicemail or email. Instead, ask them to call back when they are ready to pay, or use another payment method your provider supports. The main goal is to avoid creating a second system outside the payment provider where card data sits unattended.

Give staff a short script for edge cases. For example: “For your security, please do not email or text your card number. I can take the payment now over the phone, or you can call back when you are ready.” A simple script prevents well-meaning staff from improvising.

If you use more than one way to accept cards, document each one separately. A business might have an in-person terminal at the counter and also take payments by phone through a virtual terminal. Those are different payment methods, and they should be reviewed as such. The PCI SSC document library is a good source for the official documents at PCI SSC Document Library.

Take the payment live during the call whenever possible.
Do not accept card details by voicemail, email, or text.
Give staff a clear script so they know how to redirect customers safely.
Map each payment method separately if your business accepts cards in more than one way.

Why small businesses often end up with the wrong PCI questionnaire

Many merchants are handed a questionnaire without much explanation. The result is predictable: some get a questionnaire that is far too broad for their actual payment process, while others answer a shorter one without realizing their day-to-day handling of card data points somewhere else.

Phone payments are a common source of confusion. A business may think, “We only key payments into a website,” but the real question is how the card data reaches that website and what happens around the transaction. If staff are taking the number by phone and typing it into a virtual terminal, that is a specific scenario and should be assessed accurately.

This is where plain-English intake matters. At CAT, merchants describe how they take payments in their own words, and the system determines which of the 9 SAQ types applies, asking a follow-up question in plain English when needed. Each question is then written for that business and payment method, and when the merchant finishes, they can review, sign digitally, and get the official SAQ and AoC PDFs filled in.

If you are trying to understand the compliance side of your process before you start, PCI compliance by type of business and The PCI non-compliance fee are useful background reading.

The right SAQ depends on how you actually take payments, not on what the process is called internally.
Phone payments through a virtual terminal are often misunderstood.
A process review should include staff habits, paper forms, recordings, and follow-up workflows.
One business can have more than one payment method, and each may need separate attention.

Make the process easier for staff, not just stricter

Most unsafe phone-payment habits are process problems, not bad intentions. Staff write details down because they are busy, the customer is rushing, the internet is slow, or the payment needs approval from someone else. A policy that says “never do this” is not enough unless the safer method is also the easiest one.

Start with a short written procedure. Show staff exactly where to enter phone payments, what they should say if a customer tries to email a card number, what to do with old paper forms, and who to ask when they are unsure. Then test the process as if you were a customer calling in.

If you are an ISO, PayFac, bank, or platform that wants to build this into your own merchant experience, CAT is an API for PCI compliance with four ways to integrate: REST API, MCP server, embeddable iframe, or a platform redirect. You can see the overview at PCI compliance API overview and start with a Free sandbox.

Make the approved way the fastest way for staff to take a payment.
Use a short script and a short procedure, not a long policy nobody reads.
Check old files, shared inboxes, and recordings for leftover card data.
If you support merchants at scale, build PCI into your own workflow instead of sending merchants to a separate process.

Common questions

Can I write down a card number during a phone call and shred it later?

That is a common habit, but it is still a risky one because the card data exists on paper outside the payment system, even if only for a short time. A better process is to enter the details directly into the virtual terminal during the call and avoid creating a paper record in the first place.

Is a virtual terminal the same as my online checkout?

No. In an online checkout, the customer usually enters their own payment details. In a virtual terminal, your staff member types the card details into the payment provider’s page on the customer’s behalf, and that difference can affect PCI validation.

What if a customer emails or texts their card details anyway?

Your staff should not use the card details from that message as a normal routine. Have a process to contact the customer and take payment through the proper channel, and make sure staff know not to encourage email or text for card data in the future.

Do phone payments always mean the same SAQ type?

Not always. The right SAQ depends on the actual payment method and how card data is handled in practice. The acquirer decides which SAQ a merchant must file, so it is important to describe the process accurately.

What if my business takes cards in person and by phone?

Treat those as separate payment methods when you review PCI scope. A countertop terminal and a browser-based virtual terminal are not the same flow, and a business may need to consider each one on its own.

An API for PCI compliance

Give every merchant the right SAQ, in plain English, under your brand — by REST API, MCP, iframe or redirect. $25 per completed assessment.

Get a free sandbox → How the API works

More from the blog

General information, not legal advice. Your acquirer decides which SAQ a merchant must file. PCI DSS v4.0.1.