Card-on-File-Tokenisierung ist die Lösung, die es Unternehmen ermöglicht, Karteninhaberdaten für wiederkehrende Zahlungen, Abonnements und One-Click-Checkout zu verwalten, ohne die PAN jemals in ihren eigenen Systemen zu speichern. Es ist der Anwendungsfall, der am häufigsten die Entscheidung treibt, Tokenisierung zu adoptieren: Die Alternative – die direkte Speicherung von Kartendaten – bringt erhebliche PCI-DSS-Pflichten und anhaltende Risiken mit sich.
Was ist Card-on-File und warum es ein Compliance-Problem darstellt
Ein Card-on-File-Szenario tritt auf, wenn ein Händler Kundenkartendaten nach der ersten Transaktion für zukünftige Nutzung speichert: Abonnementverlängerungen, regelmäßige Rechnungsstellung, „Mit einer Karte bezahlen"-Buttons, die den Kunden nicht bitten, die Daten erneut einzugeben. Aus PCI-DSS-Perspektive ist die direkte Speicherung der PAN in einer Händler-Datenbank eine der riskantesten Praktiken: Sie erweitert erheblich den CDE-Perimeter, erfordert umfangreiche Verschlüsselungskontrollen, Zugangsverwaltung und kontinuierliche Überwachung.
PCI DSS verbietet das Speichern des CVV/CVC nach der Autorisierung kategorisch: Das bedeutet, dass Card-on-File-Implementierungen, die CVV speichern (oder es für jede Folgetransaktion anfordern), nicht konform sind. Die einzige PCI-konforme Methode zur Handhabung von Folgezahlungen ohne erneute Eingabe von Kartendaten ist die Tokenisierung: Der Händler speichert einen Token; der zertifizierte Vault behält die PAN und verarbeitet Belastungen auf Anfrage.
Wie Card-on-File-Tokenisierung funktioniert
Der Fluss einer Card-on-File-Tokenisierungsintegration beginnt bei der ersten Zahlungstransaktion. Der Kunde gibt Kartendaten auf der gehosteten Seite oder dem SDK von PCI Proxy EU ein. Der Vault generiert einen Token und gibt ihn an den Händler zurück. Der Händler verknüpft den Token mit dem Kundenkonto und speichert ihn in seiner Datenbank. Ab diesem Zeitpunkt tritt der Händler keine Kartendaten mehr: Für jede Folgetransaktion sendet er den Token und den zu berechnenden Betrag an PCI Proxy EU, der die PAN aus dem Vault abruft und die Belastung beim Acquirer oder PSP initiiert.
Der Fluss ist für den Endkunden vollständig transparent. Abonnements verlängern sich automatisch, ohne dass der Kunde eingreifen muss. Für manuelle Folgekäufe kann der Händler dem Kunden eine Benutzeroberfläche anzeigen, die eine maskierte Kartenreferenz anzeigt (z.B. die letzten 4 Ziffern), sodass der Kunde die gespeicherte Karte auswählen oder eine neue eingeben kann. Beides ohne PAN auf den Servern des Händlers.
Token-Portabilität: Karten-Update ohne Benutzerinteraktion
Ein kritischer Aspekt von Card-on-File-Tokenisierung ist das Management der Token-Aktualisierung, wenn eine Karte abläuft oder ersetzt wird. Ohne ein automatisiertes Update-System muss der Händler den Kunden bitten, die neue Karte einzugeben – eine schlechte Benutzererfahrung, die zu Abonnement-Abbrüchen führt. Mit PCI Proxy EU und dem Account-Updater-Programm von Visa und Mastercard ist die Aktualisierung automatisch: Wenn die Karte erneuert wird, aktualisiert der Vault die PAN, ohne den Token zu ändern. Der Händler verwendet denselben Token weiterhin, und Folgetransaktionen schlagen nicht fehl.
Diese Token-Portabilität erstreckt sich auch auf PSP-Wechsel. Wenn ein Händler den Zahlungsanbieter wechselt, kann er die von PCI Proxy EU verwalteten Tokens auf einen neuen PSP übertragen, ohne Kunden um Kreditkartendaten zu bitten. Der Vault fungiert als PSP-agnostischer Tresor, der den Wert der gespeicherten Kartenbasis bei Infrastrukturänderungen schützt.
Häufig gestellte Fragen
Kann ich das CVV für Folgezahlungen speichern?
Nein. PCI DSS verbietet kategorisch das Speichern des CVV/CVC nach der Autorisierung, auch für Card-on-File-Szenarien. Für Folgezahlungen nach der ersten Transaktion ist das CVV nicht erforderlich: Die Autorisierung erfolgt mit dem Token, den PAN-Daten, die im Vault gespeichert sind, und der zuvor ausgehandelten Händlervereinbarung. Das Anfordern des CVV bei jeder Folgetransaktion ist eine Option, die die Nutzererfahrung verbessern kann, ist aber kein Standard bei Abonnementmodellen.
Was passiert, wenn der Kunde eine Karte löschen möchte?
Der Händler sendet eine Token-Widerruf-Anfrage an den PCI Proxy EU Vault. Der Vault deaktiviert den Token und löscht die damit verbundene PAN. Aus DSGVO-Sicht kann der Händler die Löschung der persönlichen Daten mit dem Widerruf des Tokens verknüpfen und so die Ausübung des Rechts auf Löschung durch den Kunden erfüllen.
Kann ein Token über mehrere PSPs hinweg verwendet werden?
Ja, wenn die Tokens vom Vault von PCI Proxy EU ausgegeben werden. Die PCI Proxy EU Architektur ermöglicht es Händlern, denselben Token zur Initiierung von Zahlungen über verschiedene PSPs zu verwenden, ohne die Karte erneut eingeben zu müssen. Der Vault wählt die anzuweisende PAN basierend auf dem Token aus und übermittelt sie an den ausgewählten PSP. Dies ist der Schlüsselvorteil der PSP-agnostischen Tokenisierung.
Speichern Sie niemals eine PAN: Verwalten Sie Card-on-File mit dem sicheren Token-Vault von PCI Proxy EU. Entdecken Sie PCI Proxy EU.