此页面内容由机器翻译。Zoom 不保证机器翻译内容的准确性
For the complete documentation index, see llms.txt. This page is also available as Markdown.

PCI 合规性

作者:Ben DeStephen

讨论支付卡行业(PCI)的要求往往可以从先喝杯咖啡开始。如果你曾参与过这类讨论,结果往往带有主观性,这就导致人们普遍希望尽可能缩小环境范围。借助 Zoom 和 PCI Pal 实施的解决方案,咖啡变成了可选项。在这篇文章中,我们将探讨该实施方式、其优势,以及你的组织如何能够缩减你的业务流程范围。

PCI 背景

PCI 安全标准委员会制定了一套用于规范在各种环境中处理信用卡信息的指南。还有一些指南 发布的 由委员会发布的,这些指南定义了商家(收集付款的公司)的要求。标准的主要重点是保护持卡人数据(CHD),因为它会在多个系统之间共享。商家将利用各种供应商和解决方案提供商来处理销售。

所有这些组件共同形成一份支持性的合规性证明(AOC)。AOC 使商家能够利用各供应商的声明来形成自己的 AOC。根据解决方案设计和交易数量,修复并维护持卡人环境(CHE)可能需要相当大的工作量。

Combining Vendor AOC's to support a Customer AOC and a PCI Compliant Design
将供应商的 AOC 结合起来,以支持客户 AOC 和符合 PCI 要求的设计

在我们讨论实施方式及其如何使组织受益时,务必要留意持卡人数据的整体流向。如果持卡人数据显示出来,可能需要进行合规性审计。借助下面重点介绍的 Zoom 解决方案,商家可以选择尽量缩小此环境及其相关成本。

我们将看看 Zoom 和 PCI Pal 如何在幕后协同工作,以启用客户在 Zoom 呼叫中心中实现 PCI 合规性。

解决方案概述

该解决方案利用了 Zoom App MarketplaceZoom 合作伙伴解决方案 以便在环境中启用符合 PCI 要求的呼叫。实现合规性有许多不同的方法,而下面详述的解决方案提供了缩小环境范围的机会。

在本节中,我们将重点关注两个主要实体:坐席和消费者。坐席是使用 Zoom 呼叫中心的个人,将通过语音、视频或发送消息频道接收互动,并且需要以安全方式从消费者那里收取付款。消费者是交互的发起者,也是付款卡持有人。虽然基于文本的付款频道可供使用,但在示例中我们将重点关注语音频道上的交互。

在呼叫进入 Zoom 呼叫中心后,消费者会根据管理员的队列设计,通过菜单和交互流程被引导,然后再路由到指定的坐席。交互开始后,有两个媒体流片段允许坐席和消费者通过语音频道相互通信:(1) 媒体从消费者发送到 PSTN 和 ZCC 基础架构;(2) 媒体在 ZCC 基础架构与坐席客户端之间发送。这也是呼叫进入 Zoom 呼叫中心的一个传统呼叫示例。

Initial Phone Call setup
初始电话呼叫设置

初始呼叫建立后,坐席可以与消费者通信,直到需要收款为止。此时,坐席在 PCI Pal Zoom 应用中 (3) 启动一个会议,以开始收款。通过结合 Zoom 和 PCI Pal 的 API,使用 SIP 来编排 PSTN 提供商、PCI Pal 和 Zoom 之间的其他呼叫腿。这些呼叫腿以一种方式促进媒体协商,从而使 Zoom 和坐席无需处理、传输和存储持卡人数据。初始呼叫腿 (4) 仍保持在 PSTN 提供商和 Zoom 之间连接。另一个呼叫腿 (5) 从 Zoom 建立到 PCI Pal。随着呼叫腿 (4) 和 (5) 成功连接,媒体 (6) 在 PSTN 提供商和 PCI Pal 之间直接协商。媒体位于 PCI Pal 中时,持卡人数据会被移除。PCI Pal 将带有相关媒体流的信令发送回 Zoom (7)。一旦收到,Zoom 会将流重新连接到坐席 (8)。

从 PSTN 到 PCI Pal 的这段媒体流 (6) 包含持卡人数据,并在进入 PCI Pal 环境时被过滤。媒体随后被传回 Zoom (7),最终到达坐席 (8)。这条媒体路径仅在付款流程期间有效,通常只需几分钟。此时坐席仍可与消费者保持沟通。由于媒体在到达 Zoom 之前已移除持卡人数据,因此录音等服务能够在整个过程中持续运行,而不会增加合规性范围。

Payment in Process
付款处理中

付款完成后,额外连接会自动移除,媒体会在原始设置中重新建立:从 PSTN 到 Zoom (1),以及从 Zoom 到原始坐席 (2)。坐席可根据需要建立额外的付款流程。

Original Flow is re-established
原始流程已重新建立

解决方案要点

其中一个可能不会立刻显而易见的事项,是呼叫可用的 Zoom 呼叫中心服务。由于在媒体到达 Zoom 之前移除了持卡人数据,交互可以利用 Zoom 呼叫中心的各项功能,从录音、转录和情感分析到用于监督职能的质量管理。

上述架构是 Zoom 呼叫中心所独有的,具有多重设计优势。其他设计要求任何可能需要付款信息的呼叫都必须连接到付款处理器(例如,信令)。在以 Zoom 作为核心路由引擎、并正在连接到付款处理器的设计中,只有需要连接到付款处理器的呼叫才会与集成系统建立连接,而且仅在所需时长内进行。这启用了呼叫流程在不需要付款时保持正常运行的灵活性,同时也使得在需要意外收款时运行更加顺畅。

许多其他流程会持续通过安全付款解决方案连接。除了延迟方面的考虑外,这种按需方案的另一个附加好处在于故障域。 虽然这些系统具有很高的可用运行时间, 串联连接的系统会叠加 SLA。随着该解决方案在 Zoom 呼叫中心中的实施,即使某个集成出现问题,各系统仍有能力将消费者连接到坐席。

最后,Zoom 基于平台的设计使这些集成可供非 Zoom 呼叫中心用户使用。如果用户不隶属于 Zoom 呼叫中心队列,Zoom Phone 具有类似能力可供使用。

除了这些独特优势之外,与 PCI Pal 的集成以及对坐席工作流程的评估,可能会使您的组织能够缩小其 PCI 范围。

结语

在实施一个支持付款的呼叫中心时,平衡合规性和技术需求需要妥善把握。借助 Zoom 呼叫中心与 PCI Pal 的集成,我们拥有更多灵活性来帮助降低合规性复杂性。我们还将发布更多文章,从管理员的角度介绍该集成是如何配置的。

最后更新于

这有帮助吗?