In-App provisioning - ApplePay In-App provisioning- ApplePay Токенізація платіжних карток у застосунку банку емітента Функція In-App provisioning від компанії Apple дає змогу банкам емітентам платіжних карток передавати дані до Apple Wallet безпосередньо з застосунку емітента для iOS. Користувачі вважають можливість токенізувати картку в застосунку банку дуже зручним способом підготовки карток на пристроях iOS, оскільки це дає змогу уникнути ручного введення даних. Емітенти вважають токенізацію в застосунку банку ефективним способом для взаємодії з Apple Wallet, який створює інтерфейс для токенізації карток та уніфікований шлюз взаємодії з іншими сервісами. Для банків, які випускають картки без тиснення номера картки, такий варіант токенізації стає дуже важливим способом просування свого продукту. Для продуктів, які базуються на випуску віртуальних карток, варіант токенізації через застосунок є практичним функціонально-необхідним продовженням для використання в торговельній мережі. Нижче наведено приклад підготовки в застосунку емітента платіжної картки, де користувач натискає кнопку "Додати в Apple Wallet", і починається процес. Оскільки процес починається і закінчується в застосунку, він забезпечує безперебійну роботу користувача. Процес токенізації через застосунок банку Нижче наведено приклад процесу токенізації в застосунку емітента для платіжної картки, де користувач натискає кнопку "Додати в Apple Wallet", і починається процес. Оскільки процес починається і закінчується в застосунку, він забезпечує безперервну роботу користувача. Add to Apple Wallet Після вибору картки та натискання кнопки, користувачі побачать екран із запитом на підтвердження активації токенізації картки. Після підтвердження користувачем необхідно буде прийняти умови обслуговування емітента, щоб ця картка була додана в Apple Wallet. Потім з'явиться екран підтвердження про токенізацію. У процесі токенізації картки в застосунку користувач може вибрати пристрій, на який потрібно додати картку, якщо в нього є пов'язані Apple Watch, а картку не додано на жоден пристрій. iOS автоматично пропонує цю можливість; застосунок-емітент не може нею керувати. Застосунку необхідно коректно ініціалізувати API iOS, щоб вибір пристрою відображався тільки в тому разі, якщо картку не додано на жоден пристрій. Після цього екрана відбувається повернення в застосунок емітента. У застосунку банку така картка буде позначена спеціальним значком. Рис. Процес токенізації через застосунок банку Безпека Для використання функції In-App Provisioning додаток банку емітента має відповідати таким вимогам: A. Security Control Requirements – Вимоги до контролю безпеки; B. Multifactor Authentication Requirements – Вимоги до багатофакторної аутентифікації; C. UpgradetoGreenPath - Рекомендації при переході на зелений шлях обробки даних. Зупинимося тільки на перших двох. Ці вимоги належать до додатка банку емітента. Під час виконання функціонального тестування ці вимоги будуть перевірятися. Вимоги до контролю безпеки використання різних символів у паролі до додатка (Aa_*.;23); мінімальна довжина пароля 6 символів; контроль невірних спроб введення пароля (зазвичай 3); використання додаткових каналів або перевірка в колл-центрі, якщо облікові дані користувача додатка (ім'я користувача та пароль) змінювалися протягом 60 днів до спроби токенізації картки. Вимоги до багатофакторної аутентифікації Впровадження In-App Provisioning вимагає багатофакторної аутентифікації користувача як мінімум один раз перед активацією спроби токенізації. Існує два затверджених підходи до реалізації багатофакторної аутентифікації: - Багатофакторна аутентифікація на нерозпізнаних пристроях. Використуйте багатофакторну аутентифікацію з одноразовим паролем (OTP), який система передає в постійний канал (MFA) для нових і нерозпізнаних пристроїв, щоб гарантувати верифікацію користувача під час першої спроби доступу до нещодавно встановленого застосунку. Якщо користувач згодом використовує той самий застосунок на тому самому пристрої для підготовки картки для Apple Pay, вихідна MFA задовольняє вимогам MFA для In-App Provisioning. - Перевірка в додатку за допомогою одноразового коду. Якщо емітент не виконує багатофакторну автентифікацію (MFA) під час установлення застосунку, йому необхідно виконати її під час перевірки для підтвердження особи користувача, який бажає отримати картку. Емітент може зробити це, використовуючи стандартні можливості платформи (однофазовий пароль постійним каналом зв'язку або, якщо такий канал відсутній, застосунок може увімкнути в кол-центрі). Зверніть увагу, що може використовувати перевірку в застосунку замість SMS, електронної пошти або кол-центру, якщо результатом перевірки є перевірка в застосунку (оскільки це не забезпечує додаткової безпеки). Процес токенізації через застосунок У застосунку банку емітента клієнти можуть побачити список карток, якими вони користуються. Якщо картка не токенізована, клієнт може почати цей процес безпосередньо із застосунку банку. У застосунку банку емітента клієнти можуть побачити список карток, якими вони користуються. Якщо картка не токенізована, клієнт може почати цей процес безпосередньо із застосунку банку. Рис. Процедура токенізації із застосунку банку. Переваги токенізації через застосунок банку Для клієнта банку емітента, який має повсякденний досвід використання застосунку банку, не буде стресом виконати ініціалізацію токенізації картки. Усі вимоги Apple Pay зводяться до фактичного натискання однієї кнопки. Для клієнта 1. Миттєва прив'язка картки до гаманця. Не потрібно вручну вводити PAN, термін дії, CVV. Картка токенізується в Apple Wallet за кілька кліків. Можливість токенізації картки на інших девайсах. 2. Підвищена безпека. Передача даних йде в зашифрованому вигляді з додатка банку до MDES/VTS, виключаючи ризик компрометації при введенні вручну. 3. Найкращий користувацький досвід (UX). Користувач виконує токенізацію у відомому йому додатку. Можлива генерація токена одразу після емісії картки і клієнт може платити смартфоном, навіть якщо фізична картка ще не доставлена або картка віртуальна. Для банку-емітента 1. Зростання активності карток. Клієнти можуть використовувати картку відразу. 2. Зниження відмов. Менше помилок при введенні реквізитів вручну. Відсутність недоактивованих карток. 3. Управління життєвим циклом токена. Банк отримує більше контролю над токеном: активація, блокування, видалення через свій застосунок.