ბარათების ტოქსიკაცია და PAN-safe ნაკადები

1) რატომ არის ტოკენიზაცია და რა არის PAN-safe

• მინიმუმამდე დაიყვანეთ PCI DSS შეკრება (და კონტროლის ღირებულება),
• შეამცირეთ გაჟონვის რისკი
• ავტორიზაციის გაუმჯობესება (ავტო ჩანაცვლება, COF, ერთი კლიკი),
• გამარტივდეს multi-PSP მარშრუტიზაცია და ხელახალი ჩამოწერა.

PAN-safe Stream არის ასეთი მომხმარებლის და სერვერის სცენარი, სადაც PAN ჩნდება მხოლოდ იზოლირებული სანდო პერიმეტრის შიგნით (walt/TSP/PSP iframe) და არასოდეს გადის თქვენს ბეკენდში/ლოგინში/მოვლენების საბურავებში ღია ფორმით.

2) ნიშნები და სასიცოცხლო ციკლი

2. 1 Vault ნიშნები (პირადი)

წარმოიქმნება თქვენი ნიშანი-ვალტი ან მესამე მხარის სეიფ-პროვაიდერი.
მიბმული PAN- სთან, მაგრამ შექცევადი კორესპონდენცია ინახება მხოლოდ ვალტაში (HSM).
გამოიყენება ნებისმიერი PSP/აკავერის მარშრუტიზაციისთვის (მოქნილობა).
პლუს: დამოუკიდებლობა სქემებისგან; მინუს: საჭიროა საკუთარი კომპლექსის ვალტი.

2. 2 ქსელის ნიშნები (სქემა; Visa/Mastercard/AmEx TSP)

ხელმისაწვდომია ქსელების საშუალებით TSP; ხშირად თან ახლავს device-/merchant-binding და cryptogram.
ისინი აუმჯობესებენ ავტორიზაციას: უფრო მაღალია, ვიდრე approval rate, ნაკლები frode falls პოზიტიური.
ისინი მხარს უჭერენ მანქანის განახლებას ბარათის ხელახლა მიღებისას.
მინუსი: PSP/პროცესორის მხარდაჭერა და ბაზრების დაფარვა.

2. 3 ერთჯერადი (ერთჯერადი მანქანა) და მეორადი (COF)

Single-use: ერთჯერადი ჩამოწერისთვის/SCA- ს წამოწყებისთვის.
COF (Card-on-File): ხელმოწერების, განმეორებითი გადახდებისთვის.

2. 4 ცხოვრების ციკლი

1. ინიციალიზაცია: ფრონტი იღებს გადახდის ველს არა თქვენი დომენიდან (მასპინძელი ველები/iframe TSP/PSP).
2. ტოკენიზაცია: PAN - ნიშანი (vault ან ქსელი), კრიპტოგრამის გამოშვება (საჭიროების შემთხვევაში).
3. შენახვა: ნიშნები და მეტამონაცემები (BIN მონაცემები, სქემა, ვადა, დომენი).
4. გამოყენება: საავტორო უფლებები/კაპჩური/რეტრაები.
5. როტაცია/განახლება: ავტომობილების განახლება (ქსელი), ბარათის განახლება (vault/PSP).
6. მიმოხილვა/მოცილება: მომხმარებლის მოთხოვნით (GDPR/DSR) ან რეტენციის პოლიტიკა.

3) არქიტექტურული ნიმუშები PAN-safe

3. 1 კლიენტის ფენა (ვებ/მობილური)

Hosted fields/iFrame SDK PSP/TSP: PAN შემოღებულია თქვენი DOM- ის გარეთ.
თქვენი წინა მხარე იღებს მხოლოდ ნიშანს + არაკრიტიკულ ატრიბუტებს (ბოლო 4 ციფრი, BIN-meta).
SCA/3DS იწყება პროვაიდერის საშუალებით; თქვენი სერვერები იღებენ შედეგს/განაჩენს.

3. 2 სერვისი „Payments Orchestrator“

ვერ ხედავს PAN; მოქმედებს ტოკენებით.
ის ახორციელებს: მარშრუტიზაციას (პირველადი/მეორე PSP), პირადობის მოწმობა, რეპრესიები/ბაჩოფი, ჭკვიანი როტინგი (BIN/რეგიონების/კონვერტაციის მიხედვით).
ინახავს წესების კონფისკაციას და ჯანმრთელობის ტესტებს PSP (SLI/SLO).
მას შეუძლია detokenize მარიონეტული (მხოლოდ როგორც „სერვისის დაფა“ სანდო პერიმეტრის შიგნით ვალტისკენ).

3. 3 ტოკენის ვალტი (თუ საკუთარი)

HSM ბაზა, FIPS თავსებადი დაშიფვრა.
ქსელის იზოლაცია/სეგმენტი, AAA (MFA/ძირითადი პრივილეგია), აუდიტის ჟურნალები, ძირითადი როტაცია.
API: tokenize (), detokenize (), rotate (), purge () თხელი ACL/Scopes.
Format-preserving encryption (FPE) მხარდაჭერა სურვილისამებრ არის, თუ ვიზუალურად „შენიღბული“ შენახვა გჭირდებათ.

3. 4 მოვლენის საბურავი და DWH

მოვლენებში - მხოლოდ ნიშნები და უსაფრთხო მეტამონაცემები.
ავტორიზაციის ლინკია capchure/refanda საშუალებით payment _ id (არა PAN).
PAN და CVV აკრძალულია BI საცავში.

4) ნაკადები (ტექსტური დიაგრამები)

4. 1 პირველადი COF (ბარათის შენახვა)

1. User-Hosted Fields (PSP/TSP iframe) შემოაქვს PAN.
2. PSP/TSP ბრუნდება token (+ მოწყობილობა binding/cryptogram).
3. Front → Backend (Orchestrator): `{token, order_id, context}`.
4. Orchestrator - PSP: 'auth' ნიშანი (შესაძლებელია 3DS გამოწვევა).
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`.
ქსელის ნიშნებისთვის დარწმუნდით, რომ ორივე PSP მხარს უჭერს მათ მიღებას; წინააღმდეგ შემთხვევაში - შეინარჩუნეთ ორობითი ბმული (ქსელი + vault).

5) 3DS და SCA PAN-safe წრეში

3DS2 ამოქმედებულია მასპინძელი SDK- დან; თქვენი სერვერები იღებენ სტატუსის ალიასებს (frictionless, challenge, failure).
დააკავშირეთ 3DS განაჩენი payment _ id; შეინახეთ გარიგების ნივთები (ARes, CRes refs) PAN- ის გარეშე.
რეკონსტრუქციისთვის (MIT/ჩანაწერების/უნიფორმირებული COF) - სწორად შეაფასეთ გარიგების დროშები (MIT ტიპი, ორიგინალური CIT რეაგირება).

6) უსაფრთხოება, შესაბამისობა და მონაცემთა პოლიტიკა

PCI DSS შეკრება: წინა PAN- ის გარეშე, PAN- ის გარეშე ბეკენდი გამარტივებულია (SAQ-A/ვარიაციები). თუ არსებობს საკუთარი ვალტი/დეტოკენიზაცია - უფრო მაღალი სიჩქარე (SAQ-D).
HSM/საკვანძო როტაცია: მასტერკლასების პერიოდული როტაცია, ორმაგი კონტროლი, split knowledge.
GDPR/DSR: ნიშნის და დაკავშირებული მეტამონაცემების მოცილება მომხმარებლის მოთხოვნით (ხოლო PAN უცნობია).
Logs/traces: მკაცრი შენიღბვა, გაჟონვის დეტექტორები (DLP), სანიტარიზაცია შეცდომების სერიალიზაციის დროს.
სეგმენტი: ვალტი იზოლირებულ სეგმენტში; წვდომა - მხოლოდ mTLS და მოკლე სიცოცხლე (STS).

7) ინტეგრაცია PSP/acavayers- ით

7. 1 PSP შესაძლებლობების მინიმალური ნაკრები PAN-safe

Hosted fields/SDK ტოქსიკაციით.
ქსელის ტოკენსის მიღება (თუ ეს შესაძლებელია) ან/და vault ტოქსინების ექსპორტი.
Card განახლება, COF მარკირება, MIT დროშები.
3DS სერვერი + SCA ორკესტრი.
Webhooks idempotent მიწოდებით და ხელმოწერით.

7. 2 Multi-PSP არქიტექტურა

„კონექტორის“ აბსტრაქცია Orchestrator- ში (ველების გაერთიანება).
ცხრილი „წონა/პრიორიტეტები“ + ჯანმრთელობის პინგი.
BIN პოლიტიკის ცხრილი (სქემა, რეგიონი, პროდუქტი, რისკის ესკიზი).
სარეზერვო PSP კრიტიკული მარშრუტებისთვის (fallback SLA).

8) ბარათების განახლება და ტოქსინების გამძლეობა

ქსელის ტოკენსი: ხელახლა განახლება (უკეთესია LTV- სთვის).
Vault tokens: გამოიყენეთ ბარათის განახლება (PSP/3rd-party- ის საშუალებით).
გასვლის ვადების თვალყურის დევნება, მომხმარებლისთვის ნოტიფიკაცია, რბილი რეაგირება (ექსპონენტალური ბუკოფი + jitter).
COF დაკავშირება account-id- ზე და არა მომხმარებელთან PII- სთვის, მარტივი ხელახლა გამოშვებისთვის.

9) Retrai, შეცდომები და idempotence

Idempotency-key = хеш(merchant_id, account_id, order_id, attempt_n).
შეცდომების კატეგორიზაცია: hard (decline code მუდმივი) vs soft (timeout, ქსელი, risk pending).
Backoff: 1m-10m-1h-24h ზედა საზღვრით და გაუქმებით hard-decline.
Webhooks deduplication: შეინახეთ ღონისძიება _ id და სტატუსის გადასვლები (სახელმწიფო მანქანა).

10) რეკონსტრუქცია და ფინანსები

ჩაატარეთ გადახდის Ledger PAN- ის გარეშე: 'payment _ id', 'psp _ txn _ id', 'arn/rrn', 'token _ id', სტატუსები.
ყოველდღიური rec ingestion PSP/aquavayer- დან; თანხების, კომისიების, ჩარდბეკების შემცირება.
ცალკეული piplines refunds/voids/chargebacks; კოორდინაცია ბილინგთან/ბუღალტრულ აღრიცხვასთან.
KPI PSP/ქვეყნებში/BIN ტაბმები.

11) მეტრიკა და მიზნები (KPI)

უსაფრთხოება/შესაბამისობა

სერვისების%, რომლებიც არასოდეს ხედავენ PAN- ს (მიზანი: 100%).
PCI scope level (ქვემოთ - უკეთესი).

ბიზნესი

Approval Rate (AR) ნიშნის ტიპების მიხედვით (ქსელი vs vault).
COF retention, ავტომობილების განახლებული მეთოდების წილი.
D + 0/D + 1 სარეკონსტრუქციო შეუსაბამობები (მიზანი: 0).

ტექნიკა

ტოკენიზაციის დრო p 95.
გარიგების წილი fallback PSP- ის საშუალებით.
დეტოქსიკაციების რაოდენობა (მიზანი: მინიმუმამდე შემცირება, მხოლოდ ვალტის შიგნით).

12) ხშირი ანტი-ნიმუშები

გამონაკლისი PAN/CVV.
კლიენტის ფორმები მასპინძელი ველების გარეშე.
PAN- ის გაგზავნა თქვენი API ავტობუსის საშუალებით „დროებით“.
სხვადასხვა დომენის ნიშნების შერევა აშკარა პოლიტიკის გარეშე (risk).
მარშრუტიზაციის ბარათის არარსებობა (ყველა გადახდა „ერთ PSP- ში“).
3DS არტეფაქტების შენახვა ჭარბი PII.

13) განხორციელების გეგმა (ნაბიჯებით)

1. Frontend: ინტეგრირება hosted fields/SDK, ამოიღეთ საკუთარი გადახდის ფორმები.
2. PSP/TSP არჩევანი: ჩვენ ვადასტურებთ ქსელის ტოკენსის მხარდაჭერას, 3DS2, webhooks, ბარათის განახლებას.
3. Orchestrator: აბსტრაქციის ფენა PSP- ზე, მარშრუტიზაციის წესები, idempotency, retries.
4. ვალტი (სურვილისამებრ): ჩვენ ვირჩევთ მენეჯმენტ-რეჟიმს ან ვაშენებთ ჩვენს (HSM, ACL, როტაცია).
5. მონაცემები/მოვლენები: PAN აკრძალვა საბურავში და DWH; დანერგეთ DLP კარიბჭე CI/CD- ში.
6. შესაბამისობა: განაახლეთ PCI რეგიონი, პროცედურები, აუდიტის ჟურნალები, ნიღბების ტესტები.
7. დაკვირვება: AR/LSR/latence PSP, დეგრადაციის ალერტები, deschbords.
8. ეკონომიკა: A/B ქსელის ტესტი AR/Frode/ღირებულებით, flow ოპტიმიზაცია.

14) PAN-safe ჩეკის სია

• PAN შეყვანა მხოლოდ iframe/hosted fields- ში.
• ბეკენდი არასოდეს იღებს PAN/CVV.
• ნიშნები დაშიფრულია შენახვაში, გასაღებები HSM- ში, როტაცია შედის.
• 3DS2 და SCA სწორად აღინიშნება (CIT/MIT/COF).
• Multi-PSP მარშრუტიზაცია და failover ტესტირება მოხდა.
• შედის ბარათის განახლება (ქსელი/PSP).
• Logs/trais/damps - PAN- ის გარეშე (ნიღბები/ექთნები).
• რეკონსტრუქცია და chargeback paplines PAN- ის გარეშე.
• პოლიტიკოსები GDPR/ტოქსინების ამოღება ხორციელდება.
• მეტრიკები და ალერტები ფარავს ნიშნის ნაკადის ხარისხს.

15) მოკლედ

PAN: ბარათის ნომერი.
ტოკენი (vault/network): PAN უსაფრთხო შემცვლელი.
TSP: Token Service Provider (ქსელის ნიშნის სერვისი).
COF/MIT/CIT: ბარათის შენახვა/მერჩანტის ინიციატივა/კლიენტის ინიციატივა.
HSM: აპარატურის უსაფრთხოების მოდული.
SCA/3DS2: ძლიერი ავთენტიფიკაცია/ბარათების ავთენტიფიკაციის პროტოკოლი.

16) რეზიუმე

ტოკენიზაცია არის ძირითადი ტექნიკა PCI რისკების შესამცირებლად, approval rate- ის ზრდისა და მოქნილი გადახდის მარშრუტით iGaming- ში. დააკავშირეთ ქსელის ტოკენსი (კონვერტაციისა და ავტო განახლებების გამო) vault tokens- დან (კონტროლისა და დამოუკიდებლობის გამო), ააშენეთ PAN-safe flow მასპინძელი ველებით, ორკესტრით, კლავიშების მართვით და გამჭვირვალე დაკვირვებით ავტორიზაციიდან ჩანაწერამდე. ეს მისცემს უსაფრთხოებას, მასშტაბს და პროგნოზირებულ მონეტიზაციას.