Токенизация карт и 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-A/вариации). Если есть собственный вальт/детокенизация — скоуп выше (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. Это даст безопасность, масштаб и предсказуемую монетизацию.