Checkout-Keys und Kassierer-Keys
Cardflo verwendet Checkout-Keys und Kassierer-Keys, um Händlern sichere und flexible Integrationsoptionen zu bieten. Checkout-Keys verwalten die Initialisierung von Zahlungssitzungen und die Erfassung von Kundendaten, während Kassierer-Keys die serverseitige Transaktionsverarbeitung erleichtern.
Diese Trennung gewährleistet die PCI-Konformität und robuste Sicherheit für alle Zahlungsströme.
- Kategorie
- Entwickler
- Funktionen
- 10
- Verfügbar auf
- Alle Pläne
Der Überblick
Die Trennung von Zugangsdaten in Checkout-Schlüssel und Kassierer-Schlüssel stellt eine grundlegende Sicherheitsarchitektur in der modernen Zahlungs-Orchestrierung dar. Checkout-Schlüssel sind öffentlich zugängliche Bezeichner, die in clientseitigen Umgebungen wie Webbrowsern oder mobilen Anwendungen verwendet werden, um Zahlungsbestandteile zu initialisieren und sensible Karteninhaberdaten zu erfassen.
Diese Schlüssel ermöglichen es einem Händler, eine Kassenschnittstelle darzustellen, ohne sensible Backend-Berechtigungen preiszugeben. Umgekehrt sind Kassierer-Schlüssel eingeschränkte, serverseitige Zugangsdaten, die für die authentifizierte Kommunikation zwischen einem Händlerserver und dem Zahlungs-Gateway konzipiert sind.
Durch die Aufteilung dieser Rollen stellt das System sicher, dass eine Kompromittierung des clientseitigen Codes einem Angreifer nicht die Möglichkeit gibt, administrative Aktionen durchzuführen, wie z. B.
die Initiierung von Rückerstattungen oder die Erfassung autorisierter Zahlungen. Dieser architektonische Ansatz hilft, die PCI-DSS-Konformität aufrechtzuerhalten, indem der Umfang der Systeme, die direkt mit Rohzahlungsdaten interagieren, minimiert wird, während gleichzeitig eine programmierbare, granulare Kontrolle über Transaktionslebenszyklen ermöglicht wird.
Wie es funktioniert
Clientseitige Sitzungsinitialisierung
Die Integration beginnt damit, dass der Checkout-Schlüssel in der Frontend-Anwendung verwendet wird, um eine sichere Sitzung anzufordern. Dieser Schlüssel identifiziert die Händler-ID (MID) und autorisiert die Darstellung sicherer Zahlungselemente, wodurch sichergestellt wird, dass die Kartendetails des Kunden tokenisiert werden, bevor sie überhaupt die Händler-Infrastruktur erreichen.
Sichere Datentokenisierung
Während der Kunde seine Zahlungsdaten eingibt, erleichtert der Checkout-Schlüssel eine direkte Verbindung zum Vault. Sensible Felder wie PAN und CVV werden in temporäre Tokens umgewandelt.
Dieser Prozess stellt sicher, dass die Händlerumgebung außerhalb des primären Geltungsbereichs der PCI DSS-Anforderungen bleibt.
Server-zu-Server-Autorisierung
Sobald ein Token generiert wurde, verwendet der Händlerserver seinen Kassierer-Schlüssel, um eine formelle Autorisierung vom Acquirer anzufordern. Dieser private Schlüssel bestätigt, dass die Anfrage legitim ist und ermöglicht es dem Gateway, das temporäre Token den gespeicherten Zahlungsdaten zur Verarbeitung zuzuordnen.
Lebenszyklusverwaltung von Transaktionen
Aktionen nach der Autorisierung, einschließlich Erfassung, Abrechnung und Rückerstattungen, werden ausschließlich über den Kassierer-Schlüssel abgewickelt. Da diese Aktionen die Bewegung von Geldern beinhalten, erfordern sie die höhere Authentifizierungsstufe und den eingeschränkten Zugriff, den der serverseitige Kassierer-Schlüssel dem Händleradministrator bietet.
Warum es wichtig ist
Risiko- und Haftungsminderung
Die Aufteilung von Anmeldeinformationen reduziert den Wirkungsbereich einer potenziellen Sicherheitsverletzung. Wenn ein Checkout-Schlüssel aus einem Website-Quellcode abgefangen wird, kann der Angreifer ihn nicht verwenden, um Gelder abzuheben oder auf historische Transaktionsaufzeichnungen zuzugreifen.
Der Kassierer-Schlüssel bleibt auf einem sicheren Backend geschützt, um sicherzustellen, dass nur autorisierte Serverumgebungen Finanzbewegungen ausführen können, was eine entscheidende Verteidigung gegen gängige Injection-Angriffe ist.
Vereinfachte PCI DSS-Konformität
Durch die Verwendung von Checkout-Schlüsseln zur Handhabung von Kartendaten über gehostete Felder oder Komponenten qualifizieren sich Händler typischerweise für einen reduzierten Compliance-Aufwand, wie SAQ A oder SAQ A-EP.
Der Kassierer-Schlüssel stellt sicher, dass sensible Daten im Backend in einem tokenisierten Format behandelt werden, wodurch der Händler keine Rohen Kreditkarteninformationen auf seinen eigenen Servern speichern, verarbeiten oder übertragen muss.
Anwendungsfälle
E-Commerce-Webanwendungen
Händler verwenden Checkout-Schlüssel, um sichere Zahlungsformulare direkt in ihre Websites einzubetten, während der Kassierer-Schlüssel in ihrer Backend-Umgebung gespeichert wird, um die Erfassung von Geldern nach Bestätigung der Bestellung abzuschließen.
Native mobile Apps
Mobile Entwickler nutzen Checkout-Schlüssel in iOS- oder Android-Apps, um Zahlungssignaturen sicher zu erfassen, und verlassen sich auf serverseitige Kassierer-Schlüssel, um die komplexe Logik der Mehrwährungsabrechnung und wiederkehrenden Abrechnung zu verwalten.
Abonnement- und wiederkehrende Abrechnung
Nachdem der anfängliche Checkout-Schlüssel die Kartendetails erfasst hat, wird der Kassierer-Schlüssel verwendet, um ein vom Händler initiiertes Transaktions-Framework (MIT) einzurichten, das automatische Verlängerungen ohne weiteres Eingreifen des Kunden ermöglicht.
In Zahlen
Branchenstandards deuten darauf hin, dass die Auslagerung der Datenerfassung an gehostete Komponenten über clientseitige Schlüssel die Anzahl der anwendbaren PCI-Anforderungen um über 90 Prozent reduzieren kann.
Standardisierte schlüsselbasierte Architekturen ermöglichen es Entwicklern typischerweise, einen grundlegenden sicheren Checkout-Fluss innerhalb von etwa zwei Arbeitstagen Entwicklungszeit zu implementieren.
Professionelle Zahlungsgateways erfordern, dass 100 Prozent der serverseitigen Anfragen über einen privaten Schlüssel authentifiziert werden, um die Integrität des Transaktionslebenszyklus zu gewährleisten.
Verwandte Begriffe
Talk to our team about a live rollout on your acquiring stack.
Was Sie erhalten mit Checkout-Keys und Kassierer-Keys
- Isolieren Sie clientseitige Aktivitäten von sensiblen administrativen Backend-Funktionen für verbesserte Sicherheit
- Minimieren Sie das PCI-DSS-Exposition, indem Sie sicherstellen, dass Rohkartendaten die Händlerserver umgehen.
- Autorisieren Sie Frontend-Zahlungskomponenten über eingeschränkte, öffentlich zugängliche Checkout-Key-Anmeldeinformationen.
- Führen Sie sichere serverseitige Erfassungen und Rückerstattungen mit authentifizierten Kassierer-Key-Anfragen aus.
- Behalten Sie eine granulare Zugriffskontrolle über bestimmte API-Endpunkte und Transaktionsoperationen bei.
- Unterstützen Sie eine breite Palette von Frontend-Frameworks, ohne die Offenlegung von Backend-Anmeldeinformationen zu riskieren.
- Reduzieren Sie die Wahrscheinlichkeit betrügerischer Geldtransfers durch kompromittierten clientseitigen Code.
- Ermöglichen Sie die sichere Tokenisierung von Karteninhaberdaten am ursprünglichen Eingabepunkt.
- Ermöglichen Sie vom Händler initiierte Transaktionen für Abonnementmodelle mittels sicherer Backend-Authentifizierung.
- Bieten Sie klare Audit-Trails für clientseitige Sitzungen und serverseitige Verwaltungsaktionen.
A short scoping call, then a written plan for your MIDs.
Fragen zu Checkout-Keys und Kassierer-Keys
Worin besteht der Hauptunterschied zwischen einem Checkout-Schlüssel und einem API-Geheimschlüssel?
Ein Checkout-Schlüssel ist für den Einsatz in öffentlichen Umgebungen konzipiert, in denen der Code sichtbar ist, z. B.
in einem Browser. Er hat extrem eingeschränkte Berechtigungen und kann typischerweise nur ein Zahlungs-Token erstellen.
Ein API-Geheimschlüssel oder Kassierer-Schlüssel wird für serverseitige Operationen verwendet und hat die Befugnis, Geld zu bewegen, Rückerstattungen durchzuführen und auf sensible Händlerdaten zuzugreifen.
Die Trennung dieser Schlüssel stellt sicher, dass selbst wenn ein öffentlicher Schlüssel kopiert wird, die finanziellen Kernfunktionen des Händlerkontos durch serverseitige Authentifizierung geschützt bleiben.
Kann ein Checkout-Schlüssel verwendet werden, um eine Rückerstattung durchzuführen oder eine Transaktion zu stornieren?
Nein, Checkout-Schlüssel sind explizit eingeschränkt, um jegliche Operationen zu verhindern, die die Bewegung von Geldern vom Händlerkonto beinhalten. Rückerstattungen, Stornierungen und Erfassungen erfordern die Verwendung eines Kassierer-Schlüssels, der geheim gehalten und nur in einer sicheren Serverumgebung verwendet werden darf.
Diese Schutzmaßnahme ist beabsichtigt und verhindert, dass böswillige Akteure den clientseitigen Code manipulieren, um unautorisierte finanzielle Rückbuchungen oder Datenexporte vom Zahlungsgateway auszulösen.
Warum ist dieses Zwei-Schlüssel-System für die PCI-DSS-Konformität notwendig?
Die PCI-DSS-Konformität konzentriert sich darauf, wie Karteninhaberdaten behandelt werden. Durch die Verwendung eines Checkout-Schlüssels zur Tokenisierung von Kartendaten direkt vom Browser des Kunden an den Zahlungsabwickler berührt der Händler niemals die Rohdaten.
Der Kassierer-Schlüssel ermöglicht es dem Händler dann, mit diesem Token zu arbeiten. Diese Trennung ermöglicht es einem Händler, vereinfachte Konformitätsfragebögen zu verwenden, da seine Systeme niemals sensible Informationen wie Klartext-PANs besitzen.
Wie sollten Kassierer-Schlüssel innerhalb der Infrastruktur eines Händlers gespeichert werden?
Kassierer-Schlüssel müssen als hochsensible Anmeldeinformationen behandelt werden. Sie sollten niemals fest in Quelldateien kodiert oder in Versionskontrollsystemen wie Git gespeichert werden.
Stattdessen sollten sie mithilfe von Umgebungsvariablen oder einem dedizierten Dienst zur Geheimnisverwaltung verwaltet werden. Der Zugriff auf diese Schlüssel sollte auf die spezifischen Serverinstanzen beschränkt sein, die sie für die Kommunikation mit dem Zahlungsabwickler zur Transaktionsfinalisierung und Berichterstattung benötigen.
Was passiert, wenn ein Checkout-Schlüssel洩露iert oder kompromittiert wird?
Wenn ein Checkout-Schlüssel kompromittiert wird, sind die Auswirkungen im Allgemeinen gering im Vergleich zu einem Geheimschlüssel-Leak.
Ein Angreifer könnte den Schlüssel potenziell verwenden, um Junk-Daten einzureichen oder zu versuchen, Tokens über die MID des Händlers zu erstellen, aber er kann nicht auf bestehende Kundendaten oder Gelder zugreifen.
Es ist jedoch immer noch gängige Praxis, den kompromittierten Checkout-Schlüssel zu rotieren, um jegliche unautorisierte Verwendung der Frontend-Assets des Händlers zu verhindern und saubere Transaktionsprotokolle zu führen.
Unterstützen Kassierer-Schlüssel unterschiedliche Berechtigungsstufen basierend auf dem Benutzer?
Während der Kassierer-Schlüssel selbst ein hochrangiges Server-Zugangsdatum darstellt, erlauben branchenübliche Gateways oft die Erstellung mehrerer Schlüssel mit verschiedenen Bereichen. Zum Beispiel könnte ein Kassierer-Schlüssel auf schreibgeschützten Zugriff für die Berichterstattung beschränkt sein, während ein anderer die Befugnis haben könnte, Erfassungen und Rückerstattungen zu verarbeiten.
Dies folgt dem Prinzip der geringsten Rechte, um sicherzustellen, dass jeder Teil des Backend-Systems eines Händlers nur die Berechtigungen hat, die er zum Funktionieren benötigt.
Bereit für Geschwindigkeit?
Erzählen Sie uns von Ihrem Unternehmen. Wir vermitteln Ihnen die passenden Acquirer-Partner und den richtigen Weg, normalerweise innerhalb einer Woche.