Buy Now Pay Later PCI ist einer der Bereiche, in dem die PCI DSS-Verantwortungskette am komplexesten zu kartieren ist. BNPL-Modelle wie Klarna, Scalapay, Afterpay und ihre europäischen Wettbewerber umfassen mehrere Akteure in einer einzigen Transaktion: den Händler, den BNPL-Anbieter, das Kartennetzwerk und in einigen Fällen einen separaten Acquirer. Zu verstehen, wer Kartendaten verarbeitet und wer für die PCI DSS-Compliance in diesem Ökosystem verantwortlich ist, ist für jeden Händler, der Ratenzahlungen anbietet, unerlässlich.
BNPL und PCI DSS: die Verantwortungskette
In den gängigsten BNPL-Modellen agiert der Anbieter (Klarna, Scalapay usw.) als Finanzier: Er zahlt dem Händler zum Zeitpunkt des Kaufs den vollen Betrag und verwaltet dann die Kreditbeziehung mit dem Verbraucher für die nachfolgenden Raten. Der Verbraucher kann die Raten mit einer Kredit- oder Debitkarte bezahlen, wobei Kartendaten durch die Plattform des BNPL-Anbieters übertragen werden. Der Händler erhält nur den Auftragsbetrag, ohne die Kartendaten des Verbrauchers für die Raten zu sehen.
Das bedeutet, dass für die reine BNPL-Komponente der Händler außerhalb des Kartendatenflusses liegt: Der PCI DSS-Perimeter für diese Transaktion gehört dem BNPL-Anbieter, nicht dem Händler. Wenn der Händler jedoch parallel auch traditionelle Kartenzahlungen akzeptiert (was fast immer der Fall ist), bleibt sein PCI-Perimeter für diese Flüsse aktiv. Der häufige Fehler ist die Annahme, dass die Integration eines BNPL-Anbieters die PCI-Verpflichtungen vollständig eliminiert: Sie reduziert sie nur für Transaktionen, die über diesen spezifischen Kanal abgewickelt werden.
Der BNPL-Händler: welche Kartendaten er tatsächlich berührt
Es gibt BNPL-Modellvarianten, bei denen der Händler stärker in Kartendaten eingebunden ist. Bei "Händler-finanziertem BNPL" oder White-Label-Lösungen kann der Händler den Ratenplan direkt ohne externen BNPL-Anbieter verwalten. In diesen Fällen muss der Händler Kartendaten für nachfolgende Raten speichern oder darauf zugreifen können, und der PCI-Perimeter erweitert sich erheblich. Die Card-on-File-Tokenisierung wird notwendig, um diese Raten zu verwalten, ohne Kartendaten in den Systemen des Händlers offenzulegen.
Selbst bei BNPL-Modellen mit externem Anbieter gibt es Szenarien, in denen der Händler indirekt Kartendaten berührt: benutzerdefinierte Integrationen, die Daten über die Server des Händlers an den BNPL-Anbieter übertragen, E-Commerce-Plattformen, die Daten vor der Weiterleitung an den BNPL-Anbieter sammeln, oder Analysesysteme, die Zahlungsinformationen protokollieren. Jedes dieser Szenarien kann den PCI-Perimeter des Händlers erweitern, auch wenn das Geschäftsmodell BNPL ist.
Wie Tokenisierung BNPL vereinfacht
Für Händler, die internes oder White-Label-BNPL anbieten, ist die Tokenisierung die natürliche Lösung zur gesetzeskonformen Verwaltung nachfolgender Raten. Die Kartendaten werden einmal erfasst, tokenisiert, und das Token wird verwendet, um jede Rate zu belasten. Der Händler speichert niemals eine Klartext-PAN, der PCI-Perimeter wird auf das Token allein reduziert, und Raten werden über den Vault verarbeitet, der gegenüber dem PSP detokenisiert und überträgt. Das Modell ist identisch mit der Standard-Wiederkehrabrechnung, mit der zusätzlichen Ratenlogik im System des Händlers.
Für Händler, die externe BNPL-Anbieter wie Klarna oder Scalapay nutzen, bleibt die Tokenisierung für den parallelen traditionellen Kartenkanal nützlich. Ein einziger Vault, der sowohl die Kartenkanal-Tokens als auch etwaige interne BNPL-Integrationen verwaltet, vereinfacht die Gesamtarchitektur und reduziert die Anzahl der zu verwaltenden PCI-Perimeter. Händler-PCI-Compliance lässt sich mit einem einzigen Kartendaten-Aggregationspunkt weitaus leichter verwalten.
Häufig gestellte Fragen
Habe ich noch PCI DSS-Verpflichtungen, wenn ich Klarna oder Scalapay verwende?
Das hängt davon ab, wie die Integration aufgebaut ist und welche anderen Zahlungsmethoden Sie akzeptieren. Wenn die BNPL-Integration eine reine "Weiterleitung" ist (der Verbraucher wird auf die Plattform des Anbieters weitergeleitet, um Kartendaten einzugeben) und Sie keine traditionellen Karten akzeptieren, ist Ihr PCI-Perimeter minimal. Wenn Sie auch traditionelle Karten akzeptieren oder wenn die Integration Daten über Ihre Server führt, bleibt der PCI-Perimeter aktiv.
Übernimmt der BNPL-Anbieter meine gesamte PCI-Verantwortung?
Der BNPL-Anbieter deckt seinen eigenen Teil der Infrastruktur ab, nicht Ihren. Wenn Ihre technische Integration Kartendaten über Ihre Systeme leitet, bevor sie an den Anbieter gesendet werden, befinden Sie sich für diesen Teil im PCI-Scope. Lesen Sie die technische Dokumentation der Integration sorgfältig und überprüfen Sie, wie Kartendaten im tatsächlichen Fluss behandelt werden.
Wie funktioniert eine Rückbuchung bei einer tokenisierten BNPL-Zahlung?
In einem tokenisierten BNPL-Modell werden Rückbuchungen auf der Ebene jeder einzelnen Ratenbelastung abgewickelt. Das für jede Rate verwendete Token wird vom Vault detokenisiert, die Transaktion wird mit der ursprünglichen PAN beim PSP bestritten, und der Rückbuchungsprozess folgt den normalen Regeln des Kartennetzwerks. Der Vault führt ein vollständiges Protokoll jeder Detokenisierung, um im Streitfall Beweise zu unterstützen.
Bieten Sie internes oder White-Label-BNPL an und möchten Raten PCI DSS-konform ohne Kartendatenspeicherung verwalten? Entdecken Sie PCI Proxy EU.