Kartalarni tokenlash va PAN-safe oqimlari

1) Tokenizatsiya nima uchun va PAN-safe nima

• PCI DSS-kupini (va nazorat qiymatini) minimallashtirish,
• sizib chiqish xavfini kamaytirish,
• avtorizatsiyani yaxshilash (avtomatik almashtirish, COF, one-click),
• multi-PSP yo’naltirishni va qayta hisobdan chiqarishni soddalashtirish.

PAN-safe - bu foydalanuvchi va server stsenariysi boʻlib, u yerda PAN faqat izolyatsiya qilingan ishonchli perimetr (valt/TSP/PSP iframe) ichida paydo boʻladi va hech qachon sizning bekend/log/shina hodisalaringiz orqali ochiq koʻrinishda oʻtmaydi.

2) Tokenlar turlari va hayot sikli

2. 1 Vault-tokenlar (shaxsiy)

Sizning token-valtingiz yoki tashqi seyf-provayderingiz tomonidan yaratilgan.
PAN bilan bogʻlangan, ammo qaytariladigan muvofiqlik faqat valtda (HSM) saqlanadi.
Har qanday PSP/akavayerga yoʻnaltirish uchun ishlatiladi (moslashuvchanlik).
Plyus: sxemalardan mustaqillik; Minus: shaxsiy compliant-valt talab qilinadi.

2. 2 Network-tokenlar (sxemali; Visa/Mastercard/AmEx TSP)

TSP orqali tarmoqlar orqali ishlab chiqariladi; koʻpincha device-/merchant-binding va kriptogramma bilan birga keladi.
Avtorizatsiyani yaxshilaydi: yuqori approval rate, kam frod-fols-pozitivlar.
Xaritani qayta chiqarishda avtomatik yangilanishni qoʻllab-quvvatlaydi.
Minus: PSP/protsessorni qo’llab-quvvatlash va bozorlarni qoplash.

2. 3 Bir martalik (single-use) va ko’p martalik (COF)

Single-use: SCAni bir martalik hisobdan chiqarish/boshlash uchun.
COF (Card-on-File): obuna, retray, takroriy toʻlovlar uchun.

2. 4 Hayot sikli

1. Boshlang’ich: front to’lov maydonlarini domeningizdan emas (xosted/iframe TSP/PSP) oladi.
2. Tokenizatsiya: PAN → token (vault yoki network), kriptogramma chiqarish (agar talab qilinsa).
3. Saqlash: token va meta-ma’lumotlar (BIN-ma’lumotlar, sxema, muddat, domen-binding).
4. Foydalanish: avtorizatsiya/kapchur/retrai token bo’yicha.
5. Rotatsiya/yangilash: avto-yangilanishlar (network), card updater (vault/PSP).
6. Qaytarish/olib tashlash: foydalanuvchining soʻrovi (GDPR/DSR) yoki retensiya siyosati boʻyicha.

3) Arxitektura patternlari PAN-safe

3. 1 Mijoz qatlami (web/mobile)

PSP/TSP dan Hosted fields/iFrame SDK: PAN DOMdan tashqarida kiritiladi.
Sizning frontendingiz faqat token + tanqidiy boʻlmagan atributlarni oladi (oxirgi 4 raqam, BIN-meta).
SCA/3DS provayder orqali boshlanadi; serverlaringiz natija/hukm oladi.

3. 2 «Payments Orchestrator» xizmati

PAN koʻrmaydi; tokenlar bilan operatsiya qiladi.
Quyidagilarni amalga oshiradi: yo’naltirish (primary/secondary PSP), idempotency keys, retries/backoff, smart-routing (BIN/mintaqalar/konversiyalar bo’yicha).
PSP (SLI/SLO) qoidalari va health-namunalarini saqlaydi.
Detokenize-proxy (faqat ishonchli perimetr ichida valtga «servis-chelok» sifatida) biladi.

3. 3 Token-valt (agar o’zingizniki bo’lsa)

HSM-orqa, FIPS-mos shifrlash.
Izolyatsiya tarmog’i/segmentatsiya, AAA (MFA/least privilege), audit jurnallari, asosiy rotatsiya.
API: tokenize (), detokenize (), rotate (), purge () va ingichka ACL/Scopes.
Qo’llab-quvvatlash format-preserving encryption (FPE) - ko’zga tashlanadigan saqlash kerak bo’lsa, ixtiyoriy.

3. 4 Hodisa shinasi va DWH

Voqealarda faqat tokenlar va xavfsiz meta ma’lumotlar mavjud.
payment_id orqali kapchura/refanda avtorizatsiya linki (PAN emas).
BI omborlarida PAN va CVV taqiqlangan.

4) Oqimlar (matnli diagrammalar)

4. 1 Birlamchi COF (xaritani saqlash)

1. User → Hosted Fields (PSP/TSP iframe) PANni kiritadi.
2. PSP/TSP → qaytaradi token (+ device binding/cryptogram).
3. Front → Backend (Orchestrator): `{token, order_id, context}`.
4. Orchestrator → PSP:’auth’tokenida (mumkin 3DS challenge).
5. PSP → Orchestrator: `auth_result`.
6. Orchestrator → Wallet Service:’token’va meta’ni saqlaymiz.

Xizmatlaringizda hech qanday PAN mavjud emas.

4. 2. Qayta hisobdan chiqarish/obuna

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

4. 3 Failover и smart-routing

Qoida: "IF PSP_A. degraded OR BIN in {X} THEN PSP_B ELSE PSP_A`.
Tarmoq tokenlari uchun ikkala PSP ham ularni qabul qilishni qoʻllab-quvvatlashiga ishonch hosil qiling; aks holda - ikkilik bogʻlashni saqlang (network + vault).

5) 3DS va SCA PAN-safe konturda

3DS2 xosted-SDK dan ishga tushiriladi; serverlaringiz (frictionless, challenge, failure) maqom aliyalarini qabul qiladi.
3DS hukmini payment_id bilan bog’lang; tranzaksion artefaktlarni (ARes, CRes refs) PANsiz saqlang.
Rekaranting (MIT/recurring/unscheduled COF) uchun - tranzaksiya bayroqlarini (MIT turi, dastlabki CIT reference) toʻgʻri belgilang.

6) Xavfsizlik, komplayens va ma’lumotlar siyosati

PCI DSS kupi: PANsiz front, PANsiz bekend ⇒ baholash soddalashtiriladi (SAQ-A/variatsiyalar). Agar o’zingizning valt/detokenizatsiyangiz bo’lsa, yuqoriroq (SAQ-D).
HSM/asosiy rotatsiya: master-kalitlarning davriy rotatsiyasi, dual control, split knowledge.
GDPR/DSR: foydalanuvchi soʻrovi boʻyicha token va bogʻliq meta maʼlumotlar oʻchiriladi (bunda PAN nomaʼlum boʻlib qoladi).
Loglar/treyslar: qat’iy kamuflyajlar, oqish detektorlari (DLP), xatolarni seriyallashtirishda sanitarizatsiya.
Segmentatsiya: ajratilgan segmentdagi valt; kirish - faqat mTLS va qisqa yashaydigan tokenlar (STS) bo’yicha.

7) PSP/akavayerlar bilan integratsiya

7. 1 PAN-safe uchun minimal PSP imkoniyatlar toʻplami

Hosted fields/SDK tokenlash bilan.
Tarmoq tokenlarini qabul qilish (iloji boricha) va/yoki vault tokenlarini eksport qilish.
Card updater, COF markirovkalari, MIT bayroqlari.
3DS server + SCA orkestri.
Webhooks idempotent-yetkazib berish va signatura bilan.

7. 2 Multi-PSP arxitektura

Orchestratordagi «konnektor» ning abstraksiyasi (maydonlarni birxillashtirish).
«Tarozilar/ustuvorliklar» jadvali + health-pinglar.
BIN-siyosat jadvali (sxema, hudud, mahsulot, tavakkalchilik-skoring).
Kritik yoʻnalishlar uchun zaxira PSP (fallback SLA).

8) Kartalarni yangilash va tokenlarning chidamliligi

Network tokens: Qayta chiqarishda avtomatik yangilanish (LTV uchun yaxshiroq).
Vault tokens: card updaterdan foydalaning (PSP/3rd-party orqali).
Muddat tugashini kuzatish, foydalanuvchiga notifikatsiya qilish, yumshoq retralar (exponential backoff + jitter).
COF’ni PII foydalanuvchisiga emas, balki account-id’ga bogʻlash.

9) Retray, xato va idempotency

Idempotency-key = хеш(merchant_id, account_id, order_id, attempt_n).
Xatolarni toifalash: hard (decline code doimiy) vs soft (timeout, network, risk pending).
Backoff: 1m → 10m → 1h → 24h yuqori chegarasi va hard-decline bekor qilish.
Webhooks: event_id va maqom oʻtishlarini saqlang (state machine).

10) Reconciliation va moliya

Ledger to’lovini PAN’siz amalga oshiring:’payment _ id’,’psp _ txn _ id’,’arn/rrn’,’token _ id’, maqomlar.
PSP/akavayerdan kundalik rec file ingestion; summalar, komissiyalar, chorjbeklarni solishtirish.
refunds/voids/chargebacks uchun alohida payplaynlar; billing/buxgalteriya bilan kelishish.
PSP/mamlakatlar/BIN-tablar bo’yicha KPI.

11) Metrika va maqsadlar (KPI)

Xavfsizlik/komplayens

Hech qachon PAN’ni koʻrmaydigan xizmatlar% (maqsad: 100%).
PCI scope level (pastda yaxshiroq).

Biznes

Approval Rate (AR) token turlari bo’yicha (network vs vault).
COF retention rate, avtomatik yangilangan usullar ulushi.
D + 0/D + 1 rekonsilatsion farqlar (maqsad: → 0).

Texnika

Tokenlash vaqti p95.
PSP fallback orqali tranzaksiyalar ulushi.
Detokenizatsiyalar soni (maqsad: minimallashtirish, faqat valtning ichida).

12) Tez-tez anti-patternlar

Istisnolarda PAN/CVV logini.
Hosted-maydonlarsiz mijoz shakllari.
PAN’ni «vaqtinchalik» API shinasi orqali yuborish.
Turli domenlarning tokenlarini aniq siyosatsiz aralashtirish (risk).
Yo’nalish kartasining yo’qligi (barcha to’lovlar «bitta PSPga»).
Ortiqcha PIIli 3DS-artefaktlarni saqlash.

13) Joriy etish rejasi (qadamlar bo’yicha)

1. Frontend: hosted fields/SDKni integratsiyalash, oʻz toʻlov shakllarini olib tashlash.
2. PSP/TSP tanlovi: network tokens, 3DS2, webhooks, card updater.
3. Orchestrator: PSP ustidagi abstraksiya qatlami, marshrutlash qoidalari, idempotency, retries.
4. Valt (ixtiyoriy): biz managed-vault ni tanlaymiz yoki o’zimiznikini quramiz (HSM, ACL, rotatsiyalar).
5. Maʼlumotlar/hodisalar: shinaga PAN va DWH taqiqlash; CI/CD da DLP-geytni joriy etish.
6. Komplayens: PCI sohasini, tartib-taomillarni, audit jurnallarini, niqoblash testlarini yangilash.
7. Kuzatilganlik: PSP bo’yicha AR/LSR/latency metrikalari, degradatsiya alertlari, deshbordlar.
8. Iqtisodiyot: A/B-test network vs vault tokenlar AR/frod/qiymat bo’yicha, flouni optimallashtirish.

14) PAN-safe chek-varag’i

• Faqat iframe/hosted fields’ga PANni kiritish.
• Bekend hech qachon PAN/CVV qabul qilmaydi.
• Tokenlar saqlashda shifrlanadi, HSM kalitlari, rotatsiya yoqilgan.
• 3DS2 va SCA to’g’ri belgilanadi (CIT/MIT/COF).
• Multi-PSP marshrutlash va failover sinovdan o’tkazildi.
• card updater (network/PSP) yoqilgan.
• Logi/treys/damplar - PANsiz (niqob/sanitizatorlar).
• Reconciliation va chargeback-payplaynlar PANsiz.
• GDPR/tokenlarni olib tashlash siyosati amalga oshirildi.
• Metriklar va alertlar token-flou sifatini qoplaydi.

15) Lugʻat qisqacha

PAN: karta raqami.
Token (vault/network): xavfsiz PAN oʻrnini bosuvchi.
TSP: Token Service Provider (tarmoq token xizmati).
COF/MIT/CIT: xaritani saqlash/merchant tashabbusi/mijoz tashabbusi.
HSM: apparat xavfsizlik moduli.
SCA/3DS2: kartalar bo’yicha kuchli autentifikatsiya/autentifikatsiya protokoli.

16) Xulosa

Tokenizatsiya - PCI-xavflarni kamaytirish, approval rate o’sishi va iGaming-ga to’lovlarni moslashuvchan yo’naltirish uchun bazaviy texnika. Network tokens (konvertatsiya va avtoulov yangilanishlari hisobiga) va vault tokens (nazorat va mustaqillik hisobiga) ni birlashtiring, hosted maydonlari, orkestrator, kalitlarni boshqarish va avtorizatsiyadan tortib reconciliation gacha shaffof kuzatuv bilan PAN-safe flou quring. Bu xavfsizlik, miqyos va oldindan aytib bo’ladigan monetizatsiya imkonini beradi.