Betalingstokenisatie

Wat wordt vervangen, en wat een token eigenlijk is

Wat wordt beschermd, is het primaire rekeningnummer — het PAN, het lange nummer op de voorkant van de kaart — samen met de vervaldatum en, op het moment van invoer, de beveiligingscode. Die drie waarden zijn kaartgegevens, en het bewaren ervan sleept een bedrijf mee in het dure deel van PCI DSS.

Een token vervangt het PAN door een waarde die er geen wiskundige relatie mee heeft. Dat is het onderscheid met encryptie, en het is geen pedant onderscheid: cijfertekst kan worden omgekeerd door iedereen die de sleutel verkrijgt, terwijl een token alleen kan worden opgelost door de kluis die de mapping bevat. Het stelen van een tokendatabase levert niets op zonder ook de kluis te compromitteren, wat een afzonderlijk systeem is onder afzonderlijke controle.

Tokens komen in twee vormen en worden constant verward. Formaatbehoudende tokens lijken op kaartnummers — dezelfde lengte, dezelfde checksum passerend — zodat ze kunnen reizen door systemen die zijn gebouwd om een PAN te dragen. Opaak tokens zijn willekeurige identificatoren, de `tok_`- en `pm_`-achtige strings die bekend zijn van moderne API's, en ze kunnen nergens als een kaart fungeren.

De belangrijkere verwarring is die tussen eenmalig gebruik en meervoudig gebruik. De waarde die een client-side betaalveld aan uw server doorgeeft, is meestal een eenmalig token: het bestaat om één kaartinvoer van de browser naar de processor te transporteren zonder uw infrastructuur aan te raken, en het vervalt bij het eerste gebruik. De waarde die u opslaat voor toekomstige facturatie is een heel ander object — een duurzame kluisreferentie, bewust gecreëerd, die blijft bestaan om opnieuw te worden belast. Het behandelen van het eerste als het tweede is hoe teams bij de eerste verlenging ontdekken dat ze nooit iets hebben opgeslagen.

Drie soorten tokens, en ze zijn niet uitwisselbaar

Het woord omvat verschillende regelingen die verschillen in wie de mapping beheert, en dat ene feit bepaalt alles over overdraagbaarheid, veerkracht en wat er gebeurt wanneer de kaart opnieuw wordt uitgegeven.

Een gateway- of PSP-kluis-token is het meest voorkomende geval en het meest beperkte: de mapping bevindt zich in de database van één provider en betekent niets daarbuiten. Een onafhankelijke token service provider heeft dezelfde vorm met de kluis onder een ander dak, precies gekozen zodat de kluis niet eigendom is van de partij die u mogelijk wilt verlaten. Een netwerktoken, beschreven in zijn eigen vermelding, wordt uitgegeven door het kaartnetwerk en is de enige van de drie die de netwerken zelf onderhouden.

Hoe het de PCI-scope vermindert, en waar de scope niet verdwijnt

De PCI DSS-scope volgt kaartgegevens. Systemen die een PAN opslaan, verwerken of verzenden, vallen binnen de scope; systemen die alleen tokens bewaren, vallen er niet onder, omdat een token geen kaartgegevens is. Tokenisatie is daarom in de eerste plaats een scope-reductietechniek.

De reductie materialiseert alleen als het kaartnummer uw servers werkelijk nooit bereikt. Dat is wat hosted fields, een iframe van de processor, client-side tokenisatie en volledige redirects allemaal beogen te bereiken. Een integratie die de kaart naar uw backend stuurt en daar tokeniseert, heeft de opslag buiten de scope verplaatst, terwijl de verwerking en verzending er stevig binnen blijven, wat een veel kleinere besparing is dan het architectuurdiagram suggereert.

Wat overblijft, is de betaalpagina zelf. U beheert nog steeds de pagina die het betaalveld laadt, en een script dat in die pagina is geïnjecteerd, kan een kaart lezen voordat de processor deze ooit ziet. PCI DSS v4 pakt dit direct aan met vereisten die het beheer van scripts op betaalpagina's en sabotage detectie op die pagina's behandelen — 6.4.3 en 11.6.1. Geen van beide wordt door tokenisatie ontslagen.

De eerlijke samenvatting is dat tokenisatie een handelaar verplaatst van het bewijzen van de veiligheid van een kaartkluis naar het bewijzen van de integriteit van een checkout-pagina. Dat is een veel betere ruil, en het is niet hetzelfde als geen verplichtingen hebben.

De overdraagbaarheidsvalkuil: een gateway-token beweegt niet

De eigenschap die een token veilig maakt, is dat het betekenisloos is buiten de context waarin het is uitgegeven. Die eigenschap maakt geen onderscheid tussen een aanvaller en uw volgende betaalprovider.

Het migreren van een bestand met opgeslagen betaalgegevens vereist daarom een kluis-naar-kluis-overdracht: de verliezende provider exporteert de kaartgegevens onder PCI-compatibele voorwaarden naar de verkrijgende provider, die deze opnieuw tokeniseert. Dit is een gevestigde procedure, beide partijen kunnen het doen, en het vereist de medewerking van een bedrijf wiens commerciële belang gediend is bij het niet plaatsvinden van de overdracht. Het alternatief is om elke actieve abonnee te vragen een kaart opnieuw in te voeren, en een aanzienlijk deel van hen zal dit eenvoudigweg niet doen — dat is geen churn die u terugwint, het is churn die u heeft veroorzaakt.

De te beveiligen clausule is een recht om opgeslagen betaalgegevens te exporteren naar een genoemde alternatieve provider, op verzoek, binnen een gestelde termijn, tegen een gestelde prijs. Het kost niets om te onderhandelen voordat u een abonneebestand heeft en is bijna onmogelijk te verkrijgen zodra het bestand bestaat.

Het opslaan van betaalgegevens voor terugkerende facturatie

Een token alleen is niet voldoende om een klant opnieuw te factureren. Wat een latere belasting geldig maakt, is het toestemmingsrecord dat ernaast staat, en dat record heeft verschillende onderdelen die een naïeve migratie achterlaat.

De opgeslagen betaalgegevens hebben het mandaat nodig: waartoe de klant heeft ingestemd, wanneer ze hebben ingestemd, de versie van de voorwaarden die ze hebben geaccepteerd, en de frequentie en het bedrag waarmee ze hebben ingestemd. Het heeft het transactietype nodig — terugkerend, termijn of ongepland — omdat de netwerken deze anders behandelen. En het heeft de netwerktransactie-identificatie nodig die is geretourneerd door de oorspronkelijke door de klant geïnitieerde autorisatie, waarnaar volgende door de handelaar geïnitieerde belastingen moeten verwijzen om te worden herkend als geautoriseerde voortzettingen in plaats van als losstaande belastingen tegen een kaart.

Dat laatste veld is degene die ontbreekt. Een migratie die tokens verplaatst maar niet de originele netwerktransactie-identificatoren, zorgt ervoor dat de ontvangende verwerker geen verlengingen kan presenteren als geldige door de handelaar geïnitieerde transacties, en het resultaat is een autorisatiepercentage dat daalt in de eerste factureringscyclus na de verhuizing om redenen die niemand in het projectplan had voorzien.

Naast de betaalgegevens zelf is het de moeite waard om te bewaren wat u mag bewaren voor weergave en voor voorspelling: kaartmerk, de laatste vier cijfers en de vervaldatum. Dat zijn de gegevens waarmee een klant herkent welke kaart is opgeslagen, en waarmee u de betaalgegevens kunt identificeren die vóór de volgende verlenging zullen verlopen en die klanten kunt contacteren voordat de betaling mislukt.