3-D Secure 2. 0 და SCA

1) რატომ არის iGaming ოპერატორი 3DS2 და რა არის SCA

3-D Secure 2. x (EMV 3DS) - ელექტრონული კომერციის ბარათის მფლობელის ავტორიზაციის პროტოკოლი.
SCA (Strong Customer Authentication) არის მარეგულირებელი მოთხოვნა (PSD2/UK), რომელიც ვალდებულია ჩაატაროს ორმხრივი შემოწმება არაერთ სცენარში.

• Liability shift: წარმატებული ავთენტიფიკაციით, თაღლითობის რისკი გადადის გამცემზე.
• Vs 3DS1 კონვერტაციის ზემოთ: 100 + მონაცემთა ელემენტის შეგროვება საშუალებას იძლევა frictionless გარეშე გამოწვევა.
• მშობლიური სკრიპტები: SDK iOS/Android, in-app, decoupled და out-of-band დადასტურებისთვის.

2) როლები და კომპონენტები (EMV 3DS)

3DS სერვერი (თქვენ გაქვთ ან PSP): აყალიბებს მოთხოვნებს სქემაში, აერთიანებს მოწყობილობის მონაცემებს, აკონტროლებს ვერსიებს 2. 1/2. 2/2. 3.
DirecterServer (DS): სქემების როუტერი (Visa/Mastercard/AmEx და სხვ.).
Access Control Server (ACS): ემიტენტის სერვერი; იღებს გადაწყვეტილებას: frictionless ან challenge.
SDK/Method: მოწყობილობის სიგნალების შეგროვება (fingerprinting), ვებ-SDK/iframe და მობილური-SDK.

3) ტიპიური UX ნაკადები

3. 1 Frictionless (გამოწვევის გარეშე)

1. Merchant/PSP: DS: AReq 3DS მონაცემებით (მოწყობილობა, ისტორია, რისკის სიგნალები).
2. DS/ACS - ARes (frictionless): ავთენტიფიკაცია დასრულებულია მომხმარებლის მონაწილეობის გარეშე.
3. შემდეგი არის საავტორო უფლებები (Auth).

როდესაც ეს ხდება: დაბალი რისკი, whitelist (Trusted Beneficiary), LVP, მაღალი ხარისხის მონაცემები.

3. 2 გამოწვევა (გამოწვევით)

1. ARes მოითხოვს CReq/CRes (OTP, საბანკო დადასტურება, ბიომეტრია).
2. წარმატების შემდეგ - საავტორო უფლებები დაცულია.

3. 3 Decoupled / Out-of-Band

დადასტურება ბანკის განაცხადში რედაქციის გარეშე. სასარგებლოა მობილური სცენარებში.

3. 4 3RI (3DS Requestor Initiated)

იგი გამოიყენება MIT- ისთვის (ინიცირებული გარიგებები) - გამოწერები, რეტრატორები. თითოეულ გამეორებაზე არ არსებობს SCA, მაგრამ საჭიროა სწორი ბმული initial CIT- ზე.

4) SCA: სად არის სავალდებულო და სად მოქმედებს

სავალდებულოა: ელექტრონული კომერციის გარიგების უმეტესობა EEA/UK- ში, თუ გამცემი და შეძენის SCA ზონაში.
ზონის გარეთ/Out-of-scope: MOTO (ფოსტა/ტელეფონი), ზოგიერთი კორპორატიული არხი, ინტერზონის მარშრუტები (TRA ემიტენტის გამოყენება შესაძლებელია).

4. 1 გამონაკლისები

TRA (Transaction Risk Analysis): პროვაიდერის/ბანკის დაბალი რისკი (დადასტურებულია ფროიდის მეტრიკებით).
LVP (Low-Value Payments): მცირე თანხები, ბარიერებით და ემიტენტის მრიცხველებით.
Whitelist: მიმღები ემიტენტის კლიენტის თეთრ სიაში.
Secure Corporate/Merchant Initiated (MIT): შემდგომი ჩამოწერები SCA- ს გარეთ, თუ არსებობს ინიტარული CIT SCA- სთან და სწორი ბმულები.

5) გარიგების მარკირება და დროშები iGaming- ისთვის

CIT (Customer Initiated Transaction): პირველადი ჩამოწერა, ჩვეულებრივ, მოითხოვს SCA- ს (ან გამოცდილებას).
MIT Recurring/Unscheduled COF: შემდგომი ჩამოწერები; SCA არ საჭიროებს პირვანდელ CIT- სთან დაკავშირებას (ინტერკულტურული ბმულები/იდენტიფიკატორები).
PSP/სქემის მოთხოვნების სწორი ინდიკატორები კრიტიკულია liability shift- ისთვის და გამეორებებზე SCA გამოტოვებისთვის.

6) მონაცემები, რომლებიც გავლენას ახდენს ACS- ის გადაწყვეტილებაზე

• Device/Browser: user-agent, accept headers, screen, timezone, language.
• ანგარიში მონაცემები: ანგარიშის ასაკი, ბოლო პაროლის თარიღი, წარუმატებელი შეყვანების რაოდენობა.
• ტრანსფორმაციის მონაცემები: MSS/კატეგორია, თანხა/ვალუტა, წინა მცდელობები, velocity.
• Shipping/Billing: მისამართების დამთხვევა, მიმღების ისტორია.
• 3DS method completion indicator: მოახერხა თუ არა 3DS Method- ის (fingerprint) დამუშავება.
• რაც უფრო მდიდარია კონტექსტი, მით უფრო მაღალია frictionless- ის შანსი.

7) ინტეგრაციის ნაკადები გადახდის ორკესტრთან

7. 1 თანმიმდევრობა (ვებ/მობილური)

1. Initiate 3DS (3DS Server - DS/ACS) შეგიძლიათ მიიღოთ ARes.
2. თუ challenge- ს შეუძლია შეიმუშაოს CReq/CRes SDK/iframe- ის საშუალებით.
3. Auth (ავტორიზაციის) წარმატება 3DS შედეგის მითითებით (ECI, CAVV/Cryptogram, dsTransID).
4. Webhook PSP არის Ledger/DWH ორკესტრი (PAN- ის გარეშე).

7. 2 Soft-decline და retrai

საავტორო უფლებები SCA- ს გარეშე შეიძლება დაბრუნდეს 'soft-decline (კოდი) "- ით, რომ გაიმეოროს გადახდა SCA- სთან.
ორკესტრს უჭირავს მცდელობის სახელმწიფო მანქანა: no SCA - რბილი-decline - 3DS2 - Auth.

7. 3 Multi-PSP

შეამოწმეთ 3DS ვერსიების მხარდაჭერა (2. 1/2. 2/2. 3), app-SDK, decoupled.
Smart-routing: ACS- ის დეგრადაციის დროს, ზოგიერთი ემიტენტი გამოიყენებს სარეზერვო გზას (თუ პოლიტიკა/სქემები იძლევა საშუალებას).

8) UX ნიმუშები, რომლებიც ზრდის კონვერტაციას

Native/SDK მობილური აპლიკაციებში: ნაკლები რედაქცია, უფრო მაღალი დასრულება.
წინასწარი მონაცემთა კოლექცია (ელ.ფოსტა, მისამართი, ქცევითი სიგნალები) 3DS- მდე.
გამჭვირვალე მოლოდინების ეკრანები და გასაგები ტექსტები (ლოკალიზაცია ენაზე/რეგიონში).
ტაიმაუტები რბილი ანაზღაურებით და გამოწვევის განმეორებით.
Whitelisting prompt: შესთავაზეთ კლიენტს დაამატოთ მერჩანტი სანდო ბანკში (სადაც ხელმისაწვდომია).

9) შეცდომები და უკიდურესი შემთხვევები

Timeout/Unavailable ACS - სწორი კოდები და გამეორება (ან პოლიტიკური გამეორება).
ვერსია downgrade: თუ 2. 2/2. 3 არ არის ხელმისაწვდომი, გამოტოვება თავსებადი ვერსიისთვის.
Partial method: თუ 3DS Method არ დასრულებულა, მაინც გაგზავნეთ AReq - უკეთესია ნაწილობრივი მონაცემები, ვიდრე ნული.
Mixed flows: ერთდროულად 3DS + AVS მისამართის გადამოწმება - სტატუსების სწორად mappite.
Chargeback 3DS- ის შემდეგ: სადავო არტეფაქტებთან (ECI, CAVV, ARes/CRes refs).

10) დოკუმენტები და ნივთები, რომლებიც უნდა იყოს შენახული

3DS გარიგების იდენტიფიკატორები (dsTRANSID, threedSServerTRANSID).
ავთენტიფიკაციის შედეგები (ECI, CAVV/AVV, ARes/CRes სტატუსები).
Logs SDK (PII/PAN- ის გარეშე), timestamps და შეცდომების კოდი.
MIT ბმულები intial CIT ხელმოწერებისთვის/გამეორებისთვის.
სოფ-დეკლინისა და TRA გამონაკლისების დამუშავების პოლიტიკოსები.

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

კონვერტაცია

3DS კომპლექტი (ავთენტიფიკაციის წარმატებით დასრულების წილი).
Frictionless vs challenge- ის წილი (მიზანი არის frictionless).
Abandonment rate 3DS ეკრანებზე.

რისკი

ფროიდის ფრენის შემდეგ (ქვემოთ - უკეთესი).
სოლო-decline- ის წილი და შემდგომი რეაგირების წარმატება 3DS- ით.

ტექნიკა

დრო 3DS p95 (ინიციაცია - შედეგი).
SDK/iframe შეცდომები, ACS ტაიმუტი.

12) 3DS2 + SCA გაშვების ჩეკის სია

• 3DS სერვერი უკავშირდება (ვერსია 2. 1/2. 2/2. 3), ტესტის ბინების დამუშავება.
• ვებ - SDK/მობილური-SDK ინტეგრირებულია (in app + webview სცენარები).
• de vice/browser მონაცემების შეგროვება შედის (3DS Method).
• CIT/MIT/COF მარკირება სწორია; ინახება ბმული ინიცირებული CIT.
• soft-decline ნაკადი SCA- ს განმეორებით ხორციელდება ორკესტრში.
• Exemptions (TRA/LVP/whitelist) არის მორგებული და ლოგიკური მიზეზები/შედეგები.
• მულტფილმი-PSP: 3DS და fallback მარშრუტები შემოწმებულია.
• Дэшборды KPI: frictionless %, challenge success %, abandon, soft-decline.
• მზად არის 3DS არტეფაქტების და დისპუტირებული ფლეიბუკების შენახვის პოლიტიკა.

დაგეგმილია UX მინიშნებების A/B ტესტები (ლოკალიზაცია, ტექსტები, ტაიმაუტები).

13) ურთიერთობა PCI DSS- თან და ტოკენიზაციასთან

3DS2 არ ცვლის PCI DSS: ის ავთენტიფიკაციას ეხება, ხოლო PCI - მონაცემთა დაცვის შესახებ.
PAN-safe- ისთვის: ბარათის შეყვანა hosted fields/iframe; ორკესტრი ხედავს მხოლოდ ნიშნებს და 3DS არტეფაქტებს (ECI/CAVV).
COF/MIT- ისთვის გამოიყენეთ ქსელი tokens ან vault ნიშნები, რათა შემცირდეს frod და გაზარდოს ავტორიზაცია.

14) FAQ მოკლედ

ყოველთვის უნდა გაკეთდეს 3DS? SCA ზონაში - დიახ, თუ არ არსებობს სწორი გაფართოება/გამონაკლისი. ემიტენტმა შეიძლება მოითხოვოს გამოწვევა.
თუ ბანკი გატეხილია? გამოიყენეთ რეტრაევის/ტაიმაუტის პოლიტიკოსები და, თუ ეს შესაძლებელია, სხვა მარშრუტი.
მისცემს 3DS კონვერტაციის ზრდას? სწორად მოაზროვნე 3DS2 მდიდარი მონაცემებით ზრდის frictionless- ის წილს და ამცირებს frode/charjbeki.
რა არის ყველაზე მნიშვნელოვანი წარმატებისთვის? მდიდარი კონტექსტური მონაცემები, სწორი CIT/MIT/COF დროშები, სწრაფი UX და სოფ-დეკლაინის კომპეტენტური დამუშავება.

15) რეზიუმე

IGaming 3DS2 + SCA- სთვის ეს არ არის „სავალდებულო ტკივილი“, არამედ ზრდის ინსტრუმენტი: უფრო მეტი frictionless, ნაკლები frode, პასუხისმგებლობის გადაცემა ემიტენტზე, ხელმოწერების სტაბილური მონეტიზაცია და ხელახალი ჩამოწერები. ჩამოაყალიბეთ სწორი დროშები (CIT/MIT/COF), მხარი დაუჭირეთ გაფართოებებს წესების შესაბამისად, უზრუნველყეთ პან-უსაფრთხო შეყვანა და ააშენეთ ორკესტრი ჭკვიანი ხრიკებით და დაკვირვებით - შემდეგ ავთენტიფიკაცია გახდება მოკავშირე და არა კონვერტაციის მუხრუჭი.