3-D Secure 2. 0 және SCA

1) iGaming-операторына неліктен 3DS2 және SCA дегеніміз не?

3-D Secure 2. x (EMV 3DS) - e-commerce картасын ұстаушыны аутентификациялау хаттамасы.
SCA (Strong Customer Authentication) - бірқатар сценарийлерде екі факторлы тексеру жүргізуге міндеттейтін реттеуші талап (PSD2/UK).

• Liability shift: сәтті аутентификация кезінде алаяқтық тәуекелі эмитентке ауысады.
• Жоғарыдағы конверсия vs 3DS1: 100 + data-элементтерді жинау frictionless челленджсіз мүмкіндік береді.
• Жергілікті сценарийлер: iOS/Android үшін SDK, in-app, decoupled және out-of-band растау.

2) Рөлдер мен компоненттер (EMV 3DS)

3DS Server (сізде немесе PSP-де): схемаға сұрауларды қалыптастырады, девайс деректерін біріктіреді, 2 нұсқаларын басқарады. 1/2. 2/2. 3.
Directory Server (DS): схемалар роутері (Visa/Mastercard/AmEx және т.б.).
Access Control Server (ACS): эмитенттің сервері; шешім қабылдайды: frictionless немесе challenge.
SDK/Method: девайс-сигналдарды жинау (fingerprinting), web-SDK/iframe және mobile-SDK.

3) Үлгі UX-ағындары

3. 1 Frictionless (челленджсіз)

1. Merchant/PSP → DS: AReq 3DS деректерімен (девайс, тарих, тәуекел сигналдары).
2. DS/ACS → ARes (frictionless): аутентификация пайдаланушының қатысуынсыз өтті.
3. Келесі → авторизация (Auth).

Іске қосылғанда: төмен тәуекел, whitelist (Trusted Beneficiary), ЛВП, сапалық деректер.

3. 2 Challenge (челленджімен)

1. ARes CReq/CRes (OTP, банкте іске қосу-растау, биометрия) талап етеді.
2. Табыстан кейін → авторизация, liability shift сақталған.

3. 3 Decoupled / Out-of-Band

Банктің қосымшасындағы растау Мобайл сценарийлерінде пайдалы.

3. 4 3RI (3DS Requestor Initiated)

MIT (мерчант-бастамашыл транзакциялар) - жазылымдар, ретрациялар үшін пайдаланылады. Әрбір қайталауда SCA жоқ, бірақ initial CIT-ке дұрыс сілтеме қажет.

4) SCA: қайда міндетті және қайда әрекет етеді

Міндетті: егер эмитент және эквайер SCA аймағында болса, EEA/UK-дағы e-commerce транзакцияларының көпшілігі.
Аймақтан тыс/Out-of-scope: MOTO (пошта/телефон), кейбір корпоративтік арналар, аймақаралық бағыттар (эмитенттің TRA қолданылуы мүмкін).

4. 1 Ерекшеліктер (Exemptions)

TRA (Transaction Risk Analysis): провайдердің/банктің төмен тәуекелі (фрод өлшемдерімен расталады).
LVP (Low-Value Payments): эмитенттің табалдырықтары мен есептеуіштері бар шағын сомалар.
Whitelist (Trusted Beneficiary): эмитенттегі клиенттің ақ тізіміндегі алушы.
Secure Corporate/Merchant Initiated (MIT): егер SCA-мен initial CIT және дұрыс сілтемелер болса, SCA-дан тыс келесі есептен шығару.

5) iGaming үшін транзакциялар мен жалаушаларды таңбалау

CIT (Customer Initiated Transaction): бастапқы есептен шығару әдетте SCA (немесе exemption) талап етеді.
MIT Recurring/Unscheduled COF: келесі есептен шығару; бастапқы CIT байланысы болған жағдайда SCA талап етілмейді (пікірталас аралық сілтемелер/сәйкестендіргіштер).
PSP/схемаға сұрау салулардағы дұрыс индикаторлар liability shift және SCA қайталау үшін өте маңызды.

6) ACS шешіміне әсер ететін деректер

• Device/Browser: user-agent, accept headers, screen, timezone, language.
• Account data: тіркелгі жасы, соңғы құпия сөз күні, сәтсіз кіріс саны.
• Transaction data: МСС/санат, сома/валюта, алдыңғы әрекеттер, velocity.
• Shipping/Billing: мекенжайлар сәйкестігі, алушының тарихы.
• 3DS method completion indicator: 3DS Method (фингерпринт) жұмыс істеді ме.
• Контекст неғұрлым бай болса, frictionless мүмкіндігі соғұрлым жоғары болады.

7) Төлем оркестрімен интеграция ағындары

7. 1 Бірізділік (web/mobile)

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 және ретрайлер

SCA-сыз авторизация 'soft-decline (code)' → SCA-мен төлемді қайталай алады.
Оркестратор әрекеттер state-машина ұстайды: no SCA → soft-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 дейін деректердің (e-mail, мекенжайы, мінез-құлық сигналдары) Pre-collect.
Мөлдір күту экрандары және түсінікті мәтіндер (тіл/өңір бойынша оқшаулау).
Төлемге жұмсақ қайтарылатын таймауттар және челлендждің қайталамасы.
Whitelisting промпт: клиентке сенім білдірілген банкке (бар жерде) мерчант қосуды ұсыныңыз.

9) Қателер және төтенше жағдайлар

Timeout/Unavailable ACS → дұрыс кодтар және қайталау (немесе саясат бойынша fallback).
Version downgrade: егер 2. 2/2. 3 қол жеткізгісіз, үйлесімді нұсқаға кері қайту.
Partial method: Егер 3DS Method аяқталмаса, AReq - нөлге қарағанда ішінара деректерді жіберіңіз.
Mixed flows: бір уақытта 3DS + AVS мекенжай верификациясы - дұрыс статустар маппитасы.
3DS кейін Chargeback: артефактілермен (ECI, CAVV, ARes/CRes refs) дауласыңыз.

10) Сақталуы тиіс құжаттар мен артефактілер

3DS транзакция идентификаторлары (dsTransID, threeDSServerTransID).
Аутентификация нәтижелері (ECI, CAVV/AVV, ARes/CRes мәртебелері).
SDK логтары (PII/PAN жоқ), таймстемпалар және қате кодтары.
MIT жазылу/қайталау үшін initial CIT сілтемелері.
Soft-decline және TRA-ерекшеліктерді өңдеу саясаты.

11) Өлшемдер мен мақсаттар (iGaming үшін KPI)

Конверсия

3DS completion rate (аутентификацияны сәтті аяқтағандардың үлесі).
Frictionless vs challenge үлесі (мақсаты - ↑ frictionless).
3DS экрандарындағы Abandonment rate.

Тәуекел

liability shift кейін фрод-рейт (төмен - жақсы).
3DS-мен soft-decline үлесі және кейінгі ретрациялардың табыстылығы.

Техника

3DS p95 уақыты (бастама → нәтиже).
SDK/iframe қателері, ACS таймауттары.

12) Ұшырудың чек-парағы 3DS2 + SCA

• 3DS Server қосылған (2 нұсқасы. 1/2. 2/2. 3), тест-бинс пысықталды.
• Веб-SDK/мобайл-SDK біріктірілген (in-app + webview сценарийлер).
• de-vice/browser деректерін жинау қосылған (3DS әдісі).
• CIT/MIT/COF таңбалары дұрыс; initial CIT сілтемесі сақталады.
• SCA-дан soft-decline → қайталау ағыны оркестрде іске асырылды.
• Exemptions (TRA/LVP/whitelist) негізделген және себептері/нәтижелері талданады.
• Көп PSP: 3DS нұсқалары және fallback жолы тексерілді.
• Дэшборды KPI: frictionless %, challenge success %, abandon, soft-decline.
• 3DS артефактілерін және dispute ойнатқыштарын сақтау саясаты дайын.
• UX кеңестерінің A/B тестілері (локализация, мәтіндер, таймауттар) жоспарланған.

13) PCI DSS және токенизациямен өзара байланыс

3DS2 PCI DSS алмастырмайды: ол аутентификация туралы, ал PCI - деректерді қорғау туралы.
PAN-safe үшін: hosted fields/iframe картасын енгізу; оркестратор тек токендер мен 3DS-артефактілерді (ECI/CAVV) ғана көреді.
COF/MIT үшін желілік токендерді немесе vault-токендерді пайдаланыңыз.

14) FAQ қысқаша

Әрқашан 3DS жасау керек пе? SCA аймағында - иә, егер дұрыс exemption/ерекшелігі болмаса. Эмитент челлендж талап ете алады.
Егер банк бұзылса? Ретрайлер/таймауттар саясатын және мүмкіндігінше басқа бағытты пайдаланыңыз.
3DS конверсия өсімін бере ме? Деректері бай дұрыс теңшелген 3DS2 frictionless үлесін арттырады және фрод/чарджбектерді азайтады.
Табысқа жету үшін ең маңызды нәрсе не? Бай контекст деректері, CIT/MIT/COF дұрыс жалаулары, жылдам UX және soft-decline сауатты өңдеу.

15) Түйіндеме

iGaming 3DS2 + SCA үшін бұл «міндетті ауырсыну» емес, өсу құралы: көбірек frictionless, азырақ фрод, жауапкершілікті эмитентке ауыстыру, жазылымдарды және қайта есептен шығаруды тұрақты монетизациялау. Дұрыс жалаушаларды (CIT/MIT/COF) орнатыңыз, exemptions ережелерін сақтаңыз, қауіпсіз енгізуді қамтамасыз етіңіз және ақылды ретрасы мен бақылануы бар оркестратор жасаңыз - сонда аутентификация конверсия тежегішіне емес, одақтасқа айналады.