Токенізація карт і PAN-safe потоки

1) Навіщо токенізація і що таке PAN-safe

• мінімізувати PCI DSS-скоуп (і вартість контролю),
• знизити ризик витоків,
• поліпшити авторизацію (автопідстановки, COF, one-click),
• спростити multi-PSP маршрутизацію і повторні списання.

PAN-safe потік - це такий користувацький і серверний сценарій, де PAN з'являється тільки всередині ізольованого довіреного периметра (вальт/TSP/PSP iframe) і ніколи не проходить через ваш бекенд/логи/шини подій у відкритому вигляді.

2) Види токенів і життєвий цикл

2. 1 Vault-токени (приватні)

Генеруються вашим токен-вальтом або стороннім сейф-провайдером.
Прив'язані до PAN, але оборотна відповідність зберігається тільки у вальті (HSM).
Використовуються для маршрутизації до будь-якого PSP/акавайеру (гнучкість).
Плюс: незалежність від схем; Мінус: потрібен власний compliant-вальт.

2. 2 Network-токени (схемні; Visa/Mastercard/AmEx TSP)

Випускаються мережами через TSP; часто супроводжуються device-/merchant-binding і криптограмою.
Покращують авторизацію: вище approval rate, менше фрод-фолс-позитивів.
Підтримують автооновлення при перевипуску карти.
Мінус: зав'язка на підтримку PSP/процесором і покриття ринків.

2. 3 Одноразові (single-use) і багаторазові (COF)

Single-use: для одноразового списання/ініціації SCA.
COF (Card-on-File): для підписок, ретраїв, повторних платежів.

2. 4 Життєвий цикл

1. Ініціалізація: фронт отримує платіжні поля не з вашого домену (хостед-поля/iframe TSP/PSP).
2. Токенізація: PAN → токен (vault або network), випуск криптограми (якщо потрібно).
3. Зберігання: токен і метадані (BIN-дані, схема, термін, домен-біндинг).
4. Використання: авторизація/капчур/ретраї по токену.
5. Ротація/оновлення: авто-апдейти (network), card updater (vault/PSP).
6. Відгук/видалення: за запитом користувача (GDPR/DSR) або за політикою ретенції.

3) Архітектурні патерни PAN-safe

3. 1 Клієнтський шар (web/mobile)

Hosted fields / iFrame SDK от PSP/TSP: PAN вводиться поза вашим DOM.
Ваш фронтенд отримує тільки токен + некритичні атрибути (останні 4 цифри, BIN-meta).
SCA/3DS стартує через провайдера; ваші сервера отримують результат/вердикт.

3. 2 Сервіс «Payments Orchestrator»

Не бачить PAN; оперує токенами.
Реалізує: маршрутизацію (primary/secondary PSP), idempotency keys, retries/backoff, smart-routing (по BIN/регіонах/конверсії).
Тримає конфіг правил і health-пробів PSP (SLI/SLO).
Вміє detokenize-проксі (тільки як «сервіс-човник» всередині довіреного периметра до вальту).

3. 3 Токен-вальт (якщо свій)

HSM-бекенд, FIPS-сумісне шифрування.
Ізоляція мережі/сегментація, ААА (MFA/least privilege), журнали аудиту, ключова ротація.
API: tokenize (), detokenize (), rotate (), purge () з тонкими ACL/Scopes.
Підтримка format-preserving encryption (FPE) - опціонально, якщо потрібно візуально «масковане» зберігання.

3. 4 Подієва шина і DWH

У подіях - тільки токени і безпечні метадані.
Лінк авторизації ↔ капчура/рефанда через payment_id (не PAN).
У сховищах BI заборонений PAN і CVV.

4) Потоки (текстові діаграми)

4. 1 Первинний COF (збереження карти)

1. User → Hosted Fields (PSP/TSP iframe) вводить PAN.
2. PSP/TSP → повертає token (+ device binding/cryptogram).
3. Front → Backend (Orchestrator): `{token, order_id, context}`.
4. Orchestrator → PSP: 'auth'по токену (можливий 3DS challenge).
5. PSP → Orchestrator: `auth_result`.
6. Orchestrator → Wallet Service: зберігаємо'token'і мета.

PAN ніде у ваших сервісах не з'являється.

4. 2 Повторне списання/підписка

1. Scheduler/Business → Orchestrator: `charge(token, amount)`.
2. Orchestrator → PSP: `capture/auth`.
3. PSP → Orchestrator: результат + arn/rrn.
4. Orchestrator → Ledger/Reconciliation.

4. 3 Failover и smart-routing

Правило: `IF PSP_A. degraded OR BIN in {X} THEN PSP_B ELSE PSP_A`.
Для network-токенів переконайтеся, що обидва PSP підтримують їх прийняття; інакше - тримайте двійкову прив'язку (network + vault).

5) 3DS і SCA в PAN-safe контурі

3DS2 запускається з хостед-SDK; ваші сервери приймають аліаси статусів (frictionless, challenge, failure).
Зв'язуйте 3DS-вердикт з payment_id; зберігайте транзакційні артефакти (ARes, CRes refs) без PAN.
Для рекарантингів (MIT/recurring/unscheduled COF) - коректно маркуйте прапори транзакцій (тип MIT, початковий CIT reference).

6) Безпека, комплаєнс і політика даних

PCI DSS скоуп: фронт без PAN, бекенд без PAN ⇒ оцінка спрощується (SAQ-А/варіації). Якщо є власний вальт/детокенізація - скоуп вище (SAQ-D).
HSM/ключова ротація: періодичні ротації майстер-ключів, dual control, split knowledge.
GDPR/DSR: видалення токена і пов'язаних метаданих за запитом користувача (при цьому PAN залишається невідомим).
Логи/трейси: найсуворіші маскування, детектори витоків (DLP), санітарізація при серіалізації помилок.
Сегментація: вальт у виділеному сегменті; доступ - тільки по mTLS і короткоживучим токенам (STS).

7) Інтеграція з PSP/акавайерами

7. 1 Мінімальний набір можливостей PSP для PAN-safe

Hosted fields/SDK з токенізацією.
Прийняття network tokens (по можливості) і/або експорт vault-токенів.
Card updater, COF-маркування, MIT-прапори.
3DS server + оркестрація SCA.
Webhooks з idempotent-доставкою і сигнатурою.

7. 2 Multi-PSP архітектура

Абстракція «конектора» в Orchestrator (уніфікація полів).
Таблиця «ваг/пріоритетів» + health-пінги.
Таблиця BIN-політик (схема, регіон, продукт, ризик-скоринг).
Резервний PSP для критичних маршрутів (fallback SLA).

8) Оновлення карт і довговічність токенів

Network tokens: автооновлення при перевипуску (краще для LTV).
Vault tokens: використовуйте card updater (через PSP/3rd-party).
Стеження за термінами закінчення, нотифікації користувачеві, м'які ретраї (exponential backoff + jitter).
Прив'язка COF до account-id, а не до користувача по PII, для простого перевипуску.

9) Ретраї, помилки і idempotency

Idempotency-key = хеш(merchant_id, account_id, order_id, attempt_n).
Категоризація помилок: hard (decline code постійний) vs soft (timeout, network, risk pending).
Backoff: 1m → 10m → 1h → 24h з верхньою межею і відміною при hard-decline.
Дедуплікація webhooks: зберігайте event_id і статусні переходи (state machine).

10) Reconciliation і фінанси

Ведіть платіжний Ledger без PAN: 'payment _ id','psp _ txn _ id','arn/rrn','token _ id', статуси.
Щоденний rec file ingestion від PSP/акавайера; звірення сум, комісій, чарджбеків.
Окремі пайплайни для refunds/voids/chargebacks; узгодження з білінгом/бухгалтерією.
KPI по PSP/країнам/BIN-табам.

11) Метрики та цілі (KPI)

Безпека/комплаєнс

% сервісів, які ніколи не бачать PAN (мета: 100%).
PCI scope level (нижче - краще).

Бізнес

Approval Rate (AR) за токен-типами (network vs vault).
COF retention rate, частка автооновлених методів.
D + 0/D + 1 реконсиляційні розбіжності (мета: → 0).

Техніка

Час токенізації p95.
Частка транзакцій через fallback PSP.
Кількість детокенізацій (мета: мінімізувати, тільки всередині вальта).

12) Часті анти-патерни

Логування PAN/CVV у винятках.
Клієнтські форми без hosted-полів.
Відправка PAN через вашу API-шину «тимчасово».
Змішування токенів різних доменів без явної політики (risk).
Відсутність карти маршрутизації (всі платежі «в один PSP»).
Зберігання 3DS-артефактів з надлишковими PII.

13) План впровадження (за кроками)

1. Фронтенд: інтегрувати hosted fields/SDK, прибрати власні платіжні форми.
2. PSP/TSP вибір: підтверджуємо підтримку network tokens, 3DS2, webhooks, card updater.
3. Orchestrator: шар абстракції над PSP, правила маршрутизації, idempotency, retries.
4. Вальт (опціонально): вибираємо managed-vault або будуємо свій (HSM, ACL, ротації).
5. Дані/події: заборона PAN в шину і DWH; впровадити DLP-гейт в CI/CD.
6. Комплаєнс: оновити PCI-область, процедури, журнали аудиту, тести на маскування.
7. Спостережуваність: метрики AR/LSR/latency по PSP, алерти деградації, дешборди.
8. Економіка: A/B-тест network vs vault токенів по AR/фроду/вартості, оптимізація флоу.

14) Чек-лист PAN-safe

• Введення PAN тільки в iframe/hosted fields.
• Бекенд ніколи не приймає PAN/CVV.
• Токени шифруються в зберіганні, ключі в HSM, ротація включена.
• 3DS2 і SCA коректно маркуються (CIT/MIT/COF).
• Multi-PSP маршрутизація і failover протестовані.
• Включений card updater (network/PSP).
• Логи/трейси/дампи - без PAN (маски/санітайзери).
• Reconciliation і chargeback-пайплайни без PAN.
• Політики GDPR/видалення токенів реалізовані.
• Метрики та алерти покривають якість токен-флоу.

15) Глосарій коротко

PAN: номер картки.
Token (vault/network): безпечний замінник PAN.
TSP: Token Service Provider (мережевий токен-сервіс).
COF/MIT/CIT: зберігання карти/ініціатива мерчанта/ініціатива клієнта.
HSM: апаратний модуль безпеки.
SCA/3DS2: сильна автентифікація/протокол аутентифікації за картками.

16) Резюме

Токенізація - базова техніка для зниження PCI-ризиків, зростання approval rate і гнучкої маршрутизації платежів в iGaming. Комбінуйте network tokens (за рахунок конверсії і автооновлень) з vault tokens (за рахунок контролю і незалежності), будуйте PAN-safe флоу з hosted-полями, оркестратором, управлінням ключами і прозорою спостережуваністю від авторизації до reconciliation. Це дасть безпеку, масштаб і передбачувану монетизацію.