To take a card payment over the phone, you log into a virtual terminal supplied by your payment processor, collect the customer’s card number, expiration date, CVV, and billing zip code, key the transaction into the terminal, and confirm the approval code on your screen. The mechanics take a couple of minutes. What sits behind them — PCI DSS rules, call recording restrictions, and the fact that you, not the bank, absorb fraud losses on these charges — deserves more of your attention than the keystrokes.
Phone payments are Card-Not-Present transactions. The card never touches a reader, and that classification shifts risk onto the merchant in ways swiped or chip sales do not.
Set Up a Virtual Terminal First
A virtual terminal is a secure, web-based application your payment processor provides. It works like a digital version of the card reader on a retail counter: you log into the processor’s portal from any internet-connected device and get fields for the card data, billing address, and amount. No special hardware.
Access usually comes with a merchant account from a processor that supports keyed-in transactions. Not every plan includes virtual terminal access by default. Some processors bundle it in; others charge a monthly fee. Confirm before you sign. The terminal typically lives inside your payment gateway dashboard, and the same login lets you view past transactions, issue refunds, and run reports.
What to Ask the Customer For
With the customer on the line and the terminal open, collect four items:
- The full card number printed on the front of the card, typically 16 digits.
- The expiration month and year.
- The CVV — the three-digit code on the back, or four digits on American Express. This code exists specifically for transactions where the card isn’t physically present.
- The billing zip code, which lets the system run an Address Verification Service (AVS) check against the zip on file with the issuer. A mismatch flags potential fraud.
You also need the cardholder’s name as it appears on the card and the total for the sale. Read the amount back to the customer before submitting. Keying the data while they’re still on the line means typos get caught immediately instead of turning into declines you have to chase down later.
Submit the Transaction and Read the Result
Clicking submit sends an encrypted request through the payment gateway to the customer’s issuing bank. The bank checks available credit, verifies the CVV, and compares billing information against its records. It takes a few seconds. A successful authorization returns an approval code on your screen. Record or save that code. It is your proof the bank approved the charge at that moment.
If the charge is declined, do not resubmit the same details repeatedly. Ask the customer to verify what they gave you, or offer to try a different card. Multiple failed attempts on the same card can trigger fraud alerts on the customer’s account and draw scrutiny from your processor. Once the approval clears, confirm it verbally and tell the customer the receipt is coming.
Funds do not hit your account instantly. Most processors batch settled transactions once per day, and the money typically arrives in your linked bank account within one to two business days.
What Your Receipt Can Show
Federal law limits what an electronically generated receipt can display. Under the Fair and Accurate Credit Transactions Act, no business that accepts credit or debit cards may print more than the last five digits of the card number or the expiration date on any receipt provided to the cardholder.1Office of the Law Revision Counsel. 15 U.S. Code 1681c – Requirements Relating to Information Contained in Consumer Reports Most processors default to showing only the last four digits, which satisfies the rule. Include your business name and contact information, the transaction date, and the total. Modern virtual terminals let you email or text receipts directly from the confirmation screen.
Keyed-in transactions cost more than swiped or chip-read payments because the processor treats them as higher risk. The per-transaction percentage is noticeably higher than for card-present sales, and some processors add a flat fee on top. Rates between processors on virtual terminal transactions vary, so it pays to compare.
PCI DSS Rules That Apply to Phone Payments
Every business that handles credit card data must comply with the Payment Card Industry Data Security Standard, regardless of volume or size.2PCI Security Standards Council. Merchant Resources The PCI Security Standards Council specifically identifies mail-order and telephone-order environments as needing evaluation and protection under PCI DSS.
Validation runs on a tiered system. Card brands set volume thresholds that determine which level applies. Most small businesses processing low volumes fall into the lowest tier, which typically requires completing an annual Self-Assessment Questionnaire rather than an on-site audit.3Mastercard. Revised PCI DSS Compliance Requirements for L2 Merchants Your acquiring bank or processor can tell you which level and SAQ type applies to your business.
The single most important rule for phone payments is this: never store the CVV after authorization. PCI DSS Requirement 3.2 flatly prohibits it, even encrypted.4PCI Security Standards Council. PCI Data Storage Dos and Donts No sticky note, no spreadsheet, no CRM field saved “for next time.” The code exists to prove the customer has the physical card during a single transaction. Once the charge clears, it has to be gone.5PCI Security Standards Council. FAQ – Can Card Verification Codes/Values Be Stored for Card-on-File or Recurring Transactions
Non-compliance carries real cost. Processors charge monthly non-compliance fees, commonly in the $20 to $100 range for small merchants who haven’t completed their SAQ or required scans. Larger or persistent violations can trigger escalating fines through the acquiring bank reaching tens of thousands of dollars per month. A serious breach can cost you the ability to accept cards at all, plus liability for forensic investigation and reissuing compromised cards.
If You Record Calls, Solve This Before Your First Payment
A recording that captures a customer reading their CVV aloud is, by definition, storage of sensitive authentication data after authorization. That violates the same Requirement 3.2 that bars writing the code down.6PCI Security Standards Council. Information Supplement – Protecting Telephone-Based Payment Card Data
The PCI Council’s guidance on telephone-based payments is direct: where technology exists to prevent the recording of sensitive data elements, enable it. Practically, that means a pause-and-resume feature that stops the recording during the payment portion of the call, or a system that automatically masks or suppresses the audio while card data is being collected. Asking employees to manually pause every time is fragile and audit-unfriendly. The Council specifically recommends asking your call center provider to explain how they remove sensitive authentication data from recordings automatically, without staff intervention.
Fraud Liability Sits With You
This is where phone payments part company with in-person sales, and where merchants most often underestimate their exposure. When a customer dips a chip card at a physical terminal, fraud liability generally shifts to the card issuer. Phone transactions offer no equivalent shield. Without a chip read, a PIN, or 3D Secure authentication, the merchant absorbs the loss on a fraudulent charge. A stolen card number used on a call turns into a chargeback that comes out of your revenue, not the bank’s.
You cannot eliminate the risk on phone orders. You can reduce it. Running the AVS check and collecting the CVV are baseline steps. Beyond that, keep detailed records of every phone transaction: who called, when, what they ordered, where it shipped, and any confirmation emails. Those records become your evidence when a chargeback lands.
Defending Chargebacks
Phone transactions attract two kinds of chargebacks: genuine fraud, where someone used a stolen card, and friendly fraud, where the actual cardholder disputes a charge they authorized. Both hit revenue the same way. You defend them differently.
For fraud disputes, Visa’s dispute guidelines allow merchants to submit a signed order form as compelling evidence for mail or phone order transactions. If merchandise was delivered, evidence showing it went to the address that matched your AVS check can also support your case.7Visa. Dispute Management Guidelines for Visa Merchants For repeat customers, showing prior undisputed transactions with matching phone numbers, email addresses, or delivery addresses strengthens the record.
For friendly fraud, Visa’s Compelling Evidence 3.0 framework lets you overturn invalid chargebacks with structured data. It works by matching at least two prior undisputed transactions, settled more than 120 days before the dispute, that share identifying details with the disputed charge.8Visa. Friendly Fraud Explained – Prevention and Solutions Good records from day one pay off months later.
Excessive chargebacks create a separate threat. If your Mastercard chargeback count in any single month exceeds 1% of your sales transactions and totals $5,000 or more, you meet the threshold for the MATCH list, a database of terminated merchants that stays on record for five years and makes opening a new merchant account with any processor difficult. PCI DSS non-compliance is also an independent reason for MATCH listing.
If You’re Calling Customers, the Telemarketing Sales Rule Applies
Outbound sales calls carry disclosure obligations that attach before you ask for a card number. Under the FTC’s Telemarketing Sales Rule, a telemarketer making an outbound sales call must promptly and truthfully identify the seller, state that the purpose of the call is to sell goods or services, and describe what is being offered.9Federal Trade Commission. Complying with the Telemarketing Sales Rule
Before the customer consents to pay, you must disclose the total cost, all material restrictions or conditions, and any no-refund policy. If you’re offering a subscription or negative-option feature, you must tell the customer their account will be charged unless they take specific steps to cancel, and explain those steps. Collecting payment information before making these disclosures violates the rule.
The TSR also imposes a five-year recordkeeping requirement. Sellers and telemarketers must retain records of each telemarketing call, including goods or services purchased, purchase date, amount paid, and all authorizations or consent records.10eCFR. Title 16, Part 310 – Telemarketing Sales Rule The rules apply even to a small business calling existing customers to settle an invoice. The FTC has authority to pursue civil penalties for violations.11Federal Trade Commission. Privacy and Security Enforcement
Consider a Payment Link Instead
If the compliance load and fraud exposure of keyed phone payments concerns you, payment links offer a middle path. Instead of the customer reading a card number aloud while you type it in, you send a secure link by email or text during the call. The customer clicks through, enters their own card details on a hosted payment page, and the transaction processes with stronger authentication built in, including 3D Secure verification that can shift fraud liability away from you and onto the card issuer.
The security advantage is straightforward. You never hear or handle the card number, which reduces your PCI compliance scope significantly. No card data touches your systems, your call recordings, or your employees’ screens. The customer’s information goes from their device to the payment processor directly. For businesses that regularly take phone orders, offering to send a link during the call can cut chargebacks, shrink PCI effort, and still close the sale in real time.
Payment links won’t work in every situation. Some customers prefer to pay immediately by voice, and some business models require instant confirmation before shipping or dispatching a service. Where a two-minute delay is acceptable, routing the payment through a link rather than a virtual terminal is the safer option for both sides of the call.