![](https://habrastorage.org/getpro/habr/upload_files/0b2/9cb/747/0b29cb747ee23134f051a7cca56b6ed3.jpg)
Введение
Всем привет. Мы Денис и Александр из команды разработки сертификационных приложений Мир Plat.Form.
Мы занимаемся развитием систем, которые помогают банкам-участникам платежной системы «Мир» и поставщикам платежных решений выполнять тестирование.
Многие из нас совершают покупки с помощью платежных инструментов «Мир» (пластиковые карты, мобильные приложения MIRPay, Samsung Pay и т.д.), и мы, со стороны платежной системы, хотим, чтобы платежи проходили без сбоев и трудностей. Для этого платежная система «Мир» разработала требования по сертификации.
MIR CIT Mobile – это комплекс мероприятий, направленный на проверку корректности настроек программного обеспечения POS - терминалов требованиям платежной системы «Мир» (терминалы, банкоматы), позволяющий снизить риски отказа и/или некорректного обслуживания карт.
Ранее для проведения тестирования эквайеру требовалось наличие ПК и интернета (для доступа к сертификационному сервису), браузера Chrome, специального плагина и PC/SC- совместимого считывателя для записи тестовых карт и чтения EMV-логов. Перечень оборудования представлен на рис 1.
![Рис. 1 Рис. 1](https://habrastorage.org/getpro/habr/upload_files/e75/f75/50d/e75f7550d2c2d2e84fcc6440da643881.png)
Как видно, инструментарий для тестирования простой и доступный. Тем не менее, оставались ситуации, в которых существующий инструментарий не покрывал всех потребностей инженера банка. Например, когда рабочее место с ПК и тестовый стенд физически удалены друг от друга.
Учитывая сложившуюся ситуацию, мы в Мир Plat.Form приняли решение оптимизировать тестовый инструментарий и обеспечить возможность инженеру банка выполнять сертификационные мероприятия там, где это удобно. Поставленная задача, несмотря на ее сложность, оказалась решаемой и интересной, а также уникальной для такого узкого технического направления. В результате было разработано и внедрено мобильное приложение Android для сертификации терминального оборудования эквайеров. В процессе разработки нам пришлось справиться с рядом вызовов. Итак, обо всем по порядку.
Выбор варианта реализации приложения
Прежде всего необходимо было определиться с тем, какой тип приложения будем разрабатывать.
Прорабатывали варианты реализации:
Нативное приложение;
Progressive Web Application;
WebView.
Выбрали реализацию нативного приложения из-за необходимости интеграции с системой Android, работой с NFC, а также предоставления иного UI/UX на мобильном устройстве по сравнению с Web-версией.
Дизайн
После этого предстояло заняться разработкой дизайна приложения. Главным вызовом стала задача перенести функционал большого и сложного сервиса с десктопа на маленький экран мобильного телефона, не потеряв при этом в удобстве использования. Помимо этого, возникали сложности с ограничениями платформы Android и поиском примеров, поскольку многие элементы были уникальны. Мы собрали подборку графических элементов, которые хоть немного подходили под наши задачи, составили список функций, без которых мобильное приложение не имело бы смысла, и наш дизайнер набросал первый прототип. Это позволило нам более точно представить, что сработает, а что нет, и что из этого действительно можно реализовать на платформе Android. Когда все детали были утверждены, дизайнер финализировал макеты и передал их в разработку.
На рисунке 2 показан пример web-страницы проведения сертификационного тестирования, возникшие затруднения заставили подойти творчески к решению проблемы, и результат можно увидеть. на рисунке 3.
![Рис. 2 Рис. 2](https://habrastorage.org/getpro/habr/upload_files/0ab/427/15f/0ab42715fea03c06868f3560a9ba6ad2.jpg)
![Рис.3 Рис.3](https://habrastorage.org/getpro/habr/upload_files/844/2be/047/8442be047974d59ab570cef6359d8db1.png)
Далее оптимизация интерфейса происходила итеративно — мы улучшали существующие функции на основе фидбэка от пользователей, а также добавляли новые элементы. В итоге у нас появилась устоявшаяся структура и визуальный стиль. Подобнее об особенностях построения мобильного приложения мы расскажем в следующий раз.
Модуль авторизации пользователя к программному обеспечению
Web-приложение для аутентификации и авторизации пользователей использует современный протокол OAuth 2.0, что хорошо подходит и для мобильных решений.
Для удобства пользователя были сделаны вход по PIN-коду, а также с использованием биометрической аутентификации (Face ID и отпечаток пальца), что отвечает современным тенденциям мобильной разработки.
Разработка сертификационного компонента на базе NFC
Задачи авторизации и имплементации мобильного UI/UX были успешно решены, и настала очередь реализовать функционал проведения сертификационного тестирования, а точнее запись и чтение тестовой карты при помощи технологии NFC .
Для проведения сертификации применяются специальные тестовые карты, показанные на рисунке 4, которые можно персонализировать различными профилями, превращая каждый раз исходную карту в совершенно новую карту с набором уникальных характеристик, необходимых для тестирования определённого функционала оборудования приема карт «Мир».
![Рис. 4 Рис. 4](https://habrastorage.org/getpro/habr/upload_files/fac/5e9/9d5/fac5e99d5c6bce141ebfe691f9fc1190.jpg)
Для чтения карты всё довольно стандартно: мы инициализируем NfcAdapter в режиме ридера, а далее считываем данные с NFC-тега карты, а затем работаем с полученной EMV-информацией.
Для записи через NfcAdapter передаем данные через метод NFC-тега tranceive и валидируем ответ от карты после обработки картой переданных данных.
Реализовав функционал записи и чтения тестовой карты для передачи EMV данных с помощь модуля NFC, мы приступили к тестированию. Первые тесты показали, что процент успешной персонализации карты составил около 50% рис. 5.
![Рис. 5 Рис. 5](https://habrastorage.org/getpro/habr/upload_files/ff2/06a/bcb/ff206abcb9b14d04065c0e6332acd453.png)
Такой процент нас не устраивал.
Как было написано выше, карта — это пассивная метка, которая не имеет собственного источника питания и для успешной записи и чтения данных с карты необходимо повысить напряженность магнитного поля создаваемое модулем NFC, в нашем случае это смартфон. Наметили вектор исследования проблемы, можем ли влиять на напряженность электрического поля модуля NFC через API, но такая возможность отсутствовала.
И раз мы не можем влиять на API, то необходимо точно позиционировать карту с антенной модуля NFС на смартфоне. Для этой цели рекомендовали пользователям определить точное положение модуля NFС в смартфоне. При запущенном тесте, как только карта попадала в поле модуля NFC, смартфон вибрировал. Так пользователь мог определить расположение антенны и прикладывать карту именно к нему, повышая вероятность успешной персонализации.
Принцип позиционирования представлен на Рис. 6.
![Рис. 6 Рис. 6](https://habrastorage.org/getpro/habr/upload_files/46e/b85/c72/46eb85c726d55483e152f618c2741cb9.png)
Затем анализировали возможность ограничения распознавания конкретных типов NFC-тэгов, в частности работали над распознаванием поддержки Mifare чипом NFC устройства. Пробовали ограничение через конфигурируемые наборы в xml, что не дало существенного результата. При этом данный подход позволил нам начать собирать аналитику по параметрам используемых устройств, в особенности, информацию о наличии поддержки Mifare, конфигурации и характеристиках устройства, успешности выполнения персонализации. В результате анализа полученных данных мы смогли приступить к формированию списка наиболее устойчиво работающих устройств.
Добавили флаги включения NFC ReaderMode, подходящие под используемые тестовые карты.
После данной доработки процент успешной записи и чтения тестовой карты был поднят до 70%, рис. 7.
![Рис. 7 Рис. 7](https://habrastorage.org/getpro/habr/upload_files/b5b/3ed/2e6/b5b3ed2e63ce77118dfdba6902ae3cde.png)
Такой процент уже радовал, но хотелось большего. И мы поставили новую цель: как минимум, 80%. Начали пристально изучать логи записи и чтения карты и выяснили, что при низкой напряженности поля NFC карта может увеличивать время записи данных, а также не успевать отдавать данные, при этом приложение считало, что данные отсутствуют.
Для минимизации эффекта потери тэга мы ввели два параметра, конфигурируемых пользователем через настройки приложения: “Задержка обнаружения NFC тэга” и “Таймаут ожидания ответа NFC”.
Вычислили и установили указанные параметры в качестве параметров «по умолчанию» и предложили тест-группе опытным путем добиться максимального результата. Добавили сбор параметров в аналитику и начали накапливать информацию о достаточном количестве успешных сессий персонализации карт с идентичными параметрами. В результате смогли подобрать оптимальные значения для успешной записи и чтения данных с карты, которые установили «по умолчанию» в промышленной версии приложения.
Результат нас приятно удивил, рис. 8.
![Рис. 8 Рис. 8](https://habrastorage.org/getpro/habr/upload_files/f58/bd9/424/f58bd9424d2adfc25c3156cef24129d9.png)
С таким процентом успешных сессий чтения/записи приложение было передано на Friends&Family-тестирование нашим партнерам.
Заключение
Возникающие вызовы заставили искать творческий подход в решении проблем, по итогу внедрения мы предложили рынку альтернативный инструментарий тестирования, заменяющий целый набор устройств одним устройством – смартфоном с приложением Mir CIT Mobile. Это позволило решить проблему мобильности сертификационных инженеров банков-эквайеров, так как теперь им не нужно возить с собой лишнюю аппаратуру, не нужно бегать от условного банкомата к ПК. Если среди читателей есть участники платежной системы «Мир», занимающиеся сертификацией, поделитесь, пожалуйста, в комментариях своими впечатлениями.