For many organizations, accepting credit card payments over the phone is simply part of doing business.
A customer calls. An employee pulls up the account, confirms the amount owing, asks for the card number and other payment information, enters those details into a payment application, waits for an authorization and then confirms the result with the customer.
From the outside, it looks like a fairly simple transaction.
But when we examine that interaction through the Payment Flow Intelligence Framework™, a much more interesting question emerges:
Why does the employee need to be part of the card data flow at all?
That question matters because the employee may be providing real value during the conversation with the customer. They may be answering questions, helping resolve an account issue, explaining a balance, or working through a payment arrangement.
But none of those activities necessarily require the employee to hear, see or enter the customer’s card information.
That distinction is important.
Looking Beyond the Transaction
One of the reasons payment processes become complicated is that organizations tend to look at the transaction itself rather than the entire workflow surrounding it.
A phone payment is rarely just a payment.
There is usually a customer interaction before the transaction, payment information being captured somewhere, one or more systems involved in processing or recording the transaction, an authorization coming back, and often additional work occurring afterward.
Over time, these processes evolve.
An employee may originally have been required to take card information because that was simply how the payment system worked. A terminal may have been sitting on someone’s desk. Later, a browser-based payment application may have replaced the terminal, but the underlying workflow remained almost exactly the same.
The technology changed, but the payment flow did not.
That is why examining how money moves through an organization can be so useful.
Instead of starting with the payment technology, we can start with a series of operational questions.
Where does the customer decide to make the payment? Where does cardholder data enter the organization? Who interacts with that information? Which systems receive it? Which parts of the process actually require human involvement, and which parts exist primarily because that is how the workflow developed over time?
Those questions often reveal opportunities that are difficult to see when organizations look only at the payment application.
Human Involvement Is Not Always the Same as Human Value
There is an important distinction between involving an employee in a customer interaction and requiring an employee to participate in payment-data capture.
Consider a customer calling a hospital billing department, utility, municipality, insurance company or other service organization.
The customer may genuinely need assistance. They might have questions about a bill, need clarification about an account, or want to speak with someone before making a payment.
The employee may be extremely valuable during that conversation.
But when the conversation reaches the point where the customer is ready to pay, the workflow can potentially change.
Instead of the customer reading a card number aloud and the employee entering it into another application, the payment portion of the interaction can be moved into an automated IVR payment environment.
The customer enters the payment information directly.
The payment is processed.
The appropriate result can then be communicated or passed back into the broader workflow.
The employee can remain focused on the part of the interaction where human assistance provides actual value.
That is a very different way of thinking about payment automation.
The objective is not simply to replace people with technology. It is to determine where people are needed and where the payment process can be redesigned, so they no longer handle sensitive payment information.
Redesigning the Phone Payment Flow
A traditional employee-assisted phone payment might look something like this:
Customer → Employee → Payment Information → Payment Application → Processor
The employee becomes an intermediary between the customer and the payment environment.
An automated payment flow can potentially look quite different:
Customer → IVR Payment Environment → Payment System / Processor
That change may appear relatively small, but operationally it can be significant.
The organization has changed where payment information enters the environment and who interacts with it.
Employees may no longer need to hear card numbers, repeat information back to customers, or manually enter payment credentials into another system. Routine payment handling can move into a purpose-built automated environment while employees remain available for service, exceptions and more complex customer needs.
At sufficient transaction volumes, removing those manual steps can also reduce the amount of employee time dedicated to routine payment processing.
But the more important point is that the organization has deliberately redesigned the payment flow rather than simply adding another payment channel.
PCI Scope Starts With Understanding the Flow
There is also an important PCI DSS consideration.
Organizations sometimes assume that implementing a particular technology automatically removes systems or employees from PCI scope. That is too simplistic.
PCI scope depends on the specific environment, architecture, systems, processes and how cardholder data moves through them.
However, changing the payment flow so employees and certain systems no longer handle cardholder data can help reduce PCI scope or exposure depending on the environment.
That is why the first step should not necessarily be selecting a technology.
The first step should be understanding the existing flow, i.e.:
- Where is cardholder data captured?
- Can employees hear it?
- Can they see it?
- Do they type it into a system?
- Is it recorded anywhere?
- Which applications receive or transmit the information?
- What happens after authorization?
Once those questions are answered, organizations can begin evaluating whether portions of the payment process can be isolated, automated, or moved into environments specifically designed to handle payment information.
This is where Payment Flow Intelligence becomes valuable.
The objective is not simply to determine whether an organization is compliant today. It is to examine whether the payment flow itself can be designed more effectively.
Better Security Can Also Mean Better Operations
Security and operational efficiency are sometimes treated as separate initiatives.
Payment workflows demonstrate why they often are not.
If an employee has to receive payment information, enter it manually and wait for the transaction to complete, the organization has created both a security consideration and an operational dependency.
The payment cannot move without the employee.
Multiply that interaction across hundreds or thousands of payments, and the impact becomes easier to see.
Employees spend time processing routine transactions. Customers may have to wait for someone to become available. Contact-centre capacity is consumed by interactions that could potentially be handled through self-service. At the same time, more people and processes become involved in the handling of payment information.
Redesigning the flow can therefore create multiple outcomes at once.
It can reduce manual handling.
It can simplify the payment workflow.
It can provide customers with another way to complete a transaction without verbally communicating their card information.
And, depending on the architecture, it may help organizations reduce the number of people and systems exposed to cardholder data.
That is much more valuable than simply saying that IVR is another payment channel.
Understanding How Money Flows
When we conduct Payment Flow Intelligence sessions, one of the things we are looking for is unnecessary complexity.
Payments often become embedded inside operational processes that were created years ago. Those processes continue because they work well enough, even though the technology and security environment around them may have changed considerably.
Phone payments are a good example.
If employees are taking credit card numbers over the phone today, one of the first questions I would ask is:
Do they actually need to be part of that payment flow?
The answer will not be the same for every organization.
But asking the question can reveal opportunities to rethink how the payment moves from the customer, through the organization and into the payment ecosystem.
That is ultimately what Payment Flow Intelligence is about.
Payment Flow Intelligence is not simply processing a transaction, it’s about understanding how money moves, identifying where the flow creates unnecessary operational effort or exposure, and then determining whether the process can be redesigned to be more efficient and secure
Assess Your Phone Payment Flow
If your organization currently has employees accepting card payments over the phone, it may be worth examining the complete workflow before making assumptions about what needs to change.
Datatel’s Payment Flow Intelligence Framework™ can help identify where employees, systems and payment information intersect across the phone-payment process and where IVR payment automation may provide an opportunity to simplify that flow.
Assess Your Phone Payment Flow or Explore IVR Payment Automation to determine where a different payment design may make sense for your organization.