credit card processing in UCCX

[veteransreserve]

I have a client that wants to do secure credit card processing in a UCCX environment. 

My initial thoughts are to use a Finesse gadget to do a Rest API call to the credit card processor gateway and some sort of transfer or conference of the call. My questions are mostly around the PCI compliance and making sure that the agent does not hear the DTMF digits or if the caller decides to verbally enter CC digits that part of the call needs to be muted and recording paused.  

Does anyone have best practices or suggestions ?  I cant be the first engineer to get a request to securely take credit card payments in a call flow. I would appreciate any help. 

Thank you

[ptindall]

If you want to pass the customer to IVR temporarily to enter private information then there is a custom approach you can check out the content for at this link.  It's an approach that's been used successfully by several customers on CCE and I recently made it also work on CCX.   The mechanism is simply that the agent makes a consult call to an IVR service but the customer is connected to it.  The agent can see via call data how the IVR session is progressing and the outcome if required.  Once the IVR session is over, the agent resumes the call with the customer.    Can perform the consult manually at the desktop or a custom gadget at the desktop would  make it very slick.

https://twitter.com/tindallpaul/status/1146788165639974912

[veteransreserve]

This looks great .. I will prototype it over the weekend.

Thank you !

[Marek (gaman-gt.com)]

To add something to the topic.

Here are some video's that show how we did this for UCCE/PCCE: Video's . I know that you asked for UCCX but this might be handy.

And here is the overal diagram of the solution:

1. Customer calls the main number and connects to agent. The conversation begins. At some point of time agent needs to send the agent to an IVR.
2. Before transfer to IVR begins, Finesse gadget performs to actions:
   1. Calls Session Server to stop recording
   2. Calls Session Server to create a new session for the IVR conference
3. Once gadget gets the session, the transfer begins. It is done in two steps
   1. Gadget starts the new call (secondary call) to IVR and pushes the session id to one of the call variables.
   2. Once the call is established, the gadget merges the calls into one conference
4. Client enters the necessary data in the IVR (CC#, Exp. date, CVV).
5. CVP updates the context data stored in Session Server based on customer input
6. The IVR call leg ends
7. Finesse gadget detects this status and performs 2 operations
   1. Calls Session Server to retrieve data. Data is presented in gadget content.
   2. Restores the call recording
8. Agent performs the business task.
9. Customer disconnects and the call ends. The call flow ends.

In our case we use the same mechanism as Paul sugested, first we make a consult call to IVR and on top of this build 3 way conference. When the conference is established we mute the agent leg and remove unnecesary buttons from the Finesse UI. When the customer does his work in IVR we disconnect the IVR leg and pass all the context data back to Finesse. What is also interesting in my opinion and it's worth to admit - in our solution gadget also sends stop recording request to the recorder. When the customer is in IVR - the stream is not recorded.

[veteransreserve]

This looks great .. let me see how I can apply it to my scenario.

Thank you !

[Marek (gaman-gt.com)]

I've managed to create the previous idea and incorporate it into UCCX. What is funny, I was able to remove the session server from the solution - all you need to have is a Finesse gadget. The attached video shows the gadget in action in dCloud environment. 

The scenario of the video:

1. First transfer to IVR – agent directs the call to IVR, the gadget builds the 3 point conference (customer, agent, IVR) and puts the agent call leg on hold (retrieve button is removed from Finesse UI). Before the transfer, the gadget sets the CV1 with some value (can be a session id, transaction id, or any else needed for the payment system). This value will be transferred back to an agent in CV10. IVR collects customer input - credit card details like number, CVC code, card expiry date. Once all the data are gathered, the call returns to the agent, and the conference changes point to point call. The gathered details are presented in the Call Bar on finesse UI. In real life, those details should only be used by IVR - the purpose of this is to show that the gadget/agent is able to see parameters the customer provided in IVR
2. Second transfer to IVR – similar to transfer 1, but this time it is treated as re-transfer – functionality used when the data entered by the customer in IVR during first transfer were invalid (revalidate user input). All the steps that are happening in this transfer are the same as in transfer 1.
3. Third transfer to IVR – made to show that the gadget is able to detect customer drop call event being in IVR - info is presented to the agent on the banner.

[jesse7Tzz]

Merek, thanks for sharing your experience. A lot of processing stuff should be made on the server's side of the bank, as I understand this type of an issue. By the way, what do you about the most reliable bank? I've found Rate My Rewards site with plenty of comparison articles, where they compare credit cards from different banks. What do you think about it?