Does anyone have any experiance intergrating the Eckoh Callguard PCI Compliance system to a Nortel CS1000 ? We have two call centers still running CS1000/Symposium and we are being forced into installing the Eckoh PCI Compliance system . Eckoh doesn't seem to have any expertise in adapting their "solution" to the customer equipment , just wondering if anyone has been down this roade before . Thanks in advance !
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Andrzejek on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
PCI Compliance using Eckoh
- Thread starter FONEGUY
- Start date
Hi
We're using Callguard PCI. Seems to work well. there's a usb device that sits between the agents headset and handset. This is controlled by a small application on the users PC's and sorts the DTMF. the unit also acts as a usb keyboard.
There's also a server that sits infront of our call recorder that tones out any dtmf tones so you can't get the details from a voice recorder.
The application sits and waits to recognise the payments page and then "padlocks" the relevant payments pages. the caller will use their keypad to enter the account number, svc etc the agent just hears beeps and the screen gets populated with the details, again the agent cant see the numbers as all they get are dots.
Works fairly well for us but we do sometimes get delays that prevent the padlocks appearing on the payments page, but that's our hyper-v environment
It's not getting any smarter out there. You have to come to terms with stupidity, and make it work for you.
We're using Callguard PCI. Seems to work well. there's a usb device that sits between the agents headset and handset. This is controlled by a small application on the users PC's and sorts the DTMF. the unit also acts as a usb keyboard.
There's also a server that sits infront of our call recorder that tones out any dtmf tones so you can't get the details from a voice recorder.
The application sits and waits to recognise the payments page and then "padlocks" the relevant payments pages. the caller will use their keypad to enter the account number, svc etc the agent just hears beeps and the screen gets populated with the details, again the agent cant see the numbers as all they get are dots.
Works fairly well for us but we do sometimes get delays that prevent the padlocks appearing on the payments page, but that's our hyper-v environment
It's not getting any smarter out there. You have to come to terms with stupidity, and make it work for you.
- Thread starter
- #3
Mikeyb123 , We are using the Eckoh system , formally know as Call Guard . What sort of USB device did they provide ? We have the audio appliances installed between the telco and the PBX , the appliances are monitoring all of the local and LD circuits for the entire facility , not just the call center . The audio appliance ( I call it " The Wiretap ) listens for DTMF tones , when it hears the tones , it captures , creates a spoken token . The appliance plays the spoke token to the agent instead of the actual credit card number . They are wanting to go to an always off mode due to the fact that the system also hears DTMF tones for conference bridge call , IVR , etc . When the system hears these DTMF tones and they are less than the length of a CC , the system freaks out and broadcasts an error message to whoever is on an active call . The vendor can't figure out how to disregard the non CC DTMF strings so , they want to go to the always off configuration . Of course , this puts the responsibility of turning it on back on the agents , kind of defeats the purpose of the compliance .WE have other sites that are using the Cisco CM/UCCX systems , we had to do some tinkering in the UCCX Desktop manager to create a applet that turns on the tokenization when the agent logins in . When they login , the applets send a #855 DTMF string to the Eckoh server , this turns on the monitoring for that agent . I don't see why the vendor's appliance just can't ignore any DTMF strings that are less than the length of a CC , guess that would be too easy .
Can you provide more detail about your USB device ?
Thanks for your time and assistance .
Can you provide more detail about your USB device ?
Thanks for your time and assistance .
Ok,
so we are only recording on extension side rather than trunk side so makes our solution a bit simpler..
CallGuard System Overview
CallGuard is an add-on to your existing call recording system. It is a simple and neat solution which allows you to meet PCI DSS guidelines banning the storage of credit card data in recorded calls and also retain the benefits of your chosen call recording system. It enables your customers to communicate payment card details by using their telephone key pad, and (unlike an IVR) means that the agent and caller are never disconnected from each other and are able to talk freely throughout the card transaction. CallGuard’s approach uses 2 separate hardware elements: the Decoder and the Filter. Each device acts independently, and there is no communication needed between them.
Core element: CallGuard Decoder
The Decoder is a small USB device. It connects each Agent’s telephone with their computer. You need one Decoder for each Agent taking card payments.
Core element: CallGuard Filter
The CallGuard Filter is a hardware device which sits in line with your existing call recorder. It listens for customers’ DTMF tones, and stops them from getting through to your recorder. Your recordings therefore will not contain any card data. The Filter is also ‘plug and play’ and does not require any configuration.
A Filter is required for each call recording device you currently have.
It's not getting any smarter out there. You have to come to terms with stupidity, and make it work for you.
so we are only recording on extension side rather than trunk side so makes our solution a bit simpler..
CallGuard System Overview
CallGuard is an add-on to your existing call recording system. It is a simple and neat solution which allows you to meet PCI DSS guidelines banning the storage of credit card data in recorded calls and also retain the benefits of your chosen call recording system. It enables your customers to communicate payment card details by using their telephone key pad, and (unlike an IVR) means that the agent and caller are never disconnected from each other and are able to talk freely throughout the card transaction. CallGuard’s approach uses 2 separate hardware elements: the Decoder and the Filter. Each device acts independently, and there is no communication needed between them.
Core element: CallGuard Decoder
The Decoder is a small USB device. It connects each Agent’s telephone with their computer. You need one Decoder for each Agent taking card payments.
Core element: CallGuard Filter
The CallGuard Filter is a hardware device which sits in line with your existing call recorder. It listens for customers’ DTMF tones, and stops them from getting through to your recorder. Your recordings therefore will not contain any card data. The Filter is also ‘plug and play’ and does not require any configuration.
A Filter is required for each call recording device you currently have.
It's not getting any smarter out there. You have to come to terms with stupidity, and make it work for you.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question