Кейс: как сделать платежный шлюз с 50+ платежных систем, 3 000 транзакций в минуту

Любая компания, которая принимает оплату через интернет или позволяет клиентам пополнять счет внутри сервиса, сталкивается с проблемой приема платежей. Решение уже есть — можно подключиться к поставщику платежных сервисов, который возьмет на себя эту задачу. Если у вас не так много транзакций и ограничен набор способов оплаты (например, только банковские карты), то настроить работу довольно просто. Сложности начинаются, когда сервис масштабируется — растет количество транзакций, способов оплаты, нужно получать платежи из других стран. Чем больше масштаб, тем больше появляется нюансов и задач, которые надо решать и которые могут быть не очевидны на первый взгляд. Мы решили собрать в одном месте все вызовы, с которыми нам пришлось справиться при создании платежного шлюза.

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

К сожалению, нельзя одной строчкой кода подключиться к API процессингового сервиса. Обычно это непростое API с различными методами обмена информации: прошел платеж или нет, дошли деньги или нет, есть ли разрыв связи и так далее. И все нюансы нужно учитывать: нам же требуется стабильное решение по транспортировке денег. Насколько сложно подключить процессинговый сервис? Без нужного опыта сложно учесть все нюансы, которые могут возникнуть при подключении. Даже у опытной команды разработчиков это может занять две-три недели.

Вызов второй — платежи из других стран и дополнительные способы оплаты (электронные кошельки, вроде «Яндекс.Денег» или WebMoney, подарочные ваучеры и так далее). Разные банки и платежные системы берут разные комиссии. И управляя тем, через какой банк проходит платеж, можно управлять размером комиссии. То есть ведя клиента разными путями, вы можете варьировать комиссию, например, от 2% и 10%. Естественно, что клиент будет рад меньшей комиссии. Здесь приходится использовать маршрутизацию платежей. В части выбора банков эту функции частично берет на себя процессинговый сервис. Но, например, один сервис лучше работает с российскими банками, другой с зарубежными, третий с определенным типом платежных систем. На этом этапе приходится подключать несколько сервисов, и уже на стороне компании выбирать, через какой процессинг проводить платеж. При работе с разными юрисдикциями есть и другие нюансы. Например, в разных странах предпочитают разные способы оплаты: в Турции очень популярны скретч-карты, а на Кипре не любят вводить свою карту и платят через сторонние сервисы.

Мы решали проблему маршрутизации с помощью «прослойки», которая определяла, из какой страны клиент. Так мы могли подобрать для него наилучший по условиям вариант процессинга, с меньшей комиссией. При этом компании не всегда выгоден вариант с наименьшей комиссией для клиента. Например, провести оплату с помощью условно электронных денег можно либо напрямую через платежную систему, либо через работающей с ней процессинг, но с большей комиссией. И тогда приходится решать, через какой способ провести оплату надежнее в данный момент. Конечная цель — сохранить наибольшую надежность и пропускную способность, но при этом и удобство для пользователей.

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

Когда стоит задумываться о маршрутизации? Вряд ли она нужна небольшому интернет-магазину, у которого нет огромного потока заказов. Но если объем транзакций идет на десятки или даже сотни миллионов долларов, а потери на комиссиях становятся ощутимыми, то уже можно вводить такую систему. При этом если изначально есть понимание, что через ваш сервис будет проходить большой объем средств — например, вы делаете новый Ozon или Wildberries , то можно сразу закладывать такой функционал.

Вызов третий — кто хранит данные. Комиссия еще зависит от того, на чьей стороне хранятся данные о банковских картах клиентов. Система, которая хранит эти данные, должна быть сертифицирована по стандарту PCI DSS. Если такой сертификации нет, то можно получить штраф от Visa или Mastercard, или они могут даже отключить вас. Можно доверить хранение данных платежной системе, которая возьмет за это дополнительную комиссию. Для сервисов с небольшим объемом транзакций это имеет смысл, поскольку сертификация довольно затратный процесс. Но как только объем комиссий превышает бюджет на сертификацию, то стоит задумываться уже о собственной системе хранения.

Вызов четвертый — отказоустойчивость и скорость работы. Когда клиент вводит данные своей карты и нажимает кнопку «Оплатить», то «под капотом» происходит множество операций. Если кратко, то процессинговый сервис делает запрос в банк, банк отвечает, мы делаем запрос сервису, он отвечает нам, потом мы говорим системе обновить счет, система обновляет, еще нужно отправить смску пользователю. Такой объем операций, а для клиента в идеале должно пройти меньше секунды. Нажал кнопку, оплатил, проверил счет, а он уже обновился. А теперь представьте, что таких транзакций проходит 30 000 в минуту — это огромный объем информации.

Вызов пятый — система мониторинга для повышения надежности. Все процессинговые сервисы и платежные системы работают по-разному, у всех разные API. Когда вы строите крупный платежный шлюз, то это как будто вы берете разные розетки, делаете под каждую из них свою вилку, а потом сводите все в один кабель. Инженерно это довольно сложный процесс. И каждая из этих «розеток» может отказать, поэтому важно мониторить каждый подключенный сервис, чтобы быстро среагировать в случае его отказа. Если по одному из направлений наблюдается резкое сокращение транзакций, то нужно тут же связаться с этим сервисом и узнать причины, а одновременно с этим переключить клиентов на другой сервис. Или у вас возрастает количество заказов одного типа, и вы понимаете, что один процессор не выдержит. Тогда можно, например, каждого десятого клиента переключать на другой сервис.

Для этого есть система маршрутизации процессов с различными настройками, которые позволяют управлять платежными системами. Главное, что все должно работать автоматически. У вас идет поток транзакций, который нельзя останавливать. Если остановите, то потеряете деньги и клиентов. Система маршрутизации позволяет еще и балансировать запросы на сервера компании. Архитектура должна выдерживать объем, нагрузка должна распределяться.

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

Вызов седьмой — выплаты клиентам. Ряду сервисов нужно не только принимать платежи клиентов, но и делать выплаты — например, кэшбек за покупки. Это отдельная часть платежного шлюза, и она фундаментально отличается от приема платежей как по работе с API платежных систем, так и по реализации процесса. Для проекта платежного шлюза мы создали интеллектуальную систему автовыплат и автоподтверждения, которая помогает определять, можно ли сделать выплату или нет. Дело в том, что перед выплатой клиента необходимо проверить на его благонадежность по целому ряду параметров — не пытается ли он обмануть сервис, не отмывает ли деньги и так далее. То есть нужно реализовать антифрод-систему. Автоматизация процесса позволяет сократить количество персонала.

Антон Новоженин

Эксперт по разработке ИТ-продуктов

Забронировать звонок с экспертом

Вызов восьмой — дублирование выплат или начислений. Еще ряд подводных камней. Например, как избегать двойных выплат и начислений. Выплата может не пройти с первого раза, и платежная система вернет ошибку о переводе. При этом может оказаться так, что и платежная система вернет деньги клиенту, и сам сервис разблокирует сумму, которую поставил на холд для выплаты. У каких-то платежных систем есть защита от двойных платежей, у других нет. Для этого нужно понимать логику работы протокола каждой системы, чтобы избегать таких ошибок. При этом некоторые платежные системы, которые можно использовать для ввода средств, не позволяют их выводить.

В итоге, мы сделали из платежного шлюза серверное приложение, которое завернули в API и потом отдавали командам — для веб-версии сервиса, для мобильных приложений. Они просто подключались к API, отправляли запросы и могли пользоваться всеми платежными сервисами. Получилось готовое решение для всех команд разработки внутри корпоративного контура. Система постоянно улучшается.

Можно ли использовать готовое решение? Если объем транзакций небольшой, то, вероятно, можно подключить один процессинговый сервис с минимальными усилиями. Но наш опыт показывает, что если речь идет о растущем объеме транзакций, числе юрисдикций, откуда совершаются платежи, меняющихся потребительских предпочтениях, то приходится брать готовые решения и адаптировать их под себя. При этом сделать проект за пару месяцев, предусмотрев все нюансы, не получится. С ростом объемов возникают все новые вызовы и задачи, которые приходится решать. И хорошо, если у команды, которая занимается подобным проектом в вашей компании, есть богатый опыт. Финансовое взаимодействие с клиентом — одна из самых важных частей любого бизнеса. И ошибки разработчиков могут привести к потерям и негативу со стороны клиентов.