Pull to refresh

Опыт внедрения сервиса мобильных платежей Apple Pay в банке

Reading time 4 min
Views 4.2K
В этой статье мы бы хотели поделиться своим практическим опытом внедрение сервиса мобильных платежей Apple Pay, какие проектные подходы мы использовали при решении этой непростой задачи, и какие моменты нужно учесть, если вы планируете внедрение этого сервиса у себя.

Не будем далее сильно вдаваться в технические детали внедрения (по этому поводу чуть позже выйдет отдельная статья), но если на пальцах, то вся инфраструктура Apple Pay состоит из следующих компонент, которые будет необходимо друг с другом подружить:

1. Платформа выпуска и управления жизненным циклом токена (виртуального «псевдо» номера карты) на стороне платежной системы. У MasterCard она называется Mastercard Digital Enablement Service (или MDES), у VISA — Digital Enablement Program (или VDEP)
2. Ваша карточная процессинговая система
3. Приложение мобильного банка
4. Сервис шифрования, необходимый для передачи данных в Apple и Платежную систему при привязке карты через мобильный банк (в терминологии Apple это называется In-app provisioning)

Если п.1 является коробочным решением и уже разработан (потребуется только небольшая настройка под ваши карточные продукты и специфику), по п.2 вендоры процессинговых решений (например OpenWay) предлагают частично или уже полностью реализованные доработки, то вот п.4 — сервис шифрования придется разрабатывать с нуля. Отнеситесь к планированию и реализации этой компоненты очень внимательно, так как у нас на ее отладку ушло больше всего времени и сил).

С одной стороны задача выглядит как классический проект (есть фиксированный срок запуска, понятен конечный результат), поэтому вооружайся water fall’ом и вперед, но с другой стороны очень важна скорость внедрения, качество (почему это важно, расскажем в конце статьи), и тот факт, что наш Банк сейчас повсеместно переходит на agile фрейм-ворки разработки (в частности, на Scrum). В итоге получился гибридный подход, не претендующий на идеальность, но подошедший нашей команде в период agile-трансформации:

• За точку отсчета был взят проектный план MasterCard и VISA (от этого никуда не уйти, у компаний свои стандартные процедуры ведения проектов, по которым работают они сами и взаимодействуют с внешним миром)

• План был дополнен внутренними работами (Процедуры бюджетирования и заключения договоров, разработкой архитектуры, утверждением решения с Информационной безопасность, доработкой внутренних систем, тестированиями, сертификацией и т.д.), а даты завершения проставлены таким образом, чтобы выйти на желаемую дату запуска (с запасом в 2 недели, конечно же). На основе этого плана была выявлена потребность в участниках проектной команды, и сформирована эта временная команда

• Далее мы распланировали регулярные конфколлы со всей командой (раз в неделю в начале проекта, 2 раза в неделю в середине, и каждый день по 15 минут на финальной стадии перед запуском), где брали текущие и будущие задачи из большого проектного плана, били их на под-задачи, назначали ответственных, рассылали на всех этот мини-план (он же протокол встречи) и работали по нему до следующего конфколла.

• Если проектный план «ехал» по датам, мы сразу же смело его меняли, чтобы он соответствовал действительности, и не делали из этого трагедию

• Как только тот или ной компонент был полностью готов и оттестирован, выводили его на боевую среду, и уже после вывода на бой какое-то время тестировали работу сервиса на закрытой группе реальных пользователей (все это были сотрудники банка)

• И так, маленькими шажками двигались к цели.

Если внимательно присмотреться, то можно увидеть некоторые аналогии с событиями и артефактами Scrum:

• Проектный план + спецификации Apple и платежных систем – это бэклог
• Декомпозиция проектного плана на под-задачи для работы до следующего еженедельного конфколла – это PBR и планирование спринта, длительностью в неделю
• Ежедневные конфколлы – daily scrum

Но были и отклонения от фрейм-ворка, в частности мы не делали ретроспективы, тестировали не в конце каждого спринта, а когда уже большая часть компонент была разработана и интегрирована на тестовой среде, и у нас не было демо.
Что интересно, данный подход именно «родился» по ходу работы, а не был спроектирован заранее, т.е. подстраивался под подробности команды. Надеемся, что эта история вдохновит Вас к экспериментам в области управления проектами, и более гибкому подходу для достижения целей.

Почему так важно внедрять Apple Pay очень качественно? Дело в том, перед запуском в коммерческую эксплуатацию вам придется пройти обязательное независимое тестирование (сертификацию) вашего решения, развернутого на бою, в одной из 3-х тестовых лабораторий, авторизированных Apple. И это будет непросто, дело в том, что лаборатории очень скрупулёзно подходят к тестированию (обычно оно занимает порядка 2х недель).

Например, будут проверены абсолютно все ваши дизайны карт на соответствие физического пластика и картинки в кошельке (причем, если расходится дизайн логотипа или цвет шрифта плохо читается на экране телефона, вас попросят эти недостатки срочно устранить), будут проверены все возможные сценарии использования, на всех поддерживаемых устройствах (включая IPad Pro 12” )), внимательно вычитаны Terms & Conditions (нас например, просили исправить в некоторых местах знаки препинания). В общем, Apple и партнеры относятся к выпуску продуктов очень внимательно, закрыть глаза на шероховатости не получится, и к этому нужно быть готовым заранее.

Итак, работы все выполнены, тестирование и сертификация пройдены, а решение запущено. Что мы имеем в остатке:

1. Выполненный проект;
2. Интересный опыт и необычный подход к решению проекта;
3. Несколько подразделений в компании, которые приняли практики, использованные на проекте и продолжают использовать подход к решению различных задач и проектов.

В следующей статье мы постараемся рассказать больше технических деталей и особенностей, с которыми вы столкнулись в ходе внедрения Apple Pay, а пока можете задавать вопросы в комментариях.

Кузин Сергей, scrum-мастер банка «Открытие»
Tags:
Hubs:
-7
Comments 5
Comments Comments 5

Articles

Information

Website
www.open.ru
Registered
Founded
1993
Employees
over 10,000 employees
Location
Россия