MOTO-betalingen (Mail Order / Telephone Order) vormen een van de meest complexe nalevingsscenario's voor PCI DSS. Wanneer een callcenter-medewerker kaartgegevens van een klant mondeling ontvangt, valt het volledige callcenter — werkstations, opnamesystemen, telefonie-infrastructuur — binnen de CDE. De verplichtingen zijn aanzienlijk. Er bestaan echter gevestigde technische oplossingen, met name DTMF-tokenisatie, die het callcenter volledig uit het PCI-bereik verwijderen.
Wat zijn MOTO-betalingen en waarom zijn ze een PCI-probleem
MOTO staat voor Mail Order / Telephone Order: transacties waarbij kaartgegevens buiten een fysiek terminal via post of telefoon worden medegedeeld. In de callcentercontext is MOTO elke keer dat een medewerker een kaartnummer, vervaldatum en CVV van een klant ontvangt om een betaling te verwerken. Dit is een 'Card Not Present'-transactietype met een verhoogd frauderisico en strengere PCI-vereisten.
Het PCI-probleem ontstaat door de directe blootstelling van medewerkers aan gevoelige kaartgegevens. Wanneer de medewerker de PAN hoort, ziet en in zijn systeem invoert, valt alles wat hij aanraakt binnen de CDE: zijn werkstation, het CRM-systeem, het gespreksopnamesysteem (dat de PAN in het audio heeft vastgelegd) en alle netwerkinfrastructuurcomponenten waardoorheen deze gegevens stromen. PCI DSS legt dan uitgebreide verplichtingen op aan al deze systemen.
DTMF-tokenisatie: het callcenter uit het PCI-bereik verwijderen
De meest effectieve oplossing voor het beheer van PCI DSS-naleving bij MOTO-betalingen is DTMF-tokenisatie. In plaats van dat de medewerker het kaartnummer mondeling opneemt, wordt het gesprek kort overgedragen naar een beveiligd systeem dat de klant vraagt de kaartcijfers via de telefoontoetsen in te voeren. De DTMF-tonen (gegenereerd door het indrukken van toetsen) worden rechtstreeks vastgelegd door de PCI DSS-gecertificeerde infrastructuur van PCI Proxy EU, zonder ooit het audio te passeren dat de medewerker hoort.
De PAN wordt getokeniseerd door de PCI Proxy EU-kluis en alleen een token wordt teruggegeven aan het CRM-systeem van de medewerker. De medewerker ziet nooit het echte kaartnummer: hij ziet alleen een bevestiging dat de betaling veilig is vastgelegd, en de token die hij kan gebruiken voor orderverwerking. Het callcenter verlaat het PCI-bereik: geen nalevingsverplichtingen voor medewerkersworkstations, geen PAN in gespreksopnamen, geen uitgebreide fysieke beveiligingsprotocollen.
Welke SAQ geldt voor MOTO-callcenters?
Welke SAQ van toepassing is op een MOTO-callcenter hangt af van hoe kaartgegevens worden verwerkt. Wanneer medewerkers PAN's horen en in een systeem invoeren, geldt doorgaans SAQ C of SAQ D, met tientallen vereisten voor fysieke beveiliging, toegangscontrole en netwerkbeheer. Wanneer DTMF-tokenisatie is geïmplementeerd en medewerkers nooit toegang hebben tot PAN's, kan het callcenter zich kwalificeren voor SAQ B-IP (voor DTMF-oplossingen) of in bepaalde architecturen voor eenvoudigere SAQ's.
De acquirer is het juiste aanspreekpunt voor de bepaling van de correcte SAQ op basis van de specifieke architectuur. Het is belangrijk de specifieke betaalstroom, de gebruikte DTMF-oplossing en de certificeringsstatus ervan te delen met de acquirer, om te garanderen dat de gekozen SAQ correct is en de werkelijke nalevingsblootstelling weerspiegelt.
Veelgestelde vragen
Wat is het verschil tussen MOTO en gewone telefoonbetalingen?
'MOTO' is een specifieke transactiecategorie die door kaartnetwerken wordt gedetecteerd: het geeft aan dat de kaarthouder niet fysiek aanwezig was en de kaart niet in het terminal werd gestoken of contactloos werd gelezen. Alle telefoonbetalingen waarbij een medewerker kaartgegevens ontvangt, zijn MOTO. Deze classificatie beïnvloedt de kosten (MOTO heeft doorgaans hogere interchange-tarieven) en de verplichtingen (geen chip-en-pinverificatie, strengere regels voor opname en documentatie).
Moeten wij gespreksopnamen verwijderen die PAN's bevatten?
Wanneer bestaande opnamen PAN's bevatten, vormt dit een PCI DSS-overtreding. PCI DSS verbiedt uitdrukkelijk het opslaan van gevoelige authenticatiegegevens na autorisatie, inclusief PAN's in audiovorm. De corrigerende maatregel vereist de identificatie en veilige vernietiging van deze opnamen conform een gedocumenteerde procedure voor gegevensverwijdering. Voor de toekomst elimineert DTMF-tokenisatie het probleem volledig: de PAN zit nooit in het audio.
Hoe beïnvloedt DTMF de klantervaring?
De klantervaring met DTMF is doorgaans acceptabel wanneer de oplossing correct is geïmplementeerd. De medewerker begeleidt de klant door de stap waarbij gevraagd wordt de kaart via het toetsenbord in te voeren, en de medewerker blijft tijdens het gehele proces actief in het gesprek (hoort geen tonen, maar kan zien of de invoer geslaagd was). Voor minder technisch onderlegde klanten volstaat een korte, duidelijke uitleg van de medewerker. Goed ontworpen DTMF-systemen hebben een time-outmechanisme en maken een eenvoudige terugvaloptie mogelijk wanneer de klant problemen ondervindt.
Beheert u MOTO-betalingen zonder PCI-risico voor het callcenter? Ontdek PCI Proxy EU DTMF.
Hulp nodig bij PCI-naleving?
Ons team helpt u uw CDE in kaart te brengen, het juiste SAQ te kiezen en tokenisatie te implementeren met gegevensresidentie in de EU.
Neem contact op