Платформа 4pay.online переходит на новое платёжное ядро. Для клиентов это означает прежде всего одно: отношения с банками и платёжными провайдерами перестают быть их технической проблемой.
Переписывание ядра, через которое идут деньги клиентов, — решение, которое нужно уметь обосновать. Мы обосновывали его четыре года наблюдений за тем, как компании работают с платежами.
Компания, которая принимает платежи, обычно зависит от конкретного эквайера сильнее, чем ей хотелось бы, и узнаёт об этом в самый неподходящий момент. Банк меняет тарифы или требования к обороту. Пересматривает отношение к отрасли и просит уйти в течение месяца. Выходит из строя на несколько часов из-за собственной аварии. Каждый такой случай для продавца означает остановку выручки, а переход к другому партнёру — недели разработки поверх коммерческих переговоров: у нового банка свой формат запросов, свои названия статусов, своя логика возвратов и свой перечень обязательных полей.
Договориться с банком компания в любом случае должна сама — мы техническая платформа, а не платёжный агент, и тарифы, лимиты, комплаенс и ответственность остаются предметом её договора с эквайером. Но техническую часть перехода можно снять полностью, и именно это мы сделали.
Мы видели этот сценарий у клиентов достаточно раз, чтобы понять: проблема не в конкретном банке, а в том, как устроена связь между платформой и провайдером. Пока эта связь вшита в бизнес-логику, любая смена партнёра превращается в проект.
Была и вторая причина, внутренняя. В первом поколении ядра приём платежа и выплата существовали как две разные сущности со своими жизненными циклами. Любое улучшение приходилось делать дважды: отдельно для входящих денег, отдельно для исходящих. Эта двойная плата росла быстрее самой системы, и в какой-то момент стало очевидно, что дешевле переписать, чем продолжать.
Главное изменение нового ядра — в том, как платформа общается с внешним миром.
Каждый банк и платёжный провайдер подключается отдельным модулем с фиксированным набором обязанностей: провести платёж, вернуть деньги, отменить операцию, сообщить статус. Ядро не знает, с каким именно банком оно работает в конкретный момент, а наружу платформа отдаёт один и тот же набор операций и статусов независимо от того, кто обслуживает поток.
Практических следствий три.
Смена эквайера перестала быть проектом на стороне клиента. Договор с новым банком продавец заключает сам, а вот переключение маршрута выполняется в платформе: интеграция продавца остаётся прежней — те же запросы, те же названия статусов, те же уведомления. Работы для его команды разработки при этом не возникает.
Подключить второго провайдера теперь имеет смысл заранее, а не в момент кризиса. Раньше вторая интеграция стоила столько же, сколько первая, и компании откладывали её до последнего — обычно до дня, когда первый банк уже отключился. Теперь резервный маршрут заводится заблаговременно, а поток между провайдерами распределяется по правилам: по типу карты, по стране покупателя, по сумме, по доле трафика.
Появилась возможность выбирать провайдера под задачу, а не под интеграцию. Если по одному направлению банк даёт лучшую цену, а по другому выше доля одобрений, разумно использовать обоих — в отрасли такие решения обычно не окупаются из-за стоимости каждого подключения. У наших клиентов вопрос теперь сводится к переговорам об условиях, а не к бюджету на разработку.
Второе изменение внутреннее, но его следствия видны в отчётности.
Теперь входящие и исходящие деньги описаны одной моделью операции с общим набором состояний. Журнал, повторные попытки, уведомления и бухгалтерские проводки написаны один раз и работают одинаково в обе стороны.
Для финансовой службы это означает, что сверка ведётся в одном месте, а не по двум отчётам с разной логикой, и вопрос «сколько всего прошло через платформу за месяц» имеет один ответ, а не два, которые нужно складывать вручную. Для операционной команды — что сотрудник, умеющий разбирать входящий платёж, умеет разбирать и выплату: инструмент и порядок действий общие.
Третье изменение почувствуют те, кто хоть раз переживал зависание провайдера в пиковый час.
Каждая операция в новом ядре обрабатывается независимо, со своим предельным временем ожидания и своими правилами повторных попыток. Медленный ответ одного банка больше не тормозит остальной поток: платежи через других провайдеров идут в обычном темпе, а зависшие операции разбираются отдельно.
Раньше такие инциденты замечали все клиенты сразу, и объяснять их приходилось каждому. Теперь проблема одного банка остаётся проблемой одного направления.
Продавцу с одним эквайером новое ядро даёт возможность не оказаться в заложниках у единственного партнёра: резервный маршрут подключается заранее и включается в тот момент, когда это нужно.
Компании, которая продаёт в нескольких странах, оно даёт единый интерфейс поверх разных локальных банков. Расширение на новый рынок не превращается в новую интеграцию: добавляется маршрут, а не система.
Платёжному сервису, который работает на нашей платформе под собственным брендом, важнее всего скорость подключения провайдера. Теперь она измеряется неделями, а не месяцами, и переговоры с новым банком можно вести, называя реалистичный срок запуска.
Действующие клиенты переходят на новое ядро незаметно: интерфейс и статусы не меняются, миграция идёт на нашей стороне. Новые подключения с этого месяца идут сразу на второе поколение.
Ближайшие планы связаны с географией. Появление сменных модулей делает осмысленным выход на рынки, где раньше интеграция не окупалась, и в ближайшие месяцы мы рассчитываем рассказать о первых запусках за пределами привычных для платформы направлений.
«Клиент платит не за то, как устроено наше ядро, а за то, что его бизнес не останавливается, когда у банка изменились правила. Переписывали мы его ровно ради этого», — Михаил Спиридонов, директор «Два ПиЭр».
Продукт: 4pay.online