7 min read

6 ways of taking card payments over the phone safely

Featured Image

Ecommerce liberated buyers giving them convenience and power to avoid pushy sellers. And yet even tech-savvy consumers have fallen back in love with human contact.

In today’s ever more frenetic, time-pressured life, service matters more than ever.

Giving impatient buyers the ability to contact you when they can’t find what they want, need advice or simply want to act fast, and then place an order, can differentiate your service. 

Taking card payments over the phone raises a new set of security and compliance and challenges. The old way of asking the customer to read out their card details is no longer practical and liable to lead to fines and disaffected customers.

  • How to take a card payment over the phone without introducing unnecessary cost and complexity into your customer-service operations?
  • What are the security and compliance issues to be aware of
  • How do different methods help or hinder?

In this article  we look at six different technology solutions for taking card payments over the phone securely and their advantages and disadvantages. First though let us consider the security requirements.


The security imperative


The protection of consumer payment-card data when making payments is underpinned by the Payment-Card Industry Data-Security Standards, or PCI DSS.

PCI DSS was first published in 2006 by the major card-issuing brands to counter growth in fraud from remote card payments. The standards provide a common set of security requirements for anyone involved in capturing, transmitting and storing card data — from merchant to payment intermediaries and the merchant’s bank. Failure to comply with PCI DSS can lead to substantial fines from your merchant bank, which can range from $5,000 to $100,000 a month.

Arguably of greater significance is consumer attitudes to fraud and the need to protect their card data.

According to a 2022 survey by payment-security specialists Entrust, 90% of consumers are concerned about the potential of banking or credit fraud as both become more digital. For good reason too. In their 2021 Identity Fraud Study, research firm Javelin, estimated that world-wide identity-fraud losses reached $56 billion in 2020. A figure that excludes indirect costs such as damaged reputations or remediation effort.

Set against this, the old way of taking phone payments — by requiring cardholders to read out their details to strangers — is increasingly likely to result in disaffected customers.


Six solutions


There are six secure options available for taking card payments over the phone

  1. Use your business POS machine
  2. Use a virtual terminal in a secure environment
  3. Pause and resume
  4. Fully automated IVR
  5. DTMF masking
  6. Channel separation
  7. Payment links

1. Use your business POS machine

Most businesses have a Point of Sale machine (POS). In fact, whenever you order a meal from your local takeaway over the phone, they will likely ask you to read out your card number so they can type your card details into the POS machine. 

Because the customer is required to read out their card details to the agent, this process is fundamentally flawed from a PCI DSS-compliance perspective unless draconian measures are taken to train and supervise staff, and place payment takers in ‘clean rooms’ with no ability to record information digitally or with pen and paper. This is impossible in some industries, like takeaways, as they will be likely writing down your order onto a piece of paper. Then they could feasibly write down your credit card number as they read it over the phone.


  • Not PCI-DSS or GDPR compliant
  • Liable for non-compliance fines direct from your bank.
  • High chance of fraudulent activity from staff or customers.


  • None


2. Virtual terminal in a secure environment

All payment service providers provide a “virtual terminal” for merchants — a user interface for customer-service agents to manually type a payment on behalf of their customer.

Like taking payments with a POS machine, taking payments with a Virtual Terminal is fundamentally flawed from a PCI DSS-compliance perspective unless draconian measures are taken to train and supervise staff, and place payment takers in ‘clean rooms’ with no ability to record information digitally or with pen and paper. This means restricting the computer applications available,


  • Expensive to set up
  • Inefficient use of office space
  • Unviable for home working
  • Inefficient except for largest contact centers: agents can;t multi-task for example


  • None

3. Pause and resume

Although this is often cited as an option for enabling compliance with PCI DSS, it is only a partial solution, used in conjunction with method 1. 

The term refers to the pausing — and subsequent resumption — of call recording during the point in a conversation when the customer reads out their card details. This prevents spoken card data from being stored on recordings.


  • Partial fix only
  • Removes the ability to audit or supervise calls at a critical point in a call
  • In practice data can ‘leak’ outside of the paused period


  • None

4. Fully automated IVR

Callers are forwarded to a fully automated “interactive voice response” system that takes them through a series of automated prompts to submit card data and complete the payment. An IVR is used at the end of a call or when no agent is involved at all.


  • Efficiency: Removes the need for any human involvement
  • Lends itself well to simple, low-value payments, such as cinema tickets


  • Reliant solely on the customer completing the process — No opportunity to intervene if something goes awry
  • Any failure to complete a payment is only apparent after the customer hangs up
  • Can be frustrating for customers that still want that human support 

5. DTMF-masking

This process was developed and patented by Semafone ten years ago, and now used by a number of providers including PCIPal and Eckoh. 

The caller and agent remain in touch throughout the payment process. The agent instructs the customer to use their keypad to submit the various card data strings. DTMF tones are masked to obscure the numbers by creating a single tonal pitch that is heard by the calling parties.


  • A long-established solution used in many large call centres
  • A seamless experience for customers


  • Data leakage: because the agent and customer can talk during card submission, there is a danger that either customers inadvertently read out their card numbers or unscrupulous staff ask them to. This not only exposes data to the agent, but gets captured by call-recording systems in operation — which in turn creates a breach of PCI DSS
  • Training: although the process is relatively simple, it does require agents to be trained to use the solution. This may be fine for high-volume contact centres, but less suitable for multi-disciplinary staff taking occasional payments.

6. Channel separation

A patent-pending process developed by Paytia, “channel separation” developed in response to security and ease-of-use concerns raised by DTMF-masking. 

At the point of payment customer and merchant lines are separated so that neither party can speak to the other. An automated payment assistant then guides both sides through payment confirmation, card submission and authorization process. Customer and merchant can interrupt the process at any time to speak to the other person if required.


  • There is no risk of ‘data leakage’: because merchant and customer phone channels are separated during card submission
  • Little or no training is required making it ideally suited to a wide variety of use cases 


  • None


7. Payment links

A popular solution is sending customers website links to secure payment pages that can be fully or partially completed based on the information that was agreed or collected during the customer-agent phone call.

Payment links can be sent via email, text message, over chat or by QR code.


  • Simple solution
  • Works well where the customer can’t talk or wants to pay after a call


  • Requires the customer to have web access and have the ability to use it
  • Creates the opportunity for a post-call payment which creates risk the customer will not proceed with the payment/purchase
  • Harder to resolve payment issues when they go wrong since real-time verification of card details and authorization of payment is typically unavailable to the agent during the call 

Other considerations


Cloud versus on-premise applications


Cloud has become universally accepted as the defacto deployment mode for most business applications and use cases. In the case of taking card payments over the phone, this is especially so, since it abstracts the merchant’s systems entirely from the payment process and thereby reduces their compliance obligations.

Nonetheless, it is important to highlight that not all cloud deployments are the same. Applications that have been developed from the ground up to run on cloud infrastructure — sometimes referred to as “cloud-native” — are more likely to perform and scale better than legacy on-premise applications that are retrofitted for cloud deployment.


Ease of deployment


Cost and ease of deployment varies significantly across products.

Long-established providers have focussed on serving contact centers — large complex implementations, often involving significant bespoke development or configuration. This translates into expensive set up costs and minimum users.


PCI DSS accreditation


All the major providers are independently certified to PCI DSS Level-1, which means that they have been assessed and approved as suitable for high-volume payment handling.

Although you should expect this as a given, it is worth checking that this is the case, particularly if you choose a new or unknown product. Without this certification you are unable to delegate your own compliance responsibilities to your technology provider.