Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Введение
Всем привет. Мы Денис и Александр из команды разработки сертификационных приложений Мир Plat.Form.
Мы занимаемся развитием систем, которые помогают банкам-участникам платежной системы «Мир» и поставщикам платежных решений выполнять тестирование.
Многие из нас совершают покупки с помощью платежных инструментов «Мир» (пластиковые карты, мобильные приложения MIRPay, Samsung Pay и т.д.), и мы, со стороны платежной системы, хотим, чтобы платежи проходили без сбоев и трудностей. Для этого платежная система «Мир» разработала требования по сертификации.
Сертификация – это комплекс мероприятий, направленный на проверку корректности настроек оборудования приема карт «Мир» (терминалы, банкоматы), позволяющий снизить риски отказа и/или некорректного обслуживания карт.
Ранее для проведения тестирования эквайеру требовалось наличие ПК и интернета (для доступа к сертификационному сервису), браузера Chrome, специального плагина и PC/SC- совместимого считывателя для записи тестовых карт и чтения EMV-логов. Перечень оборудования представлен на рис 1.
Как видно, инструментарий для тестирования простой и доступный. Тем не менее, оставались ситуации, в которых существующий инструментарий не покрывал всех потребностей инженера банка. Например, когда рабочее место с ПК и тестовый стенд физически удалены друг от друга.
Учитывая сложившуюся ситуацию, мы в Мир Plat.Form приняли решение оптимизировать тестовый инструментарий и обеспечить возможность инженеру банка выполнять сертификационные мероприятия там, где это удобно. Поставленная задача, несмотря на ее сложность, оказалась решаемой и интересной, а также уникальной для такого узкого технического направления. В результате было разработано и внедрено мобильное приложение Android для сертификации терминального оборудования эквайеров. В процессе разработки нам пришлось справиться с рядом вызовов. Итак, обо всем по порядку.
Выбор варианта реализации приложения
Прежде всего необходимо было определиться с тем, какой тип приложения будем разрабатывать.
Прорабатывали варианты реализации:
Нативное приложение;
Progressive Web Application;
WebView.
Выбрали реализацию нативного приложения из-за глубокой интеграции с системой Android, работой с NFC, а также предоставления иного UI/UX на мобильном устройстве по сравнению с Web-версией.
Дизайн
После этого предстояло заняться разработкой дизайна приложения. Главным вызовом стала задача перенести функционал большого и сложного сервиса с десктопа на маленький экран мобильного телефона, не потеряв при этом в удобстве использования. Помимо этого, возникали сложности с ограничениями платформы Android и поиском примеров, поскольку многие элементы были уникальны. Мы собрали подборку графических элементов, которые хоть немного подходили под наши задачи, составили список функций, без которых мобильное приложение не имело бы смысла, и наш дизайнер набросал первый прототип. Это позволило нам более точно представить, что сработает, а что нет, и что из этого действительно можно реализовать на платформе Android. Когда все детали были утверждены, дизайнер финализировал макеты и передал их в разработку.
На рисунке 2 показан пример web-страницы проведения сертификационного тестирования, возникшие затруднения заставили подойти творчески к решению проблемы, и результат можно увидеть. на рисунке 3.
Далее оптимизация интерфейса происходила итеративно — мы улучшали существующие функции на основе фидбэка от пользователей, а также добавляли новые элементы. В итоге у нас появилась устоявшаяся структура и визуальный стиль. Подобнее об особенностях построения мобильного приложения мы расскажем в следующий раз.
Авторизация
Web-приложение для аутентификации и авторизации пользователей использует современный протокол OAuth 2.0, что хорошо подходит и для мобильных решений.
Для удобства пользователя были сделаны вход по PIN-коду, а также с использованием биометрической аутентификации (Face ID и отпечаток пальца), что отвечает современным тенденциям мобильной разработки.
Сертификация с NFC
Задачи авторизации и имплементации мобильного UI/UX были успешно решены, и настала очередь реализовать функционал проведения сертификационного тестирования, а точнее запись и чтение тестовой карты при помощи технологии NFC .
Для проведения сертификации применяются специальные тестовые карты, показанные на рисунке 4, которые можно персонализировать различными профилями, превращая каждый раз исходную карту в совершенно новую карту с набором уникальных характеристик, необходимых для тестирования определённого функционала оборудования приема карт «Мир».
Для чтения карты всё довольно стандартно: мы инициализируем NfcAdapter в режиме ридера, а далее считываем данные с NFC-тега карты, а затем работаем с полученной EMV-информацией.
Для записи через NfcAdapter передаем данные через метод NFC-тега tranceive и валидируем ответ от карты после обработки картой переданных данных.
Реализовав функционал записи и чтения тестовой карты для передачи EMV данных с помощь модуля NFC, мы приступили к тестированию. Первые тесты показали, что процент успешной персонализации карты составил около 50% рис. 5.
Такой процент нас не устраивал.
Как было написано выше, карта — это пассивная метка, которая не имеет собственного источника питания и для успешной записи и чтения данных с карты необходимо повысить напряженность электрического поля создаваемое модулем NFC, в нашем случае это смартфон. Наметили вектор исследования проблемы, можем ли влиять на напряженность электрического поля модуля NFC через API, но такая возможность отсутствовала.
И раз мы не можем влиять на API, то необходимо точно позиционировать карту с антенной модуля NFС на смартфоне. Для этой цели рекомендовали пользователям определить точное положение модуля NFС в смартфоне. При запущенном тесте, как только карта попадала в поле модуля NFC, смартфон вибрировал. Так пользователь мог определить расположение антенны и прикладывать карту именно к нему, повышая вероятность успешной персонализации.
Принцип позиционирования представлен на Рис. 6.
Затем анализировали возможность ограничения распознавания конкретных типов NFC-тэгов, в частности работали над распознаванием поддержки Mifare чипом NFC устройства. Пробовали ограничение через конфигурируемые наборы в xml, что не дало существенного результата. При этом данный подход позволил нам начать собирать аналитику по параметрам используемых устройств, в особенности, информацию о наличии поддержки Mifare, конфигурации и характеристиках устройства, успешности выполнения персонализации. В результате анализа полученных данных мы смогли приступить к формированию списка наиболее устойчиво работающих устройств.
Добавили флаги включения NFC ReaderMode, подходящие под используемые тестовые карты.
После данной доработки процент успешной записи и чтения тестовой карты был поднят до 70%, рис. 7.
Такой процент уже радовал, но хотелось большего. И мы поставили новую цель: как минимум, 80%. Начали пристально изучать логи записи и чтения карты и выяснили, что при низкой напряженности поля NFC карта может увеличивать время записи данных, а также не успевать отдавать данные, при этом приложение считало, что данные отсутствуют.
Для минимизации эффекта потери тэга мы ввели два параметра, конфигурируемых пользователем через настройки приложения: “Задержка обнаружения NFC тэга” и “Таймаут ожидания ответа NFC”.
Вычислили и установили указанные параметры в качестве параметров «по умолчанию» и предложили тест-группе опытным путем добиться максимального результата. Добавили сбор параметров в аналитику и начали накапливать информацию о достаточном количестве успешных сессий персонализации карт с идентичными параметрами. В результате смогли подобрать оптимальные значения для успешной записи и чтения данных с карты, которые установили «по умолчанию» в промышленной версии приложения.
Результат нас приятно удивил, рис. 8.
С таким процентом успешных сессий чтения/записи приложение было передано на Friends&Family-тестирование нашим партнерам.
Заключение
Возникающие вызовы заставили искать творческий подход в решении проблем, по итогу внедрения мы предложили рынку альтернативный инструментарий тестирования, заменяющий целый набор устройств одним устройством – смартфоном с приложением Mir CIT Mobile. Это позволило решить проблему мобильности сертификационных инженеров банков-эквайеров, так как теперь им не нужно возить с собой лишнюю аппаратуру, не нужно бегать от условного банкомата к ПК. Если среди читателей есть участники платежной системы «Мир», занимающиеся сертификацией, поделитесь, пожалуйста, в комментариях своими впечатлениями.
