Когда строить имеет смысл?

Когда платежи — сам продукт и компания планирует продавать платформу, или когда регулятор запрещает любое стороннее ПО в платёжном потоке. Для PSP, эквайера или финтеха, чей продукт — услуга мерчантам, это редкость.

Не привязывает ли нас лицензирование?

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

Можно ли лицензировать и всё же эксплуатировать самим?

Да. Tranzify работает в собственном аккаунте AWS клиента, когда это требуется, с ключами и размещением данных клиента; клиент эксплуатирует, Tranzify поставляет выпуски.

А платформа, которую построит аутсорсинговая команда?

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

Как сравнивать предложения?

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

Сколько стоит лицензия?

Лицензия на ПО или платформенная плата, зависящая от объёма и варианта развёртывания, а не доля с каждой транзакции; модели на странице цен, суммы в договоре.

Строить или покупать платёжный шлюз

Построить платёжный шлюз — это не одна интеграция: это API шлюза, периметр PCI DSS с хранилищем, форма оплаты, маршрутизация, десятки адаптеров провайдеров, которые постоянно меняются, кабинеты для мерчантов и операций, леджер и отчёты, которые просит регулятор. Платёжный бизнес, который строит это сам, тратит год до первого платежа мерчанта и команду навсегда после; тот, кто лицензирует, запускается за недели и тратит инженеров на то, что его отличает.

Что на самом деле входит в «шлюз»

API шлюза и SDK: запросы, подписи, статусы, вебхуки с повторами, песочница.
Периметр PCI DSS: хранилище карточных данных, токены, управление ключами, ежегодный аудит, люди, которые за него отвечают.
Форма оплаты: размещённая страница на языках ваших рынков, 3-D Secure, кошельки, локальные методы, доступность, скорость.
Адаптеры провайдеров: каждый эквайер, агрегатор Open Banking, локальный метод и крипто-провайдер со своим API, колбэками и особенностями, меняющимися ежегодно.
Оркестрация: правила маршрутизации, каскады, лимиты, ограничения, конструктор потоков, которым может пользоваться операционная команда.
Кабинеты: кабинет мерчанта, админка, роли, аудит, инструменты поддержки.
Финансы: балансы, комиссии, резервы, расчёты, сверка с отчётами каждого провайдера.
Соответствие требованиям: журналы и сроки хранения, трассировка платежа, отчёты для регулятора и платёжных систем.

Сколько занимает каждая часть

Часть	Первая версия	Что поддерживает её живой
API шлюза, вебхуки, песочница	3–4 месяца	Версионирование, SDK, документация, поддержка разработчиков мерчантов
Хранилище, токены, периметр PCI DSS	3–4 месяца плюс аудит	Ротация ключей, ежегодная оценка, проверка каждого изменения на соответствие стандарту
Форма оплаты	2–3 месяца	Языки, методы, кошельки, требования PCI DSS v4 к платёжным страницам, изменения браузеров
Адаптеры провайдеров	2–4 недели каждый	Изменения API, новые обязательные поля, отключённые точки, новые провайдеры для новых рынков
Маршрутизация и каскады	2–3 месяца	Правила, которые читает операционная команда; версии, откат, измерение
Кабинеты, роли, аудит	4–6 месяцев	Каждая функция, о которой просят мерчанты; каждый отчёт; каждый язык
Леджер, комиссии, резервы, расчёты	3–4 месяца	Сверка с форматом каждого провайдера; вопросы бухгалтеров
Журналы, трассировка, хранение	1–2 месяца	Хранилище, растущее годами; запросы регулятора

Части пересекаются, но реалистичная первая версия с дюжиной провайдеров — это год полной команды, а второй год уходит на то, что первый отложил.

Цифры, которые имеют значение

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

Что меняет лицензирование

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

Средний путь: лицензировать и эксплуатировать самим

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

Когда всё же строить

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

Чек-лист перед решением

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

Строить или покупать платёжный шлюз: во что обходится собственная платёжная платформа и когда лучше лицензировать