Tokenizarea cardurilor și fluxurile PAN-safe

1) De ce tokenizarea și ce este PAN-safe

• minimiza PCI DSS scoping (și costul de control),
• reduce riscul de scurgeri,
• îmbunătățirea autorizației (auto-substituție, COF, un singur clic)
• simplificați rutarea și scrierea multi-PSP.

Fluxul PAN-safe este un astfel de scenariu de utilizator și server în care PAN apare numai într-un perimetru izolat de încredere (walt/TSP/PSP iframe) și nu trece niciodată prin backend/busteni/evenimente autobuze în text clar.

2) Tipuri de jetoane și ciclul de viață

2. 1 jetoane seif (privat)

Generate de portofelul dvs. token sau furnizor de siguranță terță parte.
Legat de PAN, dar corespondența reversibilă este stocată numai în vals (HSM).
Folosit pentru a ruta la orice PSP/Akavayer (flexibilitate).
Plus: independența față de scheme; Minus: necesită propriul său walt compatibil.

2. 2 jetoane de rețea (circuit; Visa/Mastercard/AmEx TSP)

Lansat de rețele prin intermediul PCV; adesea însoțită de dispozitiv/comerciant-legare și criptogramă.
Îmbunătățiți autorizarea: rată de aprobare mai mare, mai puține fraude-falls-pozitive.
Suport auto-actualizare atunci când cardul este re-emis.
Minus: cravată pentru suport PSP/procesor și acoperire pe piață.

2. 3 De unică folosinţă şi reutilizabile (COF)

Unică utilizare: pentru o singură dezmembrare/inițiere a SCA.
COF (Card-on-File): pentru abonamente, retribuții, plăți repetate.

2. 4 Ciclul de viață

1. Inițializare: partea din față primește câmpuri de plată care nu provin de la domeniul dvs. (câmpuri găzduite/iframe TSP/PSP).
2. Tokenizare: PAN → token (seif sau rețea), eliberare criptogramă (dacă este necesar).
3. Stocare: token și metadate (date BIN, schemă, termen, legare domeniu).
4. Utilizare: autorizare/kapchur/retrai prin token.
5. Rotație/actualizare: actualizări automate (rețea), actualizator de carduri (seif/PSP).
6. Rechemare/ștergere: la cererea utilizatorului (GDPR/DSR) sau prin politica de păstrare.

3) modele arhitecturale PAN-safe

3. 1 strat client (web/mobil)

Câmpuri găzduite/iFrame SDK din PSP/TSP: PAN este introdus în afara DOM.
Frontendul dvs. primește doar atributele token + non-critice (ultimele 4 cifre, BIN-meta).
SCA/3DS începe prin intermediul furnizorului; serverele dvs. primesc rezultatul/verdictul.

3. 2 Plăți Serviciu orchestrator

Nu vede PAN; operează cu jetoane.
Implementări: rutare (PSP primar/secundar), chei idempotency, retries/backoff, smart-routing (prin BIN/regiune/conversie).
Deține configurarea regulilor PSP și a probelor de sănătate (SLI/SLO).
Știe cum să detokenize un proxy (numai ca un „serviciu de transfer” în interiorul unui perimetru de încredere la pista).

3. 3 Token-Walt (dacă este propriu)

Backend HSM, criptare compatibilă FIPS.
Izolarea/segmentarea rețelei, AAA (MFA/cel mai puțin privilegiu), jurnalele de audit, rotația cheii.
API: tokenize (), detokenize (), rotate (), purge () cu ACL subțire/Scopes.
Suport pentru criptarea în format (FPE) - opțional dacă aveți nevoie de stocare „mascată” vizual.

3. 4 Event bus și DWH

În evenimente, numai jetoane și metadate sigure.
Legătura de autorizare ↔ kapchur/refand prin payment_id (nu PAN).
PAN și CVV nu sunt permise în depozitele BI.

4) Fluxuri (diagrame text)

4. 1 COF primar (card de salvare)

1. Câmpurile găzduite → utilizatori (iframe PSP/TSP) introduc PAN.
2. PSP/TSP → returnează jetonul (+ legarea dispozitivului/criptograma).
3. Front → Backend (Orchestrator): '{token, order_id, context}'.
4. Orchestrator → PSP: „auth” prin token (provocare 3DS posibilă).
5. PSP → Orchestrator: 'auth _ result'.
6. Orchestrator → Wallet Service: salvați „token” și meta.

PAN nu apare nicăieri în serviciile dvs.

4. 2 Re-taxa/abonament

1. Scheduler/Business → Orchestrator: „taxă (token, sumă)”.
2. Orchestrator → PSP: 'capture/auth'.
3. PSP → Orchestrator: rezultat + arn/rrn.
4. Orchestrator → Ledger/Reconciliere.

4. 3 Failover и rutare inteligentă

Regula: "DACĂ PSP_A. degradat SAU BIN în {X} APOI PSP_B ELSE PSP_A'.
Pentru jetoanele de rețea, asigurați-vă că ambele PSP-uri acceptă acceptarea lor; în caz contrar, țineți legătura binară (rețea + seif).

5) 3DS și SCA în buclă PAN-safe

3DS2 este lansat de la SDK gazduit; serverele dvs. acceptă pseudonime de stare (fără frecare, provocare, eșec).
Conectați verdictul 3DS la payment_id; stoca artefacte tranzactionale (ARes, CRes refs) fara PAN.
Pentru recuperare (MIT/recurent/neprogramat COF) - marcați corect steagurile tranzacției (tip MIT, referință CIT originală).

6) Politica de securitate, conformitate și date

Domeniul PCI DSS: front fără PAN, backend fără PAN ⇒ evaluarea este simplificată (SAQ-A/variații). Dacă există un walt intrinsec/detokenation - scoop deasupra (SAQ-D).
Rotație HSM/cheie: rotație periodică a cheilor master, control dual, cunoștințe împărțite.
GDPR/DSR: Ștergeți jetonul și metadatele asociate la cererea utilizatorului (lăsând PAN necunoscut).
Jurnale/trasee: cele mai stricte deghizări, detectoare de scurgeri (DLP), igienizare la serializarea erorilor.
Segmentare: Walt în segmentul evidențiat; acces - numai pe mTLS și jetoane de scurtă durată (STS).

7) Integrarea cu PSP/acaviers

7. 1 Capacitate minimă PSP pentru PAN-safe

Câmpuri găzduite/SDK cu tokenizare.
Acceptați jetoanele de rețea (dacă este posibil) și/sau jetoanele pentru seifuri de export.
Actualizator de carduri, marcaje COF, steaguri MIT.
3DS server + SCA orchestrație.
Cârlige web cu livrare și semnătură idempotente.

7. 2 Arhitectură multi-PSP

„Conector” abstractizare în Orchestrator (unify fields).
Tabelul „greutăți/priorități” + ping-uri de sănătate.
Tabelul de politici BIN (schemă, regiune, produs, scor de risc).
PSP de rezervă pentru rutele critice (SLA de rezervă).

8) upgrade-uri de card și longevitate token

Jetoane de rețea: actualizări automate privind relansarea (cel mai bun pentru LTV).
Jetoane seif: utilizați actualizator de card (prin PSP/3rd-party).
Urmărirea datelor de expirare, notificări către utilizator, retrageri moi (backoff exponențial + jitter).
Legarea COF la cont-id, nu la utilizator PII, pentru o simplă reemitere.

9) Retrageri, bug-uri și idempotență

Idempotency-key = ( , , .
Clasificarea erorilor: hard (cod declin constant) vs soft (timeout, rețea, risc în așteptare).
Backoff: 1m → 10m → 1h → 24h cu partea superioară și hard-declin.
Webhooks deduplication - Stocați event_id și tranzițiile mașinilor de stat.

10) Reconciliere și finanțe

Mențineți un registru de plăți fără PAN: 'payment _ id',' psp _ txn _ id', 'arn/rrn',' token _ id', statusuri.
Ingestia zilnică de fișiere rec de la PSP/Akavayer; compararea sumelor, comisioanelor, chargebacks.
conducte separate pentru restituiri/anulări/chargebacks; coordonarea cu facturarea/contabilitatea.

IPS PSP/țară/BIN

11) Valori și obiective (KPI)

Securitate/Conformitate

% din serviciile care nu văd niciodată PAN (țintă: 100%).
Nivelul domeniului de aplicare al PCI (mai jos - mai bine).

Afaceri

Rata de omologare (AR) prin bolta de rețea vs.
Rata de retenție COF, cota de metode actualizate automat.
D + 0/D + 1 discrepanțe de reconciliere (obiectiv: → 0).

Tehnica

Timpul de tokenizare p95.
Cota tranzacțiilor prin intermediul rezervei PSP.
Numărul de detokenations (obiectiv: minimiza, numai în interiorul rolei).

12) Frecvente anti-modele

PAN/CVV logare în excepții.
Formulare client fără câmpuri găzduite.
Trimiterea PAN prin intermediul autobuzului API este „temporară”.
Amestecarea tokenurilor din diferite domenii fără o politică explicită (risc).
Fără card de rutare (toate plățile „într-un singur PSP”).
Depozitarea artefactelor 3DS cu PII redundant.

13) Planul de implementare (pe etape)

1. Frontend: integrați câmpurile găzduite/SDK, eliminați propriile formulare de plată.
2. Alegerea PSP/TSP: confirmăm suportul pentru jetoane de rețea, 3DS2, cărți web, actualizator de carduri.
3. Orchestrator: strat de abstracție peste PSP, reguli de rutare, idempotență, retries.
4. Walt (opţional): alegeţi seiful gestionat sau construiţi-vă singur (HSM, ACL, rotaţii).
5. Date/evenimente: ban PAN pe autobuz și DWH; Implementați poarta DLP în CI/CD.
6. Conformitate: actualizați domeniul de aplicare PCI, proceduri, jurnale de audit, teste de mascare.
7. Observabilitate: metrica AR/LSR/latenta prin PSP, alerte de degradare, tablouri de bord.
8. Economie: A/B test network vs seif tokens by AR/fraud/value, flow optimization.

14) Lista de verificare PAN-safe

• Introduceți PAN numai în câmpurile iframe/găzduite.
• Beckend nu acceptă niciodată PAN/CVV.
• Jetoane criptate în stocare, chei în HSM, rotație activată.
• 3DS2 și SCA sunt corect etichetate (CIT/MIT/COF).
• Multi-PSP rutare și failover testat.
• Actualizator card (rețea/PSP) activat.
• Jurnale/trasee/halde - fără PAN (măști/dezinfectante).
• Reconciliere și conducte de încărcare fără PAN.
• Politicile de eliminare GDPR/token implementate.
• Metrica și alerte acoperă calitatea fluxului de token.

15) Glosar Brief

Numărul cardului.
Token (seif/rețea) - Un înlocuitor sigur pentru PAN.
TSP: Furnizor de servicii Token.
COF/MIT/CIT: stocarea cardurilor/inițiativa comerciantului/inițiativa clientului.
HSM: modul de securitate hardware.
SCA/3DS2: protocol puternic de autentificare/autentificare card.

16) Rezumat

Tokenizarea este o tehnică de bază pentru reducerea riscurilor PCI, creșterea ratei de aprobare și rutarea flexibilă a plăților în iGaming. Combina token-uri de rețea (prin conversie și auto-actualizări) cu token-uri seif (prin control și independență), construi fluxul PAN-safe cu domenii găzduite, orchestrator, management cheie și observabilitate transparentă de la autorizare la reconciliere. Acest lucru va oferi securitate, scară și monetizare previzibilă.