Практическое руководство по запуску платежного сервис-провайдера: выбор модели, договор с эквайером, лицензирование, PCI DSS, выбор платформы, статьи затрат и план запуска в 9 шагов.
Под индивидуальными платежными решениями понимают платежную инфраструктуру, в которой оператор адаптирует коннекторы, платежную страницу, маршрутизацию, отчеты или логику выплат платформы под свой бизнес, а не использует ее в стандартном виде. Это руководство для PSP, банков и платформ, которые решают, что доработать в White-Label платежном шлюзе.
Индивидуальное платежное решение представляет собой платежный стек, выстроенный вокруг ваших мерчантов, рынков и денежных потоков. Для оператора это редко означает написание шлюза с нуля. Обычно берут готовую платформу и меняют то, к чему она подключена, как выглядит и что делает с каждым платежом. О том, как выбрать такую платформу, мы писали в статье «Как выбрать платформу для онлайн-платежей».
Кастомизация бывает трех уровней, и у каждого свой ответственный и свои факторы стоимости:
Вы меняете параметры, которые платформа уже предоставляет: правила маршрутизации, комиссии, лимиты, брендинг и вид отчетов. Это делает ваша команда в бэк-офисе.
Вендор дорабатывает свою платформу под вас: коннектор к новому эквайеру, локальный метод оплаты или новый сценарий. Вы пишете требования и принимаете результат.
Вы сами разрабатываете и эксплуатируете процессинговое ядро. Все функции ваши, но и сертификация, аудиты безопасности и поддержка тоже.
Модульная платежная платформа удерживает большинство задач на уровнях 1 и 2: модули маршрутизации, рисков, выплат и отчетности уже есть, их нужно только включить или расширить.
Выбор между тремя уровнями такой же, как и при выборе ПО для обработки платежей: сколько вы хотите контролировать сами и как быстро нужно запуститься.
Готовый продукт подходит, если стандартных возможностей хватает вашим мерчантам. Полная собственная разработка оправдана, если платежные технологии являются вашим продуктом и вы готовы финансировать годы работы. White-Label с доработками находится посередине: вы арендуете работающую платформу под своим брендом и заказываете расширения только там, где ваш бизнес отличается.
| Критерий | Готовый продукт как есть | White-Label с доработками | Собственная разработка |
|---|---|---|---|
| Кому принадлежит код | Вендору | Вендору; вам принадлежат настройки и ваши данные | Вам |
| Чей бренд видят мерчанты | Вендора или смешанный | Ваш: платежные страницы, бэк-офис, домен | Ваш |
| Новый эквайер или метод | Только из списка вендора | Из списка или разработка по запросу | Каждый разрабатывают ваши программисты |
| PCI DSS | Вендор сертифицирует платформу | Вендор сертифицирует платформу; вы сертифицируете свою среду | Вы сертифицируете все |
| Срок запуска | Самый быстрый | У eComCharge: от 1 недели в формате SaaS или от 3 месяцев на ваших серверах | От 12 месяцев до 2 лет до готового к эксплуатации шлюза (наша оценка) |
| Кому подходит | Мало мерчантов, стандартные задачи | PSP, банкам и платформам со своими эквайерами и сценариями | Тем, для кого платежные технологии являются основным продуктом |
Модель развертывания определяет, насколько глубоко можно зайти. Процессинг в формате SaaS использует одну кодовую базу для всех клиентов, поэтому доработка делается как функция, которую поддерживает вендор. Шлюз on-premises работает на ваших серверах и дает вашей команде прямой контроль над системой.
Чтобы сравнить варианты в деньгах, посчитайте совокупную стоимость владения за три года «построить или купить» с вашими зарплатами, затратами на аудит и объемами. Подробнее о том, из чего складывается экономика, читайте в руководстве о бизнес-модели платежного шлюза.
Настраивать можно семь областей: коннекторы, методы оплаты, платежную страницу, маршрутизацию, комиссии, бэк-офис с отчетами и логику выплат. В таблице для каждой области показано, что настраивает ваша команда, а что разрабатывает вендор.
| Область | Настройка (ваша команда, без кода) | Разработка (вендор, по запросу) |
|---|---|---|
| Коннекторы к эквайерам | Включить коннектор, который уже есть в платформе | Коннектор к эквайеру или банку, которого нет в списке |
| Методы оплаты | Включить метод для мерчанта или магазина | Локальный метод, новый для платформы |
| Платежная страница | Логотип, цвета, шрифты, текст кнопки, языки | Новый сценарий страницы или поля, которые она не поддерживает |
| Маршрутизация | Правила, порядок резервных маршрутов и веса трафика | Новый параметр, который движок не учитывает |
| Комиссии и лимиты | Фиксированные и процентные комиссии по типам транзакций, лимиты по мерчантам | Модель комиссий, которую биллинг не может описать |
| Бэк-офис и отчеты | Шаблоны отчетов, дашборды, роли пользователей, оформление интерфейса | Выгрузка или формат отчета для конкретной системы |
| Выплаты и сплиты | Правила выплат и получатели | Новый для платформы сценарий расчетов |
Попросите вендора разнести ваши требования по этим двум колонкам до любой оценки. Задача из первой колонки стоит вам только времени на настройку. Со второй колонки начинаются вопросы объема, тестирования и поддержки, им посвящена остальная часть руководства.
Если вы развиваете программную платформу, которая добавляет платежи для своих пользователей, в руководстве о SaaS платежной платформе показано, какие из этих областей важны для встроенных платежей.
Коннектор создается в пять этапов: вы заключаете договор с эквайером, эквайер передает спецификацию интеграции и тестовый доступ, вендор разрабатывает, эквайер сертифицирует, и вы включаете трафик. Дольше всего часто ждут не код, а очередь на сертификацию у эквайера.
Вы согласуете договор, платежные системы, валюты и категории мерчантов. Эквайер проводит андеррайтинг и выдает идентификаторы мерчантов (MID).
Эквайер предоставляет спецификацию API или host-to-host, тестовые учетные данные и тестовую среду. Сразу запросите форматы сообщений для возвратов, отмен и 3-D Secure (3DS).
Вендор сопоставляет сообщения эквайера со своими типами транзакций и кодами ответов, включая возвраты и аутентификацию через 3DS Server.
Эквайер прогоняет свои тест-кейсы на коннекторе и допускает его к боевому трафику. Забронируйте этот слот заранее.
Вы добавляете коннектор в правила маршрутизации, начинаете с доли одного сегмента и сравниваете результаты, прежде чем переводить больше объема.
Второй эквайер редко бывает техническая прихоть. Это основа мульти-эквайринговой стратегии, которая позволяет продолжать процессинг, когда один банк вас отключает. Планируйте коннектор до того, как он понадобится.
eComCharge разрабатывает новые коннекторы к банкам и методам оплаты по запросу и, как правило, выполняет не менее 6 новых интеграций в месяц по заказам клиентов своего White-Label шлюза.
Платежную страницу можно изменить настолько, насколько позволяет тип интеграции, и он же определяет область PCI DSS ваших мерчантов. Хостинговая платежная страница или виджет позволяют менять брендинг, а данные карты остаются у шлюза. Прямой API дает полный контроль над страницей, но переносит данные карты в системы мерчанта.
| Интеграция | Что можно изменить | Кто обрабатывает данные карты |
|---|---|---|
| Хостинговая платежная страница | Логотип, цвета, шрифты, языки, отображаемые методы оплаты | Шлюз; мерчант перенаправляет покупателя |
| Платежный виджет | То же, что на хостинговой странице, но на сайте мерчанта | Шлюз, внутри виджета |
| Мобильные SDK | Экран оплаты в приложении | SDK и шлюз |
| Прямой API | Все на странице | Собственные системы мерчанта, что расширяет его область PCI DSS |
В eComCharge мерчант может настраивать платежный виджет в каждом запросе на транзакцию: шрифт, цвет и размер шрифта, цвет фона и текст на кнопке оплаты. Хостинговая платежная страница предлагает те же функции и внешний вид, что и виджет.
Для приложений платформа предоставляет мобильные SDK для iOS и Android.
Совет по стандартам безопасности PCI (PCI SSC) описывает анкету самооценки SAQ A как анкету для мерчантов, у которых функции работы с данными счета полностью переданы проверенным третьим сторонам. С 31 марта 2025 года такой мерчант должен также подтвердить, что его сайт не уязвим для атак через скрипты. Требования 6.4.3 и 11.6.1 PCI DSS v4.0.1 обязывают авторизовать скрипты платежной страницы, проверять их целостность и отслеживать изменения.
Сохраненные карты требуют того же внимания. Токенизация карт в шлюзе позволяет собственной платежной странице предлагать сохраненные карты, не храня номера карт у мерчанта.
Правила, резервные маршруты, веса, комиссии по типам транзакций, шаблоны отчетов и оформление относятся к изменениям первого уровня. Если вендор оценивает одно из них как разработку, спросите, какой настройки не хватает в его платформе: разработка начинается с нового параметра маршрутизации, модели комиссий или формата выгрузки.
В Smart Routing eComCharge можно комбинировать более 50 условий (BIN, страну, валюту, сумму) с последовательным резервированием и распределением трафика по весам между подключениями. Правила задаются на уровне PSP, мерчанта или магазина, и правило верхнего уровня действует на все уровни ниже.
Правила действий превращают рутинные проверки в автоматические уведомления, черные списки и лимиты, и вашей риск-команде больше не нужно повторять их вручную.
Фиксированные и процентные комиссии задаются для каждого типа транзакций. Иерархия PSP, мерчантов и магазинов входит в управления мерчантами, с ролями и правами для каждого уровня.
Аналитика FinStatHub дает каждому пользователю конструктор отчетов, сохраненные поиски и более 10 типов виджетов. Бэк-офис PSP поддерживает 31 параметр оформления, включая цвет и шрифт.
Когда отчет должен поступать в другую систему, например в вашу учетную систему или ERP, Report API отдает нужные срезы данных. Спросите о нем до того, как заказывать кастомную выгрузку: вызов API, который пишут ваши разработчики, проще изменить, чем формат файла, который поддерживает вендор.
Дорабатывайте логику выплат и сплитов только после того, как решен вопрос лицензирования: она перемещает деньги, которые принадлежат другим. Эта логика определяет, кто получает какую долю платежа, когда и каким способом.
До того как писать требования, зафиксируйте четыре факта. На чей счет эквайер перечисляет возмещение? Кто рассчитывает долю и комиссии каждой стороны? Кто отправляет выплату: на карту, счет или кошелек? Кто отвечает, если чарджбэк пришел после того, как продавцу уже заплатили?
В ЕС вторая директива о платежных услугах (PSD2) относит эквайринг и денежные переводы к платежным услугам в Приложении I. Статья 3(b) исключает платежи через коммерческого агента, только если агент действует от имени лишь плательщика или лишь получателя. Если вы принимаете платежи за многих продавцов и выплачиваете им средства, проверьте лицензию до того, как строить сценарий. Правила различаются по странам: в Казахстане требования к платежным услугам нужно сверять с позицией Национального банка (НБК).
Об организационных и административных вопросах запуска платежного сервиса, включая лицензирование, мы писали в статье «Как создать сервис приема платежей: административные и организационные вопросы».
В eComCharge один платеж можно разделить между несколькими получателями с автоматическими расчетами и отчетностью, а выплата отправляет средства на карту клиента.
Если ваш сценарий переводит деньги между частными лицами (P2P), а не продавцам, этот случай разобран в руководстве о P2P-платежах через API.
Задача описывается письменно до написания кода: вы формулируете бизнес-потребность, вендор разделяет ее на настройку и разработку, и обе стороны подписывают спецификацию интеграции с приемочными тестами. Затем идут разработка, ваше тестирование, сертификация у третьих сторон и контролируемый запуск.
Опишите мерчанта, рынок и денежный поток, приложите примеры транзакций и ожидаемые отчеты. Техническое решение оставьте вендору.
Вендор отмечает каждый пункт как настройку, существующий модуль или новую разработку и указывает, что ему нужно от третьих сторон.
В спецификации перечислены методы API, типы транзакций, коды ответов, вебхуки и приемочные тесты, по которым работа будет закрыта.
Разработка идет в тестовой среде. Перед передачей сборки вам вендор проводит собственное регрессионное тестирование.
Ваша команда повторяет примеры транзакций, включая возвраты, частичные возвраты, отказы и таймауты, и подписывает приемку.
Эквайер или провайдер метода оплаты сертифицирует свой коннектор. Платежная система сертифицирует только то, что регулирует сама, например 3DS Server.
Начните с одного мерчанта или доли трафика, следите за уровнем одобрений и ошибками, затем расширяйте.
Postman-коллекция beGateway позволяет бизнес-сотрудникам попробовать запросы до того, как разработчики начнут писать код.
На стоимость и сроки влияют шесть факторов: модель развертывания, доля новой разработки, количество новых коннекторов, сертификация у третьих сторон, миграция данных и выделенная инфраструктура. В таблице показано, почему каждый из них меняет результат и кто им управляет.
| Фактор | Почему меняет стоимость или сроки | Кто управляет |
|---|---|---|
| Модель развертывания | SaaS у eComCharge: от 1 недели; ваши серверы: от 3 месяцев | Вы выбираете |
| Доля новой разработки | Настройка требует только времени вашей команды; новый код требует спецификации, тестов и поддержки | Gap-анализ вендора |
| Новые коннекторы | Каждому нужны спецификация эквайера, разработка и сертификация | Вендор и эквайер |
| Очередь на сертификацию | Эквайер или провайдер метода сам назначает тестовые слоты | Третья сторона |
| Миграция данных | Перенос мерчантов, истории и токенов сохраненных карт со старой платформы | Вы, старый и новый вендор |
| Выделенная инфраструктура | Серверы, зарезервированные под вас или одного мерчанта вместо общего пула | Выбираете вы, эксплуатирует вендор |
Индивидуальное решение окупается, когда изменение приносит больше, чем стоит его поддержка: больше одобренных платежей, новый рынок или сегмент мерчантов, который раньше был недоступен.
Допущения, придуманные для примера: вы PSP на SaaS-платформе. Вы добавляете эквайера в новой стране, локальный метод оплаты и еженедельные выплаты продавцам одного мерчанта-маркетплейса.
Только один из четырех пунктов гарантированно требует разработка. Это должно отражаться в предложении вендора, а ваш план должен начинаться с договора с эквайером.
Выделенную инфраструктуру можно добавить позже. В одном из наших проектов PSP на общем SaaS решил проблему производительности за несколько дней, выделив два сервера под одного мерчанта, вместо того чтобы масштабировать всю платформу.
Стоимость eComCharge зависит от ваших задач, поэтому свяжитесь с отделом продаж, чтобы получить предложение.
Риски индивидуальных платежных решений: технический долг, расширение области PCI DSS, зависимость от одного вендора и сроки запуска, которые задают третьи стороны. Каждый растет вместе с долей кастомного кода в вашем стеке, и для каждого есть мера контроля, о которой можно договориться до начала работ.
| Риск | Что идет не так | Как снизить |
|---|---|---|
| Технический долг | Эквайер меняет API или платежная система меняет правило, а за кастомный код никто не отвечает | Выбирайте функции, которые войдут в стандартный продукт; укажите в договоре, кто поддерживает код |
| Расширение области PCI DSS | Собственная платежная страница переносит данные карт в системы мерчанта или ваши | Оставьте ввод карты на хостинговых страницах, в виджетах или SDK и используйте токены шлюза |
| Зависимость от вендора | Токены, данные мерчантов и правила маршрутизации нельзя вынести с платформы | Согласуйте условия выгрузки данных и токенов до подписания |
| Задержки третьих сторон | Слот сертификации у эквайера сдвигает ваш запуск | Сначала заключите договор с эквайером и заранее забронируйте сертификацию |
| Размывание требований | Требования меняются во время разработки, и работа никогда не закрывается | Зафиксируйте приемочные тесты в спецификации, а изменения оформляйте новой задачей |
Зависимость от вендора стоит проверять жестче всего. В одном из наших проектов PSP, чей эквайер перестал работать, сохранил базу рекуррентных платежей благодаря миграции токенов за одну неделю. Спросите любого вендора, как он сделал бы то же самое для вас.
Передача PCI DSS на аутсорсинг сертифицированной платформе сужает вашу область, но не убирает ее. Вы по-прежнему проверяете собственную среду и процессы.
Если вы еще сравниваете платформы, в руководстве о том, как выбрать White-Label платежную платформу, перечислено, что проверить помимо кастомизации.
eComCharge представляет собой White-Label платежную платформу для PSP, банков-эквайеров и платформ. Маршрутизацию, комиссии, брендинг и отчеты вы настраиваете сами, а eComCharge разрабатывает то, чего в платформе еще нет, начиная с новых коннекторов.
Установка в формате SaaS занимает от 1 недели, на ваших серверах от 3 месяцев.
Подробнее о платформе beGateway читайте на странице White-Label платежного шлюза.
Это платежная инфраструктура, в которой оператор (PSP, банк или платформа) адаптирует коннекторы, платежную страницу, маршрутизацию, отчеты или логику выплат платежной платформы под своих мерчантов и рынки. Большая часть работы сводится к настройке существующей платформы. Разработка нужна там, где не хватает эквайера, метода оплаты или денежного потока.
На практике ничем. Bespoke чаще говорят в британском английском, custom в американском. Оба термина означают платежный стек, адаптированный под бизнес конкретного оператора: настройкой, доработкой у вендора или собственной разработкой.
Строить стоит, только если платежные технологии являются вашим основным продукт и вы готовы финансировать работу: по нашей оценке, на готовый к промышленной эксплуатации шлюз уходит от 12 месяцев до 2 лет. В остальных случаях большинство задач закрывает White-Label платформа под вашим брендом с доработкой коннекторов и сценариев по запросу. Установка eComCharge в формате SaaS занимает от 1 недели.
Да, если вендор разрабатывает коннекторы по запросу. Вы заключаете договор с эквайером и получаете его спецификацию и тестовый доступ, вендор разрабатывает коннектор, эквайер сертифицирует его перед запуском боевого трафика. У eComCharge более 170 активных коннекторов, новые разрабатываются по запросу.
Может изменить. Если данные карты вводятся на хостинговой платежной странице, в виджете или SDK, их обрабатывает шлюз, и область PCI DSS мерчанта остается небольшой. Если мерчант делает собственную форму на прямом API, данные карты попадают в его системы и область PCI DSS расширяется. С 31 марта 2025 года мерчант, который проходит проверку по анкете самооценки SAQ A, должен также подтвердить, что его сайт не уязвим для атак через скрипты.
Окупается, если изменение приносит больше, чем стоит его поддержка: больше одобренных платежей, новый рынок или сегмент мерчантов, который раньше был недоступен. Начните с настроек, которые уже есть в платформе, и заказывайте разработку только для остального. Учитывайте поддержку, сертификацию и миграцию как часть стоимости.
Это зависит от модели развертывания, количества новых коннекторов, доли новой разработки и выделенной инфраструктуры. Стоимость eComCharge определяется вашими задачами, поэтому свяжитесь с отделом продаж, и мы рассчитаем предложение под ваши требования.
Главные риски: технический долг, когда за кастомный код никто не отвечает, расширение области PCI DSS, когда данные карт уходят из шлюза, зависимость от вендора, когда токены и данные нельзя выгрузить, и сроки запуска, которые диктует сертификация у эквайера. Договоритесь о том, кто поддерживает код, об условиях выгрузки данных и о плане сертификации до начала работ.
eComCharge разрабатывает и предоставляет сертифицированную по стандарту PCI DSS Level 1 White Label платформу для обработки платежей beGateway для поставщиков платежных услуг и оркестрации платежей.
Практическое руководство по запуску платежного сервис-провайдера: выбор модели, договор с эквайером, лицензирование, PCI DSS, выбор платформы, статьи затрат и план запуска в 9 шагов.
Четыре типа провайдеров токенизации для PSP и банков, сетевые и шлюзовые токены, переносимость и миграция токенов, влияние на область PCI DSS и вопросы, которые стоит задать до выбора.
Как PSP ведет портфель мерчантов на White-Label платформе: иерархия, онбординг и KYC, настройки магазинов, роли пользователей, мониторинг чарджбэков, выплаты и отключение мерчантов.
Для PSP, банков-эквайеров и эмитентов электронных денег: что включает платежный шлюз «все в одном», что остается вне его, один шлюз или несколько провайдеров и как проверить покрытие по каждому рынку.
Узнайте, как построить успешную бизнес-модель платежного шлюза в Центральной Азии. Узнайте о ключевых источниках дохода, бизнес-моделях и стратегиях для быстрого выхода на рынок в 2025 году.
Изучите, как работает white-label система для обработки и приема платежей по банковским картам и как она помогает компаниям быстро, безопасно и экономически эффективно запускать брендированные платежные решения. Узнайте о преимуществах и особенностях white-label платежных решений.