Eine PCI-konforme API zu integrieren bedeutet nicht, eine sichere REST-Schnittstelle zu bauen: Es bedeutet, eine Architektur zu entwerfen, in der Entwickler und interne Systeme nie Klartext-PAN-Daten berühren. Dies ist der Kernunterschied zwischen einer generischen API mit Zahlungen und einer wirklich PCI-konformen Integration. PCI Proxy EU bietet genau diese Architektur: der PAN fließt direkt in den Vault, und der Entwickler arbeitet ausschließlich mit Token.
Was "PCI-konform" für eine API bedeutet
Eine "sichere API" ist nicht per se eine PCI-konforme API. Sicherheit bezieht sich auf Transportverschlüsselung, Authentifizierung, Rate Limiting und Schutz vor OWASP-Schwachstellen. PCI-Konformität ist spezifischer: Sie erfordert, dass Kartendaten (PAN, CVV, Ablaufdatum in Kombination) in einer CDE verwaltet werden, die nach PCI DSS v4 zertifiziert ist, und dass Systeme außerhalb der CDE Karteninformationen nicht im Klartext speichern oder verarbeiten.
Eine PCI-konforme API für Zahlungen sollte daher drei Eigenschaften haben: (1) Kartendaten berühren nie den Server des Händlers – sie werden direkt vom Client-Browser oder der App an den Vault gesendet; (2) der Server des Händlers empfängt und verarbeitet nur Token, nie PANs; (3) die Tokenisierungs-API wird von einem PCI DSS Level 1 zertifizierten Anbieter bereitgestellt, der eine gültige AOC (Attestation of Compliance) ausstellen kann.
Wie die Integration mit PCI Proxy EU funktioniert
PCI Proxy EU stellt eine REST-API und ein JavaScript-Widget für die Kartendatenerfassung bereit. In einer typischen Webintegration fügt der Entwickler das PCI Proxy EU-Widget in die Checkout-Seite ein: Das Widget rendert die Formularfelder für die Kartennummer, das Ablaufdatum und den CVV direkt im gesicherten Kontext von PCI Proxy EU, nicht auf dem Server des Händlers. Der Kunde gibt Kartendaten ein, das Widget sendet sie direkt an den PCI Proxy EU-Vault und gibt dem Merchant-System einen Token zurück.
Ab diesem Moment arbeitet der Merchant-Server ausschließlich mit Token: Er kann den Token für wiederkehrende Zahlungen, Rückerstattungen, Teilzahlungen oder andere nachfolgende Transaktionen verwenden, ohne jemals den Klartext-PAN zu berühren. Dies eliminiert den Merchant-Server vollständig aus der CDE für den Kartenerfassungsfluss. In Szenarien mit Callcenter oder MOTO ermöglicht PCI Proxy EU eine sichere telefonische Eingabe über DTMF oder Webmasken, wiederum ohne dass der Agent Klartext-Kartendaten sieht oder verarbeitet.
PCI-Scope-Reduzierung für Entwickler
Für einen Entwickler, der eine PCI-konforme API integriert, ist der praktische Effekt erheblich: Wenn der Entwickler-Server nie PAN im Klartext empfängt oder verarbeitet, ist die Serverinfrastruktur des Entwicklers nicht im PCI-Scope. Logs, Caches, temporäre Dateien, Datenbanken – keine dieser Ressourcen erfordert PCI DSS-Kontrollen, wenn sie Tokens enthalten, keine PANs.
Dies bedeutet praktisch, dass Händler, die PCI Proxy EU für die Kartenerfassung verwenden, ein SAQ A oder SAQ A-EP statt eines SAQ D einreichen können. Die Anzahl der anwendbaren Anforderungen sinkt von über 300 auf 22–30, was den Compliance-Aufwand erheblich reduziert. Für Fintechs und Startups bedeutet dies, dass die PCI-Compliance nicht mehr ein monatelanger Prozess ist, der den Go-Live blockiert, sondern etwas, das in einigen Tagen im Rahmen des normalen Entwicklungszyklus abgeschlossen werden kann.
Häufig gestellte Fragen
Kann ich den PCI Proxy EU-Token für wiederkehrende Zahlungen verwenden?
Ja. Der von PCI Proxy EU ausgestellte Token ist ein dauerhafter Card-on-File-Token, der für spätere Transaktionen verwendet werden kann: Abonnements, Verlängerungen, partielle Beträge oder Rückerstattungen. Der Händler übergibt den Token zusammen mit dem Transaktionsbetrag an den PSP, der ihn in den zugehörigen PAN für die Autorisierung beim Acquirer auflöst, ohne dass der Händler jemals den PAN im Klartext berührt.
Ist das PCI Proxy EU-JavaScript-Widget für alle E-Commerce-Plattformen kompatibel?
Das Widget ist framework-agnostisch und kann in jede Web-Plattform integriert werden: React, Vue, Angular, Vanilla JS, WordPress/WooCommerce, Shopify über Apps. Die Integration erfordert die Einbindung des Skripts und die Konfiguration der Callback-Felder, um den Token zu empfangen. Für native Mobile-Apps stellt PCI Proxy EU SDKs für iOS und Android bereit, die dasselbe sicherheitsarchitektonische Muster replizieren.
Welchen SAQ kann ich nach der Integration von PCI Proxy EU für alle Zahlungsflüsse einreichen?
Wenn alle Kartendatenerfassungsflüsse (online, MOTO, Telefon) über PCI Proxy EU-Tools routen und der Händlerserver nie PANs im Klartext empfängt, kann der Händler im Allgemeinen ein SAQ A (für rein webbasierte E-Commerce-Händler) oder SAQ A-EP (wenn der Händler Seitenelemente verwaltet, die die Karteneingabe beinhalten) einreichen. Der genaue SAQ-Typ wird vom Acquirer in Abstimmung mit den PCI-Netzwerkrichtlinien bestimmt.
Entwickeln Sie eine Zahlungsintegration und möchten verstehen, wie Sie PCI Proxy EU in Ihre Architektur integrieren? Entdecken Sie die technische Dokumentation.