Tokenisierung von Karten und PAN-Safe-Streams

1) Warum Tokenisierung und was ist PAN-safe

• Minimierung des PCI-DSS-Scope (und der Kontrollkosten),
• das Risiko von Leckagen zu verringern,
• Verbesserung der Autorisierung (Auto-Substitution, COF, One-Click),
• Vereinfachen Sie Multi-PSP-Routing und erneute Abbuchungen.

Ein PAN-Safe-Stream ist ein solches Benutzer- und Server-Szenario, bei dem die PAN nur innerhalb eines isolierten Trusted Perimeter (Walth/TSP/PSP-Iframe) erscheint und niemals im Klartext durch Ihre Beckend/Logs/Event-Busse geht.

2) Arten von Token und Lebenszyklus

2. 1 Vault-Token (privat)

Generiert von Ihrem Token-Walth oder einem Drittanbieter-Tresor-Anbieter.
Sie sind an die PAN gebunden, aber die reversible Übereinstimmung wird nur im Walth (HSM) gespeichert.
Wird für das Routing zu jedem PSP/Acavayer (Flexibilität) verwendet.
Plus: Unabhängigkeit von Systemen; Der Nachteil: Es wird ein eigener Compliant-Walth benötigt.

2. 2 Netzwerk-Token (Schaltung; Visa/Mastercard/AmEx TSP)

Ausgestellt von Netzwerken über TSP; oft begleitet von Device-/Merchant-Bindung und Kryptogramm.
Verbesserung der Autorisierung: höhere Approval-Rate, weniger Betrug-Fols-Positive.
Unterstützt Auto-Updates, wenn die Karte neu ausgegeben wird.
Nachteil: Bindung an PSP/CPU-Unterstützung und Abdeckung der Märkte.

2. 3 Einweg (Single-Use) und wiederverwendbar (COF)

Single-Use: für eine einmalige SCA-Abbuchung/Initiierung.
COF (Card-on-File): für Abonnements, Retrays, Nachzahlungen.

2. 4 Lebenszyklus

1. Initialisierung: Front empfängt Zahlungsfelder nicht von Ihrer Domain (hosted fields/iframe TSP/PSP).
2. Tokenisierung: PAN → Token (Vault oder Netzwerk), Ausgabe eines Kryptogramms (falls erforderlich).
3. Speicherung: Token und Metadaten (BIN-Daten, Schema, Laufzeit, Domain-Binding).
4. Verwendung: Autorisierung/Capchur/Retrai durch Token.
5. Rotation/Update: Auto-Updates (Netzwerk), Card-Updater (Vault/PSP).
6. Widerruf/Löschung: auf Anfrage des Nutzers (DSGVO/DSR) oder gemäß der Retentionsrichtlinie.

3) Architektonische Muster PAN-sicher

3. 1 Client-Ebene (Web/Mobile)

Hosted fields/iFrame SDK von PSP/TSP: Die PAN wird außerhalb Ihres DOM eingegeben.
Ihr Frontend erhält nur ein Token + unkritische Attribute (letzte 4 Ziffern, BIN-meta).
SCA/3DS startet über den Provider; Ihre Server erhalten ein Ergebnis/Urteil.

3. 2 Service „Zahlungen Orchestrator“

Sieht keine PAN; betreibt Token.
Implementiert: Routing (primary/secondary PSP), idempotency keys, retries/backoff, smart-routing (nach BIN/Regionen/Konversionen).
Hält config PSP-Regeln und Gesundheitsproben (SLI/SLO).
Kann einen Detokenize-Proxy (nur als „Service-Shuttle“ innerhalb des vertrauenswürdigen Umfangs zum Walzer).

3. 3 Token-Walth (wenn eigene)

HSM-Backend, FIPS-konforme Verschlüsselung.
Netzwerkisolierung/Segmentierung, AAA (MFA/Least Privilege), Audit-Protokolle, Schlüsselrotation.
API: tokenize (), detokenize (), rotate (), purge () mit dünnen ACLs/Scopes.
Unterstützung von Format-Preserving Encryption (FPE) - optional, wenn visuell „maskierbare“ Speicherung benötigt wird.

3. 4 Eventbus und DWH

In Ereignissen gibt es nur Token und sichere Metadaten.
Link Autorisierung ↔ Capchur/Refand durch payment_id (nicht PAN).
PAN und CVV sind in BI-Speichern verboten.

4) Threads (Textdiagramme)

4. 1 Primärer COF (Kartenerhaltung)

1. User → Hosted Fields (PSP/TSP iframe) führt PAN ein.
2. PSP/TSP gibt → Token (+ device binding/cryptogram) zurück.
3. Front → Backend (Orchestrator): `{token, order_id, context}`.
4. Orchestrator → PSP: 'auth' per Token (3DS Challenge möglich).
5. PSP → Orchestrator: `auth_result`.
6. Orchestrator → Wallet Service: Speichern Sie' Token 'und Meta.

Die PAN erscheint nirgendwo in Ihren Diensten.

4. 2 Erneute Abbuchung/Abonnement

1. Scheduler/Business → Orchestrator: `charge(token, amount)`.
2. Orchestrator → PSP: `capture/auth`.
3. PSP → Orchestrator: Ergebnis + arn/rrn.
4. Orchestrator → Ledger/Reconciliation.

4. 3 Failover и smart-routing

Regel: "IF PSP_A. degraded OR BIN in {X} THEN PSP_B ELSE PSP_A`.
Stellen Sie bei Netzwerk-Token sicher, dass beide PSPs ihre Akzeptanz unterstützen; Andernfalls halten Sie die binäre Bindung (network + vault).

5) 3DS und SCA in PAN-sicherer Schleife

3DS2 wird vom Hosted-SDK gestartet; Ihre Server akzeptieren Aliasstatus (frictionless, challenge, failure).
Verbinden Sie das 3DS-Urteil mit dem payment_id; Transaktionsartefakte (ARes, CRes refs) ohne PAN speichern.
Bei Rekarantierungen (MIT/recurring/unscheduled COF) - Transaktions-Flags (MIT-Typ, ursprüngliche CIT-Referenz) korrekt kennzeichnen.

6) Sicherheit, Compliance und Datenpolitik

PCI DSS scope: Front ohne PAN, Beckend ohne PAN ⇒ Auswertung vereinfacht (SAQ-A/Variationen). Wenn es eine eigene Walzen-/Entgiftung gibt - scope oben (SAQ-D).
HSM/Schlüsselrotation: periodische Hauptschlüsselrotationen, duale Steuerung, geteiltes Wissen.
DSGVO/DSR: Löschen des Tokens und der zugehörigen Metadaten auf Anfrage des Benutzers (wobei die PAN unbekannt bleibt).
Logs/Traces: strengste Maskierungen, Leckdetektoren (DLP), Sanitarisierung bei der Serialisierung von Fehlern.
Segmentierung: Walth im dedizierten Segment; Zugriff nur über mTLS und Short-Life Token (STS).

7) Integration mit PSP/Acavayer

7. 1 Minimaler Satz von PSP-Funktionen für PAN-safe

Hosted fields/SDK mit Tokenisierung.
Annahme von Netzwerk-Token (wenn möglich) und/oder Export von Vault-Token.
Kartenupdater, COF-Markierungen, MIT-Flags.
3DS Server + SCA Orchestrierung.
Webhooks mit idempotent Lieferung und Signatur.

7. 2 Multi-PSP-Architektur

Abstraktion des „Konnektors“ in Orchestrator (Vereinheitlichung der Felder).
Tabelle „Gewichte/Prioritäten“ + Gesundheit-Pings.
BIN-Policy-Tabelle (Schema, Region, Produkt, Risikobewertung).
Backup-PSP für kritische Routen (Fallback-SLA).

8) Karten-Update und Token-Haltbarkeit

Netzwerk-Token: Auto-Updates bei Neuveröffentlichung (besser für LTV).
Vault Token: Verwenden Sie Card Updater (über PSP/3rd-Party).
Nachverfolgung von Ablaufdaten, Benachrichtigungen an den Nutzer, Soft Retrays (exponentieller Backoff + Jitter).
Verknüpfen Sie den COF mit der Account-ID, nicht mit dem Benutzer per PII, für eine einfache Neuausstellung.

9) Retrays, Fehler und idempotency

Idempotency-key = хеш(merchant_id, account_id, order_id, attempt_n).
Fehlerkategorisierung: hard (decline code permanent) vs soft (timeout, network, risk pending).
Backoff: 1m → 10m → 1h → 24h mit Obergrenze und Abbruch bei Hard-Decline.
Webhooks-Deduplizierung: Speichern Sie event_id und Statusübergänge (State Machine).

10) Reconciliation und Finanzen

Führen Sie einen Payment Ledger ohne PAN: 'payment _ id', 'psp _ txn _ id', 'arn/rrn', 'token _ id', Status.
Tägliche rec Datei ingestion von PSP/acavayer; Vergleich von Beträgen, Provisionen, Chargebacks.
Separate Pipelines für refunds/voids/chargebacks; Abstimmung mit Abrechnung/Buchhaltung.
KPIs nach PSP/Land/BIN-Tabs.

11) Metriken und Ziele (KPIs)

Sicherheit/Compliance

% der Dienste, die niemals eine PAN sehen (Ziel: 100%).
PCI-Scope-Level (niedriger ist besser).

Unternehmen

Approval Rate (AR) nach Tokentyp (network vs vault).
COF Retention Rate, Anteil der automatisch aktualisierten Methoden.
D + 0/D + 1 Rekonsilierungsabweichungen (Ziel: → 0).

Technik

Tokenisierungszeit p95.
Anteil der Transaktionen über fallback PSP.
Anzahl der Entgiftungen (Ziel: minimieren, nur innerhalb des Walzes).

12) Häufige Anti-Muster

Protokollierung von PAN/CVV in Ausnahmen.
Clientformulare ohne Hosted-Felder.
PAN-Versand über Ihren API-Bus „temporär“.
Mischen von Token verschiedener Domains ohne explizite Richtlinie (Risiko).
Keine Routing-Karte (alle Zahlungen „in einem PSP“).
Speicherung von 3DS-Artefakten mit redundanten PIIs.

13) Implementierungsplan (in Schritten)

1. Frontend: Hosted Fields/SDK integrieren, eigene Zahlungsformulare entfernen.
2. PSP/TSP-Auswahl: Wir bestätigen die Unterstützung für Netzwerk-Token, 3DS2, Webhooks, Card Updater.
3. Orchestrator: Abstraktionsebene über PSP, Routing-Regeln, Idempotency, Retries.
4. Walth (optional): Wir wählen managed-vault oder bauen unser eigenes (HSM, ACL, Rotationen).
5. Daten/Ereignisse: Verbot von PAN im Bus und DWH; DLP-Gate in CI/CD implementieren.
6. Compliance: PCI-Bereich, Verfahren, Auditprotokolle, Maskierungstests aktualisieren.
7. Beobachtbarkeit: AR/LSR/Latenzmetriken durch PSP, Degradationsalerts, Dashboards.
8. Wirtschaft: A/B-Test Netzwerk vs vault Token auf AR/frod/Kosten, Optimierung flow.

14) Checkliste PAN-sicher

• PAN-Eingabe nur in iframe/hosted fields.
• Beckend akzeptiert niemals PAN/CVV.
• Token werden im Speicher verschlüsselt, Schlüssel im HSM, Rotation aktiviert.
• 3DS2 und SCA sind korrekt gekennzeichnet (CIT/MIT/COF).
• Multi-PSP-Routing und Failover getestet.
• Card updater (network/PSP) aktiviert.
• Logs/Traces/Dumps - ohne PAN (Masken/Desinfektionsmittel).
• Reconciliation und Chargeback-Pipelines ohne PAN.
• GDPR/Token Removal Policies implementiert.
• Metriken und Alerts decken die Token-Flow-Qualität ab.

15) Glossar kurz

PAN: Kartennummer.
Token (Tresor/Netzwerk): Sicherer PAN-Ersatz.
TSP: Token Service Provider (Netzwerk-Token-Service).
COF/MIT/CIT: die Aufbewahrung der Karte/Initiative die mertschanta/Initiative des Kunden.
HSM: Hardware-Sicherheitsmodul.
SCA/3DS2: die starke Authentifizierung/Protokoll der Authentifizierung nach den Karten.

16) Zusammenfassung

Tokenisierung ist eine grundlegende Technik zur Reduzierung von PCI-Risiken, zum Wachstum der Annahmequote und zum flexiblen Zahlungsrouting in iGaming. Kombinieren Sie Network-Token (durch Conversion und Auto-Updates) mit Vault-Token (durch Kontrolle und Unabhängigkeit), bauen Sie einen PAN-Safe-Flow mit Hosted-Fields, Orchestrator, Key-Management und transparenter Beobachtbarkeit von Autorisierung bis Reconciliation. Dies wird Sicherheit, Umfang und vorhersehbare Monetarisierung geben.