Hi,
we want to make an integration with an external payment gateway so the callers can make payment through calls in a secure manner. For that reason we are using secure flow in architect. Agents will transfer to that secure flow at certain point in the call.
The payment provider/gateway that will validate the credit card is called Redsys. They have REST API, and they require some of their parameters in the calls to be encrypted.
We have seen in secure flows exist a variation of call data action, called "secure call data action". The question is, what does exactly do this "secure call data action", compared to the normal one?? Does it make some kind of encryption in the variable before sending them out as parameters?? I couldn't find any exact response in the resource center.
I can imagine that this has to be the normal scenario. I cannot think of any payment gateway that does not demand encrypted data.
If Purecloud cannot encrypt/decrypt parameters send/received through secure call data actions, we were thinking about using an intermediate proxy, but we are afraid that this proxy can break PCI DSS compliance.
Secure Actions are a designation on the action configuration that designates it as being suitable for use in handling sensitive information. This designation also extends into the action's usage within an Architect call flow, which will only allow you to handle secure variables with a secure action.
From a functional perspective, there is no practical difference between a secure action and one that does not have that designation. We still handle all of the data as if it were secure. All actions must communicate with HTTPS endpoints, using the highest level of TLS the endpoint indicates it supports; Request and Response payloads are not logged internally; etc. The secure designation is really there for making declarative configurations within your PureCloud environment to show your implementation is done in a PCI compliant manner.
I'm interested to understand what you mean by " they require some of their parameters in the calls to be encrypted". As I mentioned above, all data actions are executed using TLS, so every data action is encrypted; but I suspect that you mean that this payment processor has additional encryption requirements beyond communicating using TLS. I looked for a RedSys API reference, but couldn't find one on their site; if you happen to have a link I'll be glad to look through their reference to have a better understanding of what their requirements are.
All of that said, generally we have not encountered additional encryption methodologies being implemented by payment processors in their REST APIs; only that we support a minimum of TLS 1.2 (we do).
Feel free to PM me if there are any points that you'd like to discuss that you feel shouldn't be aired in a public forum.
Reading through that document, it's still ambiguous exactly what is required. There are examples of payloads that are unencoded, base64 encoded, and signed using HMAC SHAH256, all within the same spec. Additionally, that whole document is geared towards integrating a point of sale system, with the requirements for payload encoding seeming to be designed to protect against browser based man-in-the-middle attacks (which generally are not a concern for our server to server style of integration). Most notably, there doesn't appear to be a detailing of specific endpoints to leverage for tokenizing cards, doing risk verification, and processing transactions.
Generally we're looking for something more similar to Sagepay's REST API: https://test.sagepay.com/documentation/#introduction. Note that this provides a dedicated breakdown of REST API endpoints, with details of the request and response payloads (Sagepay is just one example, there are numerous other vendors that fit this same pattern).
Hi Richard, we are having the same problem in our implementation, basically the QSA want us to encrypt the credit card number even if we are using HTTPs, they said it needs to be double encrypted. Now is there anyway we can do that in Secure IVR data flow? Thanks
Out of curiosity, where are they getting that requirement from? That would certainly be a new one in a PCI audit, so I'd love to know if there is a specific set of requirements they're working from.
Without further details about what sort of double encryption we're being asked to engage in, I can't really evaluate it. I can say that there is generally not an out of the box method for double encrypting our data actions today, mostly because that hasn't been a defined requirement we've encountered thus far.
We made it finally by using an intermediary proxy. I see no other way for this kind of scenario.
That proxy has to use TLS 1.2 minimum, as per Richard's advice, and the rest is straightforward. This proxy is responsible for digesting the initial Purecloud data action, and finally returning decrypted parameters/easy to use information to Purecloud related to payment transaction.
We have designed intermediate function in Google cloud and also in AWS (in order to have different options for potential different customers)