Розуміємо 3‑D Secure (3DS): як працює автентифікація та чому платежі не проходять

Чому це важливо

3‑D Secure (особливо сучасна 3DS2) — головний технічний механізм для автентифікації емітентом у онлайн‑транзакціях без фізичної картки; більшість збоїв спричинені помилками інтеграції, перериваннями на боці пристрою/UX, політиками емітентів, обробкою шлюзом або регіональними правилами SCA — кожну проблему можна пом'якшити.

Що таке 3‑D Secure і які версії використовуються

3‑D Secure — це промисловий протокол, який підключає автентифікацію емітента (ACS) у процес оплати онлайн, щоб емітент міг провести ризик‑оцінку або кидати виклик транзакції до її авторизації. EMVCo підтримує специфікацію; сьогодні використовують EMV® 3‑D Secure (3DS2).

EMVCo випускає оновлення v2.x; рекомендовано застосовувати v2.2 або новіше для покращеної функціональності. Версія v2.3 додала підтримку WebAuthn/FIDO — перевірте актуальну версію EMVCo на дату публікації.

• 3DS дозволяє емітенту робити ризик‑аналіз перед авторизацією транзакції.
• Використовуйте EMVCo v2.x (рекомендовано >= v2.2) для зменшення тертя.

Як працює типовий 3DS2‑флоу

Продавець надсилає AReq із даними транзакції та пристрою до сховища схеми і ACS емітента. Емітент або повертає 'frictionless' (без виклику), або ініціює виклик — OTP, push‑повідомлення в додатку, WebAuthn тощо.

Після ARes продавець продовжує авторизацію через еквайра. Сучасна 3DS2 дозволяє надсилати більше даних і використовувати нативні SDK для мобільних додатків, що підвищує ймовірність проходження без виклику.

• AReq → схема/ACS → frictionless або challenge → ARes → авторизація транзакції.
• 3DS2 підтримує WebAuthn та нативні мобільні SDK.

Чому відбуваються збої автентифікації

Поширені причини: відсутні або неповні поля 3DS в AReq (помилки інтеграції), блокування iframe чи перехід користувача в інший додаток (переривання), політика емітента або відсутність підтримки 3DS2 емітентом, проблеми з OTP/OOB, і помилки шлюзу/маршрутизації.

Діагностика: перевірте, що ви відправляєте обов’язкові поля, використовуйте нативні SDK де можливо, тестуйте у sandbox, інтерпретуйте коди ACS/шлюзу та забезпечте запасний шлях оплати.

• Помилковий AReq → fallback або відмова; перевірте повні поля.
• Блокування iframe/перехід додатку → таймаути; використовувати нативні SDK.
• OTP через SMS має ризики — підтримуйте WebAuthn/пуш‑автентифікацію.
• Шлюз може некоректно мапити результати — тестуйте у sandbox.

Практичні кроки для пом'якшення проблем

Використовуйте EMVCo‑схвалений 3DS2 SDK, надсилайте повний набір даних пристрою і транзакції в AReq та тестуйте різні сценарії в sandbox вашого PSP/шлюзу. Це підвищує шанс, що емітент прийме транзакцію без виклику.

Покращуйте UX при викликах: інформуйте користувача залишатися у браузері/додатку під час перевірки, підвищуйте таймаути в розумних межах, і надавайте альтернативні способи оплати при невдачі автентифікації.

• Підтвердьте, що SDK у вас — в списку схвалених продуктів EMVCo.
• Надсилайте повні AReq поля (device fingerprint, transaction context).
• Тестуйте з офіційними тестовими картами у PSP sandbox.
• Реалізуйте зрозумілі повідомлення для кінцевого користувача та запасні методи оплати.

Що перевірити

• Поставити і перевірити EMVCo‑схвалений 3DS2 SDK.
• Надсилати повні дані пристрою/транзакції в AReq.
• Протестувати флоу з тестовими картами у sandbox шлюзу.
• Надати інструкції для користувача під час challenge і альтернативні способи оплати.