Новая финтех-компания и процессинговый центр Paygine была зарегистрирована в марте 2022 года, а уже в сентябре она продемонстрировала принципиально новый подход на рынке платёжных сервисов, выпустив уникальный продукт Method, который, по мнению ряда экспертов, может стать хитом в b2c.  Роман ТИХОНОВ, Chief Product Officer бренда Paygine, в интервью главному редактору Национального банковского журнала Станиславу КОМАРОВУ помогает разбираться в тонкостях бесконтактной оплаты в текущих непростых условиях, анализирует возможности Method и объясняет, почему в российской ИТ-отрасли осталось так мало создателей и архитекторов новых платформ и систем.

NBJ: Что происходит на рынке бесконтактных платежей в связи с уходом Apple Pay, Google Pay, Visa, Mastercard? Как я понимаю, огромное количество пользователей оказались к этому попросту не готовы…

Р. ТИХОНОВ: Вы правы. Пользователи столкнулись с серьёзным вызовом к их паттерну платить телефоном и делать оплату в два клика. У себя в Paygine мы это быстро заметили в мониторинге платёжных операций клиентов. Они стали не так охотно совершать импульсные покупки, потому что не могли сделать быструю оплату.

К примеру, эта проблема очень сильно коснулась рынка чаевых. Там всегда было простое действие: открываешь QR-код и через Apple или Google Pay платишь. 90% платежей уходило в Pay. После ухода западных платёжных сервисов пользователям стало довольно сложно оставлять чаевые таким образом. В первую очередь это было связано со сложностями при запоминании карты или её ручным вводом.

NBJ: И в Paygine начали искать решение? 

Р. ТИХОНОВ: Изначально мы задумались над тем, что можем сделать. В этот момент на рынке стало появляться большое количество разных Pays от известных и менее известных банков, которые стали представлять свои технологичные решения. Они заключаются в том, что, нажимая на кнопку «оплатить», клиент попадает в приложение банка. По такому же принципу работает и Система быстрых платежей (СБП). Пользователь выбирает в ней нужный банк и переходит в приложение этого банка. Рынок сейчас насыщен рекламой СБП как более дешёвым методом оплаты. Но для пользователя это не очень выгодное решение, как если бы он платил пластиковой картой, либо оплачивал через Pay своего банка, потому что он лишается кэшбэков и бонусов от своего банка.

Таким образом, на рынке сложился набор из разных платёжных конструкций. Оплата пластиковой картой – привычно, но долго и неудобно. Есть разные Pays банков или СБП, но нужно быть клиентом этой кредитной организации и как-то интегрировать его себе на страницу. Плюс возникла новая проблема: приложения некоторых банков начали удалять из Stores, и переход в приложение конкретного банка становился невозможен. Для пользователя этот способ оплаты исчез и стал неактуальным.

Мы выложили на стол перечень этих проблем и подумали, что можем сделать. Первое, что нам пришло в голову, сделать свой собственный Pay. Проделали большой путь, чтобы разобраться, как это работает. Поняли, что должны стать неким токен-хранилищем, которое собирает карты любых банков и выдаёт токены в случае оплаты.

При этом мы понимали, что наш Pay становится одним среди многих, и его тоже надо интегрировать, что сразу же делало его достаточно громоздким решением. Тем не менее, работа над созданием этой платформы подарила нам большое количество возможностей с точки зрения сохранения авторизации пользователя. Мы научились распознавать его по непрямым метаданным, по номеру телефона. С этим на рынке тоже имеются сложности. Например, компания Apple регламентирует срок хранения таких данных в сервисах семью днями. Если вы не пользовались сервисом больше недели, то данные о пользователе «сгорают». Для нас это тоже стало определённым вызовом. С ним мы справились, создав продукт, который назвали GinPay. Мы старались завуалировать слово Рay, потому что сейчас всё что угодно стало Рay.

Продукт получился чисто для b2b. В нём мы научились сохранять карты и достаточно долго хранить данные о них. При этом качественно и правильно обновлять их в кросс функциональных процессах. Далее мы пошли на создание отдельной изолированной команды разработчиков для того, чтобы перевести наш новый продукт из b2b-поля в b2c. Это мой давний гештальт, всегда очень хотел работать с продуктом b2c.

Этой команде мы дали API, часть своих технологий и поставили пред собой цель сделать платёжный сервис, который поддерживает привычку человека платить телефоном. Мы стали исходить из тезиса: «Сделаем что-то простое, понятное и живое, если у тебя нет карты, а надо быстро оплатить». И у нас получился абсолютно новый продукт. Мы очень долго искали ему имя, в итоге назвали его Method – это часто применимый термин в программировании.

NBJ: В чем суть Method?

Р. ТИХОНОВ: Первый важный его компонент мы называем delivery, он заключается в том, что мы даём возможность большим количеством способов доставить до плательщика наш Method. Это могут быть QR-коды, а они, как известно, тоже бывают разные: статические, динамические и кассовые. Все они – это своего рода ссылки. Пользователь должен этот QR-код отсканировать, и у него откроется наша страничка, некая форма  wallet’a, в котором ему будет предложено оплатить через СБП, добавить свою карту или использовать любую удобную для него платежную опцию (Pays разных банков). Всё, бинго!

NBJ: Приведите пример. Предположим, я стою на кассе и мне надо быстро оплатить покупки. Мои действия, если я решу использовать ваш Method?

Р. ТИХОНОВ: Вы можете выбрать для оплаты СБП или другой доступный способ оплаты. Мы сохраняем любые карты, и мы будем долго вас помнить, потому что научились довольно длительное время сохранять ваши данные. В следующий раз, когда вы придёте в Method, он покажет ваш любимый способ оплаты первым. Если вы, например, платите через СБП в Райффайзенбанк, то сразу увидите своё приложение СБП Райф. По каждому пользователю Method будут собираться необходимые данные для того, чтобы выдавать ему максимально удобный способ оплаты. В чём проблема карт – ушли Pays, в чём проблема СБП – нет бонусов. Есть люди лояльные и к СБП, им бонусы не нужны, а есть и те, кому важен кэшбэк.

Каждый пользователь найдёт для себя в Method удобный способ, который его не триггерит и выполняет текущие платёжные задачи. Понятно, что впоследствии в Method будет предложено и кредитование, и кредитный лимит, и автоматическое дополнение карт из разных банков. Получается некое пространство, в котором можно гибче работать с пользователем, и этот продукт достаточно далёк от идеи Pay, как таковой.

NBJ: Про полезность Method для «физиков» вы рассказали, а чем он может быть интересен бизнесу?

Р. ТИХОНОВ: Отмечу минимальную затратность структурных решений для его использования. Бизнесу становится не нужен платёжный терминал, отпадает необходимость печатать чеки. В систему вводится e-mail, он сохраняется, и на него всегда будут приходить чеки. Или знакомое всем офлайн-решение: к вам приезжает курьер, надо провести оплату. Ему уже не нужно будет возить с собой терминал. Потому что у него есть QR-код, который уже сгенерирован или распечатан на накладной.

Приведу пример оплаты в большом сетевом магазине по продаже электроники. Товар выбран, покупателю печатают накладную, он идет на кассу, чтобы совершить покупку. С нашим Method на кассу ходить не обязательно. Сканируешь QR-код и оплачиваешь. Касса вообще становится не нужна! Аналогичная ситуация и с рядом других офлайновых решений. Пользователь всегда попадает в одно и то же окно, которое ему знакомо, и в нём он производит оплату. Method очень отдалённо напоминает такие популярные азиатские решения, как WeChat или Alipay. Но, тем не менее, на российском рынке такого продукта нет, и очевидно, что он его может «съесть».

Не зря я в начале интервью упомянул кейс про чаевые. Для бизнеса мы сделали такой простой личный кабинет, где ничего особо делать-то и не надо. Зайти, зарегистрироваться, получить QR-код. И прямо оттуда выставлять счета и получать платежи. При этом даже можно быть самозанятым.

NBJ: Немного сменим тему. Создавая Method, вы не столкнулись с проблемой нехватки или утечки ИТ-кадров? Об этом очень много говорится в последнее время. 

Р. ТИХОНОВ: Изложу свой взгляд на проблему «исхода программистов». Возможно, это не самый популярный, но, по крайней мере, честный ответ относительно очень многих ИТ-структур. В связи с СВО моё мнение на этот счёт не поменялось. Мои личные наблюдения касаются как больших, так и маленьких компаний. Всегда в них присутствуют какие-то люди, вокруг которых строится вся обвязка. Понятно: чем больше этой обвязки, тем больше функций демпфера она выполняет, если вдруг человека оттуда изъять. Но у идеолога и основной движущей силы, как правило, есть имя. Это не обязательно один специалист, могут быть несколько персоналий. Например, у нас достаточно большой штат ИТ, понятно, что я чаще общаюсь с Team Lead (руководителями разработки) и прекрасно понимаю, что у нас есть один человек, который занимается архитектурой системы. Их не может быть два, потому что это идеология одного человека.

Есть такая фраза: «Можно заменить абсолютно всех сотрудников, но нельзя заменить создателя». В целом это применимо к тем людям, которые занимались разработкой Method. В чём их сила помимо талантов создателей? Как правило, это люди с возможностью принятия собственных рискованных решений, которые ведут к созданию уникального продукта. Успех без риска невозможен!

К сожалению, на рынке происходит измельчание кадров. Сейчас найти менеджера, который готов принять сложное ответственное решение, непросто. И такой человек зачастую стоит намного больше, чем его знания. Впрочем, случается и обратная ситуация, есть слишком самоуверенные люди, которые принимают слишком самоуверенные решения.

Тем не менее, от модного сейчас подхода в создании продуктов, когда собирается команда, все в ней имеют одинаковое мнение и несут коллективную ответственность, на мой взгляд, мало толку. Зачастую люди из таких команд, попав в сложную ситуацию неопределённости, делают самый простой выбор: уходят в другую команду, которая находится в более стабильной обстановке. По сути, это паразитирующая позиция.

NBJ: Вы ведёте к тому, что архитекторов и создателей систем осталось мало…

Р. ТИХОНОВ: Про кадры – важная ремарка, архитекторов было и есть мало. «Рабочие лошадки», как правило, это начинающие программисты, у которых пока ещё нет большого опыта, они работают масштабно и быстро. Более опытные делают свою работу более вдумчиво и качественно. Тут важно соблюдать баланс между time to market и качеством решений. Это как раз основная задача тех самых архитекторов.

Что же касается будущего российского финтеха, то наш сегмент со всеми проблемами справится. Наша страна исторически здесь одна из первых! И тут однозначно ничего страшного не случится. 

Беседовал: Станислав Комаров

Материал также опубликован в печатной версии Национального банковского журнала (сентябрь 2022)