Card tokenization and PAN-safe streams

1) Why tokenization and what is PAN-safe

• minimize PCI DSS scoping (and cost of control),
• reduce the risk of leaks,
• improve authorization (auto-substitution, COF, one-click),
• simplify multi-PSP routing and write-offs.

PAN-safe flow is such a user and server scenario where PAN appears only inside an isolated trusted perimeter (walt/TSP/PSP iframe) and never passes through your backend/logs/event buses in clear text.

2) Types of tokens and life cycle

2. 1 Vault tokens (private)

Generated by your token wallet or third-party safe provider.
Bound to PAN, but the reversible correspondence is stored only in the waltz (HSM).
Used to route to any PSP/Akavayer (flexibility).
Plus: independence from schemes; Minus: requires its own compliant-walt.

2. 2 Network tokens (circuit; Visa/Mastercard/AmEx TSP)

Released by networks via TSP; often accompanied by device-/merchant-binding and cryptogram.
Improve authorization: higher approval rate, less fraud-falls-positives.
Support auto-update when the card is re-issued.
Minus: tie for PSP/processor support and market coverage.

2. 3 Single-use and reusable (COF)

Single-use: for one-time scrapping/initiation of SCA.
COF (Card-on-File): for subscriptions, retrays, repeated payments.

2. 4 Life cycle

1. Initialization: the front receives payment fields not from your domain (hosted fields/iframe TSP/PSP).
2. Tokenization: PAN → token (vault or network), cryptogram release (if required).
3. Storage: token and metadata (BIN data, schema, term, domain binding).
4. Usage: authorization/kapchur/retrai by token.
5. Rotation/update: auto-updates (network), card updater (vault/PSP).
6. Recall/deletion: at the request of the user (GDPR/DSR) or by retention policy.

3) PAN-safe architectural patterns

3. 1 Client layer (web/mobile)

Hosted fields/iFrame SDK from PSP/TSP: PAN is entered outside your DOM.
Your frontend receives only the token + non-critical attributes (last 4 digits, BIN-meta).
SCA/3DS starts through the provider; your servers get the result/verdict.

3. 2 Payments Orchestrator service

Does not see PAN; operates with tokens.
Implements: routing (primary/secondary PSP), idempotency keys, retries/backoff, smart-routing (by BIN/region/conversion).
Holds the config of PSP rules and health samples (SLI/SLO).
Knows how to detokenize a proxy (only as a "service shuttle" inside a trusted perimeter to the track).

3. 3 Token-Walt (if own)

HSM backend, FIPS compatible encryption.
Network isolation/segmentation, AAA (MFA/least privilege), audit logs, key rotation.
API: tokenize (), detokenize (), rotate (), purge () with thin ACL/Scopes.
Format-preserving encryption (FPE) support - optional if you need visually "masked" storage.

3. 4 Event bus and DWH

In events, only tokens and secure metadata.
Link of authorization ↔ kapchur/refand via payment_id (not PAN).
PAN and CVV are not allowed in BI repositories.

4) Streams (text charts)

4. 1 Primary COF (save card)

1. User → Hosted Fields (PSP/TSP iframe) introduces PAN.
2. PSP/TSP → returns token (+ device binding/cryptogram).
3. Front → Backend (Orchestrator): `{token, order_id, context}`.
4. Orchestrator → PSP: 'auth' by token (3DS challenge possible).
5. PSP → Orchestrator: `auth_result`.
6. Orchestrator → Wallet Service: save 'token' and meta.

PAN does not appear anywhere in your services.

4. 2 Re-charge/subscription

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

4. 3 Failover и smart-routing

Rule: 'IF PSP_A. degraded OR BIN in {X} THEN PSP_B ELSE PSP_A`.
For network tokens, make sure that both PSPs support their acceptance; otherwise, hold the binary binding (network + vault).

5) 3DS and SCA in PAN-safe loop

3DS2 is launched from the hosted SDK; your servers accept status aliases (frictionless, challenge, failure).
Link the 3DS verdict to the payment_id; store transactional artifacts (ARes, CRes refs) without PAN.
For reclamation (MIT/recurring/unscheduled COF) - correctly mark the transaction flags (type MIT, original CIT reference).

6) Security, compliance and data policy

PCI DSS scope: front without PAN, backend without PAN ⇒ assessment is simplified (SAQ-A/variations). If there is an intrinsic walt/detokenation - scoop above (SAQ-D).
HSM/key rotation: periodic rotation of master keys, dual control, split knowledge.
GDPR/DSR: Delete token and associated metadata at user request (leaving PAN unknown).
Logs/trails: strictest disguises, leak detectors (DLP), sanitization when serializing errors.
Segmentation: Walt in the highlighted segment; access - only on mTLS and short-lived tokens (STS).

7) Integration with PSP/acaviers

7. 1 Minimum PSP capability for PAN-safe

Hosted fields/SDK with tokenization.
Accept network tokens (if possible) and/or export vault tokens.
Card updater, COF markings, MIT flags.
3DS server + SCA orchestration.
Webhooks with idempotent delivery and signature.

7. 2 Multi-PSP architecture

"Connector" abstraction in Orchestrator (unify fields).
Table "weights/priorities" + health pings.
BIN policy table (schema, region, product, risk scoring).
Fallback PSP for critical routes (fallback SLA).

8) Card upgrades and token longevity

Network tokens: auto-updates on re-release (best for LTV).
Vault tokens: use card updater (via PSP/3rd-party).
Tracking expiration dates, notifications to the user, soft retreats (exponential backoff + jitter).
Binding COF to account-id, not to PII user, for simple reissue.

9) Retreas, bugs and idempotency

Idempotency-key = хеш(merchant_id, account_id, order_id, attempt_n).
Error categorization: hard (decline code constant) vs soft (timeout, network, risk pending).
Backoff: 1m → 10m → 1h → 24h with upper bound and hard-decline.
Webhooks deduplication - Store event_id and state machine transitions.

10) Reconciliation and Finance

Maintain a payment ledger without PAN: 'payment _ id', 'psp _ txn _ id', 'arn/rrn', 'token _ id', statuses.
Daily rec file ingestion from PSP/Akavayer; comparison of amounts, commissions, chargebacks.
Separate pipelines for refunds/voids/chargebacks; coordination with billing/accounting.

PSP/Country/BIN KPIs

11) Metrics and Objectives (KPIs)

Security/Compliance

% of services that never see PAN (target: 100%).
PCI scope level (below - better).

Business

Approval Rate (AR) by network vs vault.
COF retention rate, share of auto-updated methods.
D + 0/D + 1 reconciliation discrepancies (target: → 0).

Technique

Tokenization time p95.
Share of transactions through the PSP fallback.
Number of detokenations (objective: minimize, only inside the roller).

12) Frequent anti-patterns

PAN/CVV logging in exceptions.
Client forms without hosted fields.

Sending PAN via your API bus is "temporary."

Mixing tokens from different domains without an explicit policy (risk).
No routing card (all payments "in one PSP").
Storage of 3DS artifacts with redundant PII.

13) Implementation plan (by steps)

1. Frontend: integrate hosted fields/SDK, remove your own payment forms.
2. PSP/TSP choice: we confirm support for network tokens, 3DS2, webhooks, card updater.
3. Orchestrator: abstraction layer over PSP, routing rules, idempotency, retries.
4. Walt (optional): choose managed-vault or build your own (HSM, ACL, rotations).
5. Data/events: ban PAN on bus and DWH; Implement DLP gate in CI/CD.
6. Compliance: update PCI scope, procedures, audit logs, masking tests.
7. Observability: AR/LSR/latency metrics by PSP, degradation alerts, dashboards.
8. Economics: A/B test network vs vault tokens by AR/fraud/value, flow optimization.

14) PAN-safe checklist

• Enter PAN in iframe/hosted fields only.
• Beckend never accepts PAN/CVV.
• Tokens encrypted in storage, keys in HSM, rotation enabled.
• 3DS2 and SCA are correctly labeled (CIT/MIT/COF).
• Multi-PSP routing and failover tested.
• Card updater (network/PSP) enabled.
• Logs/trails/dumps - without PAN (masks/sanitizers).
• Reconciliation and chargeback pipelines without PAN.
• GDPR/token removal policies implemented.
• Metrics and alerts cover token flow quality.

15) Glossary Brief

PAN: Card number.
Token (vault/network) - A safe substitute for PAN.
TSP: Token Service Provider.
COF/MIT/CIT: card storage/merchant initiative/customer initiative.
HSM: hardware security module.
SCA/3DS2: strong authentication/card authentication protocol.

16) Summary

Tokenization is a basic technique for reducing PCI risks, increasing approval rate and flexible payment routing in iGaming. Combine network tokens (through conversion and auto-updates) with vault tokens (through control and independence), build PAN-safe flow with hosted fields, orchestrator, key management and transparent observability from authorization to reconciliation. This will give security, scale and predictable monetization.