Buy Now Pay Later PCIis een van de gebieden waarin de PCI DSS-verantwoordelijkheidsketen het meest complex in kaart te brengen is. BNPL-modellen zoals Klarna, Scalapay, Afterpay en hun Europese concurrenten omvatten meerdere partijen in één transactie: de handelaar, de BNPL-aanbieder, het kaartnetwerk en in sommige gevallen een afzonderlijke acquirer. Begrijpen hoe kaartgegevens worden verwerkt en wie verantwoordelijk is voor de PCI DSS-naleving in dit ecosysteem is essentieel voor elke handelaar die betalingen in termijnen aanbiedt.
BNPL en PCI DSS: de verantwoordelijkheidsketen
In de meest gangbare BNPL-modellen treedt de aanbieder (Klarna, Scalapay enz.) op als financier: hij betaalt de handelaar op het moment van aankoop het volledige bedrag en beheert vervolgens de kredietrelatie met de consument voor de volgende termijnen. De consument kan de termijnen met een krediet- of debetkaart betalen, waarbij kaartgegevens via het platform van de BNPL-aanbieder worden overgedragen. De handelaar ontvangt alleen het orderbedrag, zonder de kaartgegevens van de consument voor de termijnen te zien.
Dat betekent dat de handelaar voor de pure BNPL-component buiten de kaartgegevensstroom valt: de PCI DSS-perimeter voor die transactie hoort bij de BNPL-aanbieder, niet bij de handelaar. Wanneer de handelaar daarnaast echter ook traditionele kaartbetalingen accepteert (wat bijna altijd het geval is), blijft zijn PCI-perimeter voor die stromen actief. De veelvoorkomende fout is de aanname dat de integratie van een BNPL-aanbieder de PCI-verplichtingen volledig elimineert: ze worden alleen verkleind voor transacties die via dat specifieke kanaal worden afgehandeld.
De BNPL-handelaar: welke kaartgegevens hij werkelijk aanraakt
Er zijn BNPL-modelvarianten waarbij de handelaar sterker bij kaartgegevens betrokken is. Bij "door de handelaar gefinancierde BNPL" of white-labeloplossingen kan de handelaar het termijnplan rechtstreeks beheren zonder externe BNPL-aanbieder. In die gevallen moet de handelaar kaartgegevens voor volgende termijnen opslaan of er toegang toe kunnen krijgen, en breidt de PCI-perimeter zich aanzienlijk uit. Card-on-file-tokenisatie wordt dan noodzakelijk om deze termijnen te beheren zonder kaartgegevens in de systemen van de handelaar bloot te stellen.
Zelfs bij BNPL-modellen met een externe aanbieder zijn er scenario's waarin de handelaar indirect kaartgegevens aanraakt: maatwerkintegraties die gegevens via de server van de handelaar naar de BNPL-aanbieder verzenden, e-commerceplatforms die gegevens verzamelen voor doorsturen naar de BNPL-aanbieder, of analysesystemen die betalingsinformatie loggen. Elk van deze scenario's kan de PCI-perimeter van de handelaar uitbreiden, ook wanneer het bedrijfsmodel BNPL is.
Hoe tokenisatie BNPL vereenvoudigt
Voor handelaren die interne of white-label-BNPL aanbieden, is tokenisatie de natuurlijke oplossing voor het wetsconform beheren van volgende termijnen. De kaartgegevens worden eenmalig vastgelegd en getokeniseerd, en het token wordt gebruikt om elke termijn te belasten. De handelaar slaat nooit eenPANin platte tekst op, de PCI-perimeter wordt teruggebracht tot enkel het token, en termijnen worden verwerkt via de kluis, die richting de PSP detokeniseert en overdraagt. Het model is identiek aan de standaard terugkerende facturatie, met de extra termijnlogica in het systeem van de handelaar.
Voor handelaren die externe BNPL-aanbieders zoals Klarna of Scalapay gebruiken, blijft tokenisatie nuttig voor het parallelle traditionele kaartkanaal. Eén enkele kluis die zowel de tokens van het kaartkanaal als eventuele interne BNPL-integraties beheert, vereenvoudigt de totale architectuur en verkleint het aantal te beheren PCI-perimeters.PCI-naleving voor handelarenis veel eenvoudiger te beheren met één enkel aggregatiepunt voor kaartgegevens.
Veelgestelde vragen
Heb ik nog PCI DSS-verplichtingen wanneer ik Klarna of Scalapay gebruik?
Dat hangt af van hoe de integratie is opgezet en welke andere betalingsmethoden u accepteert. Wanneer de BNPL-integratie een pure "doorsturing" is (de consument wordt naar het platform van de aanbieder doorgestuurd om kaartgegevens in te voeren) en u geen traditionele kaarten accepteert, is uw PCI-perimeter minimaal. Wanneer u ook traditionele kaarten accepteert of wanneer de integratie gegevens via uw server voert, blijft de PCI-perimeter actief.
Dekt de BNPL-aanbieder mijn volledige PCI-verantwoordelijkheid?
De BNPL-aanbieder dekt zijn eigen deel van de infrastructuur af, niet het uwe. Wanneer uw technische integratie kaartgegevens via uw systemen doorstuurt voordat ze naar de aanbieder worden verstuurd, bevindt u zich voor dat deel binnen het PCI-bereik. Lees de technische documentatie van de integratie zorgvuldig en controleer hoe kaartgegevens in de werkelijke gegevensstroom worden verwerkt.
Hoe verloopt een terugboeking bij een getokeniseerde BNPL-betaling?
In een getokeniseerd BNPL-model worden terugboekingen afgehandeld op het niveau van elke afzonderlijke termijnbelasting. Het token dat voor elke termijn wordt gebruikt, wordt door de kluis gedetokeniseerd, de transactie wordt bij de PSP betwist met de oorspronkelijke PAN, en het terugboekingsproces volgt de normale regels van het kaartnetwerk. De kluis houdt een volledig logboek bij van elke detokenisering als bewijs bij een geschil.
Biedt u intern of white-label-BNPL aan en wilt u termijnen PCI DSS-conform beheren zonder kaartgegevensopslag?Ontdek PCI Proxy EU.
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