La solution tire parti de
Zoom App Marketplace et des
solutions partenaires de Zoom pour permettre des appels conformes à la norme PCI au sein d’un environnement donné. Il existe de nombreuses façons d’aborder la conformité, et la solution décrite ci-dessous permet de minimiser la portée d’un environnement.
Pour les besoins de cette section, nous nous concentrerons sur deux entités : l’agent et le consommateur. L’agent est une personne qui utilise Zoom Contact Center et qui reçoit des engagements par le biais d’un canal vocal, vidéo ou de messagerie et qui doit recevoir les paiements du consommateur de manière sécurisée. Le consommateur est l’initiateur de l’engagement et le détenteur de la carte de paiement. Bien qu’il existe des canaux de paiement basés sur le texte, nous nous concentrerons dans cet exemple sur les engagements via le canal vocal.
Lorsqu’il appelle Zoom Contact Center, le consommateur est dirigé vers les menus et les interactions en fonction de la conception de la file d’attente administrative avant d’être acheminé vers l’agent désigné. Une fois que l’engagement a commencé, deux segments de flux de média permettent à l’agent et au consommateur de communiquer l’un avec l’autre via un canal vocal : (1) le média est envoyé du consommateur au RTC et à l’infrastructure ZCC, et (2) le média est envoyé de l’infrastructure ZCC au client de l’agent. Ceci est également un exemple d’appel traditionnel dans Zoom Contact Center.

Figure 2 : configuration initiale de l’appel téléphonique
Une fois l’appel initial établi, l’agent·e peut communiquer avec le·la consommateur·rice jusqu’à ce que le paiement soit encaissé. À ce moment-là, l’agent·e, dans l’application Zoom PCI Pal, (3) lance une session pour commencer la collecte du paiement. Le protocole SIP utilise à la fois les API Zoom et PCI Pal pour orchestrer les segments supplémentaires de l’appel entre le fournisseur RTC, PCI Pal et Zoom. Ces segments d’appel facilitent la négociation du média en déchargeant Zoom et l’agent·e du traitement, de la transmission et du stockage des données du·de la titulaire de la carte. Le segment initial (4) reste connecté entre le fournisseur RTC et Zoom. Un segment supplémentaire (5) est établi entre Zoom et PCI Pal. Lorsque les segments d’appel (4) et (5) sont connectés avec succès, le média (6) est négocié directement entre le fournisseur RTC et PCI Pal. Pendant que le support se trouve dans PCI Pal, les données du·de la titulaire de la carte sont supprimées. PCI Pal envoie la signalisation avec un flux média associé à Zoom (7). Dès réception, Zoom reconnecte le flux à l’agent·e (8).
Ce flux de média du RTC à PCI Pal (6) contient des Données relatives aux titulaires de carte et est filtré dès son entrée dans l’environnement PCI Pal. Le média est renvoyé à Zoom (7) et finalement, à l’agent·e (8). Ce chemin média n’est actif que pendant la durée du processus de paiement, à savoir seulement quelques minutes en général. L’Agent·e a la possibilité de maintenir la communication avec le ou la Client·e pendant cette période. Les Données des titulaires de carte étant supprimées du média avant d’arriver à Zoom, des services tels que l’enregistrement peuvent être maintenus tout au long de l’expérience sans élargir le champ d’application de la conformité.
Figure 3 : paiement en cours
Une fois le paiement effectué, les connexions supplémentaires sont automatiquement supprimées et le média est établi dans la configuration d’origine : du RTC à Zoom (1) et de Zoom à l’agent d’origine (2). Un·e agent·e peut établir des flux de paiement supplémentaires si nécessaire.
![]()

Figure 4 : le flux initial est rétabli