Taking Payments

Topic Views - 5122

Head of Contact Centre Management


Can anyone advise me on how they take payments over the phone securely when all calls are recorded and therefore PCI information is stored via the call recording equipment we use?

Director of Consulting

h2i Consulting Limited


There is a company called Semafone who have developed a solution that enables payment details to be tapped into the phone by the customer, the data is then encrypted and can be attached to the relevant customer record or sent straight to your billing system. The solutions means that the call recording will not contain the customers payment details for anyone to hear. Originally developed for inbound call handling, the solution works just as well for outbound call activity. I would recommend you speak to them about this and see if their solution would suit you. Here's the link to their website. http://www.semafone.com/

Kind Regards


Account Manager



Another thing to check is whether your current call recording sytem can support an API for start/stop so that the CCV number is not recorded or has an upgrade path for record on demand.

Some companies are using the help of QSA,s to help them through the PCI minefield.

But yes semaphone is another way around this

Sales Director


I agree with the comment above. We work with a range of Call Recording vendors on behalf of our clients and most are introducing ways in which you can automatically pause and resume call recordings when you come to collect Credit Card data. Combine this with using a Payment Gateway to ensure the sensitive data is not stored on your system anywhere and you should be ok.

PCI is just about the number one topic we are being asked about by our clients and as already mentioned it is a bit of a minefield.

Project Support Manager

The Listening Company

You can use Decru Encryption - stores all voice recordings in encrypted format. They can still be accessed internally of course, for QA purpose.

In that case, your IT dept should be able to provide a mute function on your advisors' softphones.


Call Centre Helper

We are doing an editorial on Call Recording for PCI DSS complaince as part of our Call Recording and Speech Analytics Reference Guide. This will be published at the end of the month.

So far the two main options seem to be

- Pass the call into an IVR that will handle the credit card details

- Use some form of API that when the agent goes to a certain field it turns on and off the call recording.

Sales Director


Hi Jonty,

Yes they seem the two main options everyone is taking, apart from turning off call recording altogether when taking payments...

One issue I would be interested in seeing others opinions on is when in the call process do you hand the caller off to the IVR?

At the end of the call so the agent can be freed up? In a sales environment will this increase the % of people not completing the order as they have an opportunity to drop out of the IVR... During the middle of the call in which case what does the agent do whilst the caller is making a payment, how do you return the caller back to the same agent and how does the agent know the payment was successful??

The discussions we have had with clients and using the IVR function seem to focus on these items...

Anyone else got the answers??


(Disclaimer: I work for Veritape, a provider of PCI DSS compliant call recording software.)

For Christine (and others):


Whilst the underlying rules for PCI DSS have not changed recently, the PCI SSC (the body which governs card payment security) has issued two recent updates specifically about call recording.

And there are contact details if you'd like more information on the guidelines.

For Jonty:


Jonty, there is also a third option (of the style mentioned in the thread above): isolate the agent from the transaction even though the call remains 'open' between the agent and the customer.

For Gavin:


I would caution against using encryption. The difference with encrypted audio calls versus (say) encryption in other parts of the payment process (such as electronic payment authorisation with an acquirer/bank) is that the ability to _decrypt_ the audio is an inbuilt function of all call recording systems. Call centre supervisors, trainers, etc are required to listen to call recordings as part of their jobs.

Hence if card details are retained in the audio, supervisors and anybody with permission to listen to calls has a huge library of card details from which to potentially steal. The PCI governing body, the SSC, specifically says that encryption is not good enough. In addition, the major UK banks, when publicly discussing this issue at industry bodies like Vendorcom, say that they do not approve of encryption as a 'solution'.

In addition (sorry!) if an agent has the ability to manually mute their phones, experience has shown that they may start doing this at inappropriate points of the conversation, to mask other behaviour. An automated or fail-safe method for muting the card details is far preferable to manually-operated ones.

For Kevin:


Yes, this IVR approach does seem a little clunky, and the customer service or customer continuity aspect of these communications don't seem, to "hold the customer's hand" properly. That is, you 'dump' a customer to an IVR/robot and, as you say, that increases the possibility that the customer won't complete the transaction. And then, yes, there are routing issues getting customers back to the same agent (do they twiddle their thumbs while the customer is paying?), and comms issues sending transaction success/failure details back to the agent. Not very tidy... the most sensible approach surely seems to be that the agents should be taking the card details, but using a system which guarantees the card details aren't stored in audio.

(Wow, that was a long post - hope you're still alive when you get down to here!)



Anyone have thoughts about what to do with the existing stored calls we have, which we are required to keep? Either of the options discussed (stopping recording for the payment info or using an IVR) are helpful going forward, but what about calls that are already stored?


(Disclaimer: I work for Veritape. We provide PCI compliant call recording systems to contact centres.)

For Olivia


Veritape's view on this is: take all recordings which are not required to be accessible 'live', and:

- encrypt them, allowing access to only the senior Compliance Manager role (or similar)

- burn to two separate DVDs

- store one DVD on site

- store the other DVD offsite

- in both cases, you need to comply with the standard protection mechanisms which PCI DSS imposes for paper-based documents

This approach ensures security because:

- if the data (DVD) is stolen it can't be played back

- the DVDs are 'offline' - i.e. they can't be hacked into from outside or inside the organisation by somebody connecting remotely to the audio file location.

We have had positive feedback from the major acquirers (banks) that this approach would be looked on favourably by them. Of course, the acquirers have the final 'say' for each merchant individually.

By doing this (and assuming that the bulk of your recordings are not needed for 'live' access once they are say 3 months old), within 3 months all your library of recordings (whether 'live' or 'archived') are PCI compliant.

[Part of this post removed (No advertising allowed) - Editor]



Customer Care Rep

Can someone advise me what prompted all of the PCI compliance hysteria to start with? Was there a surge in the number of cards used fraudulently and were they traced back to call centres and the such like? Were they being abused by individual staff, or were there wholesale thefts of information not stored safetly.

I am not being critical, just interested! Thanks.

Account Manager


Hi Callzilla

From what I understand this has come about through credit card fraud as information about transactions are stored within call recording systems and could be abused with card details being taken off the recorded call.

Thus the need to find a way of stopping this from happening through compliance.



Head of IT and Telecoms

Transfer the call to a payment extension
I don't see what all the fuss is about really.
We use asterisk, it is free. When ready to take payment you can simply transfer the call to a payment extension, say 4444 which is set up to disallow recording or attended transfers.
The client hears the amount and is then prompted to enter the appropriate details on their keypad. The transaction is processed and appended into the client record as a success or fail. The client is automatically passed back for you to confirm and thank them.
If at any point the client wishes to break off the transaction they simply press * to return to the handler.
Neither the agent nor the record will hold the card details or CVV2
This is a free solution based on a free PBX platform. It makes use of the dialplan features of Asterisk, it's gateway interface and tiny bit of Perl scripting.
But there are so many ways to make a free, secure and compliant card payment gateway inhouse with or without CRM integration it's silly : )


Payment gateway
That's a great important thing. A Payment Gateway is a processor place on your website (a part of visitor workflow) where a transaction can be made.

Want to add a comment?

Not found what you were looking for?

1. Try searching through our site.
2. Still not got an answer?

Why not ask the Call Centre Helper Community? Click here to ask your question