Secure Pause Failing During External Payment Transfers

I am conducting a PCI-DSS compliance audit on our new Genesys Cloud Architect implementation. We use a Secure Pause action before transferring callers to an external payment gateway. According to our integration tests, the Secure Pause initiates successfully. However, when we extract the media files via the /api/v2/conversations/{conversationId}/recordings endpoint, approximately five percent of the audio files still contain the Dual-Tone Multi-Frequency tones from the customer entering their credit card number. The flow executes the Secure Pause block immediately prior to the Transfer block. Why is the recording service capturing audio during a transfer despite an active Secure Pause command?

Greetings. I have encountered a similar anomaly during the development of our conversational AI payment bot. The architecture of the Secure Pause function dictates that it only suspends recording on the specific conversation leg where it is invoked.

When you execute a transfer to an external routing number or a third party SIP trunk, the edge server instantiates a completely new outbound conversation leg to connect the transfer target. The Secure Pause state does not automatically inherit across different routing segments.

You must ensure the recording policy on the external trunk is explicitly disabled, or the system will resume recording the moment the transfer completes.

Yes, this is very important to understand. In my load testing scenarios, we saw this exact failure during high volume periods. The Secure Pause action has a slight initialization delay.

It takes a few milliseconds for the command to travel from the Architect flow execution engine to the media server processing the audio. If your customer begins typing their card number on their keypad the instant the transfer starts, those first few tones will leak into the audio file before the pause fully engages.

You must insert a brief audio prompt, such as ‘Please wait while we connect your secure payment’, immediately after the Secure Pause block to absorb that delay.

Hey. Who just went through this exact compliance audit last month, I can tell you that using the Secure Pause block right before a transfer is a terrible design pattern. The auditors will flag it every single time because you have zero control over the external transfer leg.

Instead of transferring the call, you should be using a Secure Flow. You invoke a Secure Flow directly from the Inbound Call Flow using the Call Secure Flow block.

Secure flows automatically suppress all recordings and screen captures natively at the platform level without needing manual pause actions. Once the payment is done, it returns to the main flow.

Do not use external transfers for payment data.