Topic Views - 4889
Head of Contact Centre Management
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/
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
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
In that case, your IT dept should be able to provide a mute function on your advisors' softphones.
Call Centre Helper
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.
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??
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.
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.
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.
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!)
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
I am not being critical, just interested! Thanks.
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
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 : )
(edit: oops, necropost)