Implementing Automated PCI Redaction in Screen Recording during Secure Pause Events

How-To-Articles
1

Implementing Automated PCI Redaction in Screen Recording during Secure Pause Events

What This Guide Covers

  • Eliminating a critical PCI-DSS compliance gap by ensuring that when an agent triggers a “Secure Pause” to collect a credit card over the phone, the Genesys Cloud WEM Screen Recording also pauses automatically.
  • Architecting a custom Secure Pause Architect flow that coordinates both Voice and Screen recording suspensions simultaneously using the Genesys Cloud API.
  • The end result is a foolproof compliance mechanism that prevents agents’ screens (which are displaying the billing portal and typing out the credit card number) from being captured and stored in your historical quality management recordings.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud CX 3 (or CX 1/2 with WEM Add-on).
  • Permissions: Architect > Flow > Edit, Quality > Screen Recording > Manage, Integrations > Action > Edit.
  • Infrastructure: A deployed Web Services Data Action integration configured to hit the Genesys Cloud Public API (api.mypurecloud.com).

The Implementation Deep-Dive

1. The Screen Recording Blind Spot

When a customer is ready to pay, the agent clicks “Secure Pause” (or a Secure Flow is triggered via DTMF). This stops the voice recording for 60 seconds.

The Trap:
By default, the Voice recording pauses, but the Screen recording continues. The agent opens the external payment gateway, types the customer’s 16-digit credit card number into the portal, and clicks submit. Because the Screen Recording was still running, that 16-digit number was captured in full 1080p video and saved to your Genesys Cloud AWS S3 bucket. If an auditor reviews this recording, you instantly fail your PCI-DSS assessment, exposing the company to massive fines.

2. The Genesys Cloud API Architecture

To solve this, we must explicitly tell the Quality Management engine to pause the screen capture process whenever the voice recording is paused. We do this using the Genesys Cloud Conversations API.

Implementation Steps (The Data Action):

  1. Navigate to Admin > Integrations > Actions.
  2. Create a new custom Data Action named Pause_Screen_Recording.
  3. HTTP Method: PUT
  4. Endpoint URL: /api/v2/conversations/{conversationId}/participants/{participantId}/screenrecording/pause
  5. Input Contract:
    • conversationId (String)
    • participantId (String)
  6. Create a secondary Data Action named Resume_Screen_Recording.
  7. HTTP Method: PUT
  8. Endpoint URL: /api/v2/conversations/{conversationId}/participants/{participantId}/screenrecording/resume

3. Orchestrating the Secure IVR Flow

Instead of relying on the manual “Secure Pause” button in the UI (which relies on the agent remembering to click it), we will build a dedicated Secure Flow that handles the billing entry and the recording redaction autonomously.

Implementation Steps:

  1. Open Architect and create a new Secure Call Flow.
  2. The Entrance (Pause): When the call enters the Secure Flow, the voice recording is automatically paused by the platform.
  3. Immediately place a Call Data Action block as the very first step.
  4. Execute the Pause_Screen_Recording Data Action you created in Step 2.
    • Use the built-in variables Call.ConversationId and Call.AgentParticipantId.
    • Result: The agent’s screen recording goes dark (or is overlaid with a privacy mask depending on the desktop app configuration) the exact second the voice recording stops.
  5. The DTMF Collection: Use a Collect Input block to securely collect the customer’s credit card number via their telephone keypad. (The agent does not type it).
  6. The Payment Gateway: Use another Data Action to process the payment through your gateway (e.g., Stripe, Cybersource).
  7. The Exit (Resume): Right before returning the call to the agent, use a Call Data Action block to execute the Resume_Screen_Recording API call. The screen capture begins again, and the call seamlessly returns to the normal Agent Workspace.

4. Handling Agent-Initiated Manual Pauses

If you allow agents to manually click the “Secure Pause” button in their interface (rather than transferring to a Secure Flow), you must bridge the gap using EventBridge.

Implementation Steps:

  1. Configure an Amazon EventBridge integration.
  2. Subscribe to the v2.detail.events.conversation.{id}.secure_pause topic.
  3. Route this to an AWS Lambda function.
  4. When the Lambda receives the secure_pause_started event, it executes the Pause_Screen_Recording API call.
  5. When the Lambda receives the secure_pause_ended event, it executes the Resume_Screen_Recording API call.
    Note: Because this is an asynchronous event trigger, there may be a 1-2 second latency before the screen recording actually stops. If strict zero-tolerance PCI compliance is required, the Secure Flow architectural method (Step 3) is superior to the manual button.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Multiple Agent Participants (Consult Transfers)

  • The Failure Condition: Agent A receives the call. The screen recording starts. Agent A consult-transfers the call to Agent B. They are both on the line. Agent B initiates a Secure Pause to take payment. The API call is triggered, but it uses the original participantId (Agent A). Agent A’s screen is paused, but Agent B’s screen (who is actively typing the credit card) is still being recorded.
  • The Root Cause: Architect flows often retain the participantId of the first agent who handled the interaction unless specifically updated.
  • The Solution: In your Data Action payload, you must dynamically query the active participants. If using EventBridge, the payload will explicitly identify which userId initiated the Secure Pause. You must map this userId to the correct participantId before executing the screen pause API, ensuring the redaction applies to the agent currently controlling the payment gateway.

Edge Case 2: The Agent Application Screen Recording Policy

  • The Failure Condition: You implement all the APIs perfectly. However, when you test it, you find that the screen recording didn’t pause; it completely terminated, creating two separate video files for a single interaction, causing errors in your QA dashboard playback.
  • The Root Cause: Genesys Cloud Screen Recording relies on the Genesys Cloud Desktop App. If the desktop app loses network connectivity during a pause, or if the API call is malformed, it may fail gracefully by terminating the file handle rather than suspending it.
  • The Solution: Ensure your agents are running the latest version of the Genesys Cloud Desktop App (web-browser screen recording via Chrome extensions behaves differently and is generally not recommended for PCI environments). Additionally, review your Quality > Policies to ensure the Screen Recording policy is set to “Record the entire interaction” rather than conditional recording, which interacts more smoothly with the explicit Pause/Resume API endpoints.

Official References