Мы разработали фичу для восточноевропейского банка, благодаря которой клиент может подключить карту к Google Pay прямо в приложении. В проекте были задействованы пять участников: мы, банк, Google Pay, интегратор и токен сервис-провайдер. У трёх последних в документации были белые пятна, на прояснение которых ушло полтора месяца, хотя разработка с нашей стороны заняла всего две недели.
Я Владислав Кортиков, Android-разработчик в KODE. В статье рассказал, что может ждать вас при добавлении подобной фичи в банковское приложение. Здесь много неочевидных моментов, постигнутых с болью, и возможно однажды эта информация поможет кому-то сэкономить силы и время.
Зачем банку токенизация
Банк хотел, чтобы клиенты могли добавлять карты в Google Pay прямо из мобильного приложения. Для этого ему нужно было токенизировать карты сначала на стороне сервера, а затем — в приложении.
За год банк перевёл клиентов на карты VISA, а серверный вендор с лицензией от VISA токенизировал их на сервере. Оставалось сделать токенизацию карт в приложении. Летом 2023 года банк передал эту задачу нашей команде, которая имела подобный опыт и работала с сервисами Google.
С помощью фичи банк планировал увеличить мотивацию клиентов установить приложение и DAU — daily active users. Логика была такой:
- Банку нужно как можно больше клиентов в приложении, потому что там он предлагает продукты и услуги.
- Клиенту удобно оплачивать покупки телефоном и не искать по карманам физическую карту.
- Чтобы оплачивать покупки телефоном, клиент может скачать приложение и прямо в нём добавить банковскую карту в Google Pay.
- А чтобы клиент мог добавить карту в Google Pay, банку нужно сделать фичу.
Три чёрных ящика
Чтобы разработать фичу, мне нужно было узнать о специальном API от Google Pay — Push Provisioning API. Информации в открытом доступе о нём не было. Мы связались с Google через менеджера банка и запросили документацию, которую я изучил вместе с аналитиком.
После чтения документации у нас остались три «чёрных ящика»:
- Google Pay,
- Интегратор,
- Токен сервис-провайдер.
В документации Android-разработчика не было точной информации о том, как работает сервер и как он общается с токен сервис-провайдером. Документация описывала, как всё должно быть на клиенте и давала подсказки для разных случаев. Но она не давала понимания, что сделал интегратор и точно ли он сделал это в соответствии с документацией токен сервис-провайдера.
Поэтому когда возникали проблемы, мне нужно было предполагать, что именно сделал не так интегратор или токен сервис-провайдер. Я заново открывал документацию, искал приписки внизу маленькими буквами и выдвигал гипотезу об изменениях. Если она не срабатывала, проверял следующую гипотезу. А когда упирался в тупик, шёл общаться к Google Pay, интегратору или токен сервис-провайдеру, и коммуникация затягивалась.
Основной сценарий по добавлению карты
Я поделил добавление карты на два этапа: сначала настроил каркас, а потом делал полноценное подключение.
Первый этап: интеграция с SDK Google Pay
Для взаимодействия с SDK Google Pay нужно было настроить интеграцию с Push Provisioning API. Я не писал логику и не соблюдал внутренние функциональные требования фичи, только следовал требованиям документации к API, чтобы сделать минимальную реализацию для проверки работоспособности. Затем я запросил у Google то, чего не хватило — например, разрешение на тестирование Push Provisioning API для конкретных версий приложения. Для этого нужно было заполнить анкету и описать конфигурацию приложения: передать Android ID и хэш ключа подписи. Этот этап помог сократить ошибки в будущем.
Также я написал надстройку над SDK, чтобы скрыть её внешние зависимости.
Второй этап: полная реализация сценария
После того, как я настроил работу интерфейсов, появился каркас для полноценного подключения. Мы собрали бизнес-требования из строгих требований Google к дизайну и требований банка, и приступили к работе.
Запрос Get OPC
У меня есть middleware-сервер — прослойка между сервисами банка и мобильного приложения. Чтобы добавить карту, нужно передать SDK специальный OPC-токен. Приложение не генерирует этот токен, и чтобы его получить, я отправляю на middleware-сервер запрос Get OPC. В запросе передаю серверу три параметра о пользователе:
- Идентификатор, который предоставляет SDK — Stable Hardware ID.
- Идентификатор текущего Wallet — кошелька, который установлен у пользователя.
- ID карты.
Сервер обращается к интегратору, тот общается с токен сервис-провайдером и возвращает обратно токен. При этом я не использую первые два идентификатора для сбора информации о пользователе.
Логика добавления карты
Пользователь выбирает карту, которую хочет подключить в Google Pay, и начинает сценарий добавления карты. Я получаю три идентификатора — Stable Hardware ID, идентификатор текущего Wallet и ID карты пользователя, вызываю метод Get OPC и получаю токен. Затем отдаю токен SDK и вызываю в нём метод Push Tokenize.
Далее передаю управление SDK, и он открывает на своей стороне экраны вроде: «Вы хотите добавить карту в Google Pay. Подпишите необходимые соглашения». Пользователь остается внутри банковского приложения и проходит сценарий добавления карты: активирует её, подтверждает согласие на обработку данных. При успешном завершении сценария SDK возвращает результат в приложение и пользователь видит, что карта добавлена в Google Pay. После этого приложение может предложить ему назначить карту способом оплаты по умолчанию.
Если у пользователя на устройстве не одна активная учетная запись Google, а несколько, для каждой из них нужен свой Wallet ID. В таком случае нужно выбрать текущую активную учетную запись, которую установил пользователь, вызвать запрос Get OPC, отправить три идентификатора и получить токен.
Верификация в Google
Помимо «чёрных ящиков», на каждом этапе разработки большую роль играл Google.
Во-первых, как я уже писал выше, чтобы добраться до документации Push Provisioning API, нужно было подавать запрос в Google.
Во-вторых, у Google строгие гайдлайны по дизайну, которые до мелочей регламентируют визуал фичи. У сценария добавления карты в приложение чёткий алгоритм: например, когда пользователь оформляет карту, приложение обязательно должно показать ему, что он может подключить её в Google Pay.
В-третьих, помимо отдельного тестирования фичи, у Google были обязательные тест-кейсы, которые должно было пройти приложение.
В-четвёртых, в конце Google провёл валидацию — получил приложение и протестировал его. Только после этого он разрешил использовать фичу в релизных сборках.
Затем мы собрали альфа-сборку и передали приложение на проверку в банк. Для этого мы предоставили доступ к тестовым данным, чтобы сотрудники банка прошли конкретные шаги. Фичу релизили c выключенной feature toggle, чтобы она не была видна пользователям, пока банк не прошёл нужные сценарии и мы не исправили обнаруженные проблемы. А потом нужно было ещё раз получить финальный аппрув от Google. Наконец, мы дождались, когда какое-то количество пользователей обновит приложение и включили фичу.
Результаты
Для реализации фичи по добавлению банковской карты в Google Pay нужно было выполнить четыре функциональных требования. Мы сделали:
Первичную интеграцию с проверкой и получением всех нужных доступов.
Полноценную интеграцию фичи с дизайном.
Интеграцию с банком, в которой было взаимодействие не только с SDK, но и с интегратором и токен сервис-провайдером.
Интеграцию в конкретный флоу, где после заказа карты в банке пользователь видит предложение добавить эту карту в Google Pay через приложение.
После реализации фичи мы продолжаем развивать приложение.