Les paiements MOTO (Mail Order / Telephone Order) sont parmi les plus complexes à sécuriser en termes de conformité PCI DSS. Lorsqu'un client communique ses données de carte par téléphone, l'agent du centre d'appels entend les numéros — et potentiellement les saisit dans un système informatique. La tokenisation DTMF est la solution qui permet de protéger ces données sans perturber l'expérience client.
Qu'est-ce qu'un paiement MOTO et pourquoi est-il problématique en PCI DSS ?
Les paiements MO (Mail Order) correspondent aux paiements initiés par courrier — le client envoie ses informations de carte par courrier physique ou email. Les paiements TO (Telephone Order) correspondent aux paiements par téléphone — le client communique ses données de carte verbalement à un agent. Ces deux types de transactions sont regroupés sous le terme MOTO et partagent des caractéristiques de risque particulières.
Le problème PCI DSS des paiements téléphoniques est multiple. L'agent entend les données de carte verbalement — même si les systèmes informatiques ne les capturent pas directement, l'agent lui-même constitue un vecteur de risque. Si l'agent saisit le PAN dans un système de caisse ou de CRM, ce système entre immédiatement dans le périmètre CDE. Les enregistrements d'appels (obligatoires dans de nombreux secteurs) peuvent capturer les données de carte si elles sont communiquées verbalement, créant un problème de stockage de SAD.
PCI DSS exige que les enregistrements d'appels contenant des données de carte soient protégés conformément aux mêmes exigences que tout autre stockage de données de titulaires de carte (exigence 3). L'interdiction absolue du stockage des SAD post-autorisation (exigence 3.3) s'applique également aux enregistrements audio — un enregistrement contenant un CVV verbalement communiqué viole PCI DSS.
La solution DTMF : comment fonctionne la pause des enregistrements
La première solution partielle est la pause des enregistrements lors de la saisie des données de carte. Lorsque le processus de paiement commence, le système téléphonique suspend l'enregistrement de l'appel, le client communique ses données de carte, et l'enregistrement reprend après validation. Cette approche élimine le problème des enregistrements audio contenant des données de carte.
Mais la pause des enregistrements ne résout pas le problème de l'agent qui entend et potentiellement saisit les données. La solution complète est la tokenisation DTMF (Dual-Tone Multi-Frequency) : le client saisit ses données de carte directement sur le clavier de son téléphone (touches DTMF), sans les communiquer verbalement. Le système téléphonique transfère ces tonalités directement au système de tokenisation de PCI Proxy EU, qui génère un token sans que les données ne transitent par les systèmes du centre d'appels.
Avec la tokenisation DTMF, l'agent reste en communication avec le client pendant toute la durée de la transaction mais n'entend ni ne voit les données de carte — il entend simplement des tonalités masquées. L'enregistrement de l'appel peut se poursuivre sans interruption car aucune donnée de carte n'est verbalisée. Le système du centre d'appels ne reçoit qu'un token, jamais un PAN.
Impact sur le périmètre PCI DSS du centre d'appels
Sans tokenisation DTMF, un centre d'appels traitant des paiements téléphoniques a un périmètre CDE très étendu : le système téléphonique (IPBX, enregistreur d'appels), les postes de travail des agents, le CRM où les données de carte peuvent être saisies, les réseaux connectant ces systèmes, et potentiellement les systèmes de sauvegarde des enregistrements. Chacun de ces composants doit satisfaire les exigences PCI DSS.
Avec la tokenisation DTMF de PCI Proxy EU, le périmètre CDE du centre d'appels se réduit drastiquement. Les systèmes téléphoniques et les postes agents sortent du périmètre — ils ne voient que des tonalités masquées et des tokens. Seuls le système de tokenisation PCI Proxy EU (infrastructure externe certifiée PCI DSS niveau 1) et votre système de gestion des tokens entrent dans le périmètre. Le nombre de systèmes à auditer passe de plusieurs dizaines à quelques-uns.
Cette réduction de périmètre permet aux centres d'appels de se qualifier pour une SAQ-B ou SAQ-B-IP plutôt qu'une SAQ-D, simplifiant considérablement les obligations de conformité annuelles. Les résultats concrets : moins de tests de pénétration, moins de scans ASV, et une politique de sécurité moins étendue à documenter et maintenir.
Obligations spécifiques PCI DSS pour les environnements MOTO
Les centres d'appels MOTO doivent satisfaire des exigences PCI DSS spécifiques au-delà des exigences générales. L'exigence 9.4.2 impose que les zones d'accueil des visiteurs dans les zones CDE soient clairement identifiées et que les visiteurs soient escortés. Pour un centre d'appels, cela signifie que les zones où les agents traitent des paiements doivent être physiquement sécurisées avec contrôle d'accès.
L'exigence 12.3 exige une politique d'utilisation acceptable pour les technologies critiques utilisées dans le CDE. Pour les centres d'appels, cela inclut des règles explicites sur l'utilisation des téléphones personnels dans les zones de paiement (généralement interdits), la politique de screenshot (interdite dans les zones CDE), et les règles sur la mémorisation des données de carte (formellement interdite par PCI DSS).
La formation des agents est également une exigence clé (exigence 12.6) : tous les agents manipulant des paiements doivent être formés aux exigences PCI DSS, aux procédures de gestion des données de carte, et aux actions à prendre en cas d'incident de sécurité. Cette formation doit être documentée et renouvelée au moins une fois par an.
Intégration pratique de PCI Proxy EU dans un centre d'appels
L'intégration de la tokenisation DTMF PCI Proxy EU dans un centre d'appels existant nécessite une coordination avec votre opérateur téléphonique ou votre plateforme de centre d'appels cloud (Genesys, Avaya, Cisco, Five9, etc.). PCI Proxy EU propose des connecteurs et des API pour les principales plateformes de téléphonie, permettant une intégration sans remplacement de l'infrastructure existante.
Le flux de paiement DTMF avec PCI Proxy EU fonctionne ainsi : l'agent informe le client qu'il va être guidé pour saisir ses données de carte, le flux audio bascule vers un IVR sécurisé de PCI Proxy EU, le client saisit son PAN, sa date d'expiration et son CVV via les touches DTMF de son téléphone, PCI Proxy EU tokenise ces données et renvoie un token au système du centre d'appels, puis l'appel retourne au flux normal avec l'agent.
Le token peut ensuite être utilisé pour finaliser la transaction dans votre système de gestion des commandes ou CRM sans que ce système ne soit exposé aux données de carte réelles. Si le paiement échoue (fonds insuffisants, carte expirée), l'agent peut demander au client de renouveler la saisie via le même processus DTMF sécurisé.
Cas d'usage avancés : paiements hybrides et multi-canal
La tokenisation DTMF de PCI Proxy EU s'intègre dans des stratégies de paiement multi-canal avancées. Un token créé lors d'un paiement téléphonique peut être réutilisé pour des transactions ultérieures via d'autres canaux (web, mobile), permettant une expérience client cohérente sans que le client n'ait à ressaisir ses données de carte. Cette interopérabilité des tokens entre canaux est particulièrement précieuse pour les centres d'appels qui gèrent à la fois des clients e-commerce et téléphoniques.
Les centres d'appels gérant des remboursements et refacturations bénéficient également de la tokenisation : le token COF stocké lors du premier paiement peut être utilisé pour émettre des remboursements partiels ou complets sans accès au PAN, simplifiant les opérations de service client tout en maintenant la conformité PCI DSS.
Sécurisez vos paiements téléphoniques avec la tokenisation DTMF : découvrir PCI Proxy EU.