PCI 合規性

作者：Ben DeStephen

討論支付卡產業（PCI）的要求，通常可以從先來杯咖啡開始。如果你曾參與過這類對話，結果往往相當主觀，這也會導致大家普遍希望盡可能縮小環境的適用範圍。透過 Zoom 與 PCI Pal 所實作的解決方案，咖啡就變成可有可無。在這篇文章中，我們將探討這項實作、它的效益，以及你的組織如何可能縮小業務流程的適用範圍。

PCI 背景

PCI 安全標準委員會制定了一套規範，用於管制在各種環境中處理信用卡資訊的方式。這些規範 已發布 由委員會發布，並定義商家（收款的公司）的要求。這些標準的主要重點是保護持卡人資料（CHD），因為這些資料會在多個系統之間傳遞。商家會運用各種供應商與解決方案提供者來處理銷售。

所有這些元件最終都會導向一份支援性的符合性證明（AOC）。AOC 可讓商家運用各個供應商的聲明來形成自己的 AOC。依照解決方案設計與交易量而定，為了補救並維護持卡人環境（CHE），可能需要相當龐大的投入。

結合供應商的 AOC，以支援客戶的 AOC 與符合 PCI 的設計

在討論這項實作及其如何為組織帶來效益時，必須留意持卡人資料的整體流向。如果存在持卡人資料，可能就需要進行合規稽核。以下方展示的 Zoom 解決方案而言，商家可以選擇將此環境及其相關成本降到最低。

我們將看看 Zoom 與 PCI Pal 如何在幕後協同運作，讓客戶能在 Zoom Contact Center 中達成 PCI 合規。

解決方案概覽

此解決方案善用了 Zoom App Marketplace 以及 Zoom 合作夥伴解決方案 ，以便在環境中啟用符合 PCI 規範的通話。達成合規的方法很多，而以下詳述的解決方案則提供了縮小環境適用範圍的機會。

在本節中，我們將聚焦於兩個主要實體：客服人員與消費者。客服人員是使用 Zoom Contact Center 的個人，會透過語音、視訊或訊息管道接收互動，並需要以安全方式向消費者收取款項。消費者是發起互動的人，也就是持卡人。雖然也有提供以文字為基礎的付款管道，但在此範例中，我們將聚焦於語音管道的互動。

消費者撥入 Zoom Contact Center 後，會先依據管理端的佇列設計，經過各項選單與互動流程，再轉接至指定的客服人員。互動開始後，會有兩段媒體流讓客服人員與消費者透過語音管道彼此溝通：（1）媒體從消費者傳送到 PSTN 與 ZCC 基礎架構；（2）媒體在 ZCC 基礎架構與客服人員的用戶端之間傳送。這也是撥入 Zoom Contact Center 的傳統通話範例。

初始電話通話設定

在初始通話建立後，客服人員就能與消費者溝通，直到需要收取款項為止。此時，客服人員可在 PCI Pal Zoom App 中（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 之前已移除持卡人資料，因此錄音等服務可在整個體驗期間持續運作，而不會增加合規範圍。

付款進行中

付款完成後，額外連線會自動移除，媒體會恢復為原始設定：從 PSTN 到 Zoom（1），以及從 Zoom 到原本的客服人員（2）。客服人員可視需要建立其他付款流程。

原始流程已重新建立

解決方案重點

其中一個可能不會立刻顯而易見的項目，是該通話可使用 Zoom Contact Center 服務。持卡人資料在媒體抵達 Zoom 之前即被移除，讓互動能運用 Zoom Contact Center 的功能，從錄音、轉錄與情緒分析，到供主管使用的品質管理功能都能涵蓋。

上述架構是 Zoom Contact Center 獨有的，並帶來多項設計優勢。其他設計通常要求任何可能需要付款資訊的通話，都必須連接到付款處理器（例如：信號控制）。在此設計中，Zoom 作為核心路由引擎，只有需要連接付款處理器的通話才會建立到整合系統，而且僅在所需時間內建立。這使得通話流程在不需要付款時仍可正常運作，若突然需要收款，也能更順暢地處理。

許多其他流程會持續連接到安全付款解決方案。除了延遲方面的考量外，按需解決方案的另一項附加效益，是關於故障域。 雖然這些系統具有高度可用的運作時間，但串接的系統會形成整體 SLA。透過在 Zoom Contact Center 中實作此解決方案，各系統即使其中一個整合出現問題，仍有能力繼續將消費者連接到客服人員。

最後，Zoom 以平台為基礎的設計，也讓這些整合可供非 Zoom Contact Center 使用者利用。如果使用者不屬於 Zoom Contact Center 佇列，則可使用 Zoom Phone 的類似功能。

除了這些獨特的效益之外，與 PCI Pal 整合並檢視客服人員的工作流程，還可能讓你的組織縮小 PCI 適用範圍。

總結

在建置支援付款的聯絡中心時，如何在合規與技術需求之間取得平衡，需要妥善規劃。透過 Zoom Contact Center 與 PCI Pal 的整合，可提供更多彈性，進而降低合規複雜度。我們接下來還會發表更多文章，聚焦於管理員角度下這項整合的設定方式。