Які дії виконує Google\Apple, якщо клієнт НЕ ввів OTP під час токенізації в гаманці? Які дії виконує Google\Apple, якщо клієнт НЕ ввів OTP під час токенізації в гаманці? Якщо клієнт у процесі токенізації картки вибирає аутентифікацію через надсилання йому OTP через СМС на фінансовий номер телефону, який знає банк-емітент, і потім не вводить OTP, фактично це означає наступне. - клієнт змінив номер телефону і не повідомив про це банк; - клієнт не має доступу до свого телефону в конкретний момент; - мобільний оператор має проблеми з доставкою СМС; - телефон впав і розбився; - клієнта відволікли від процесу, і він забув, що виконував токенізацію. Введення OTP в гаманці і подальше порівняння значення OTP є важливим фактором аутентифікації. Ця дія підтверджує, що саме власник картки виконує токенізацію в гаманці. Далі відбуватимуться такі процеси: 1. Процес токенізації не завершено коректно: Процес токенізації зупиняється, токен не створюється, картка не прив'язується до Apple Pay / Google Pay. 2. Період сесії введення OTP «provisioning session»: Кожен запит на токенізацію має період сесії введення OTP. Якщо клієнт нічого не зробив, сесія закривається. Apple Pay: 5–10 хвилин; Google Pay: до 5 хвилин. Для клієнтів Apple Pay додатково надійде нагадування в кінці дня і, можливо, через 7 днів. 3. Банк-емітент фіксує таку спробу як «невдалу»: У системі емітента фіксується статус незавершення процесу токенізації: OTP not entered; User abandoned authentication; Provisioning attempt failed — authentication incomplete. Така інформація дуже важлива для платіжних систем з точки зору аналітики шахрайства та незавершеності процесу. Платіжні системи дуже серйозно ставляться до такої інформації і можуть накласти штраф на банк-емітент, якщо відсоток таких операцій перевищуватиме 2,5%. 4. Повідомлення про помилку: Гаманець Apple Pay покаже користувачеві помилку: «Card Not Added»; «Authentication Required». І запропонує спробувати токенізувати картку знову. «Try Again Later» Гаманець Google Pay показує користувачеві помилку: «Couldn't finish setup»; «Verification required». І попросить виконати токенізацію картки знову. «Try again» 5. Клієнт може ініціювати повторну токенізацію: Якщо клієнт не ввів OTP з будь-якої причини, перерахованої вище, або з якоїсь іншої причини, з його картою нічого не станеться. Ніякого блокування картки не буде. Процесс токенізації завжди можна повторити, і це не вплине на статус картки: Через Wallet (ручне введення картки та прив'язка); Через банківський додаток (push provisioning). Єдине, що треба враховувати, це те, що повторні спроби впливають на систему аналітики, наприклад в Apple Pay. Кілька спроб призводять до рекомендації виконати посилену перевірку клієнта: Yellow або Orange Path. Якщо клієнт переривав OTP або кілька разів не пройшов перевірку, рекомендований шлях може перейти, наприклад, з Green → Yellow іноді з Yellow → Orange (рідко) Банки-емітенти зазвичай обмежують кількість спроб введення OTP: 3–5 OTP спроб за сесію; 5 спроб на добу; 3 спроби для віртуальних карт на добу. Такі обмеження дозволяють банку мінімізувати фрод. Apple може заблокувати подальші спроби на деякий час Це вимушена тимчасова пауза (rate-limit), наприклад: 2 хвилини; до 24 годин — у рідкісних випадках (підозра на фрод). Google Pay більш гнучкий до повторних спроб Google Pay працює через VTS (Visa Token Service) або MDES (Mastercard Digital Enablement Service), але сценарії у Google інший, більш гнучкий, часто більше діагностики. Google не перемикає ризик-шляхи так агресивно, але при 3–5 повторних невдалих спробах буде виконуватися наступне: verification path може стати Enhanced Verification; запропонує інший метод верифікації: дзвінок в банк; вхід в додаток; автоматична перевірка за допомогою внутрішніх параметрів ризику Google. Висновок: якщо клієнт отримує відмову в першій сесії токенізації, повторну сесію потрібно виконувати через кілька днів.