Практическое руководство по запуску платежного сервис-провайдера: выбор модели, договор с эквайером, лицензирование, PCI DSS, выбор платформы, статьи затрат и план запуска в 9 шагов.
Платежный шлюз «все в одном» представляет собой единую платформа, через которую мерчанты принимают карты, кошельки и локальные методы оплаты, отправляют выплаты и получают отчеты по одной интеграции. Руководство написано для PSP, банков-эквайеров и эмитентов электронных денег, которые хотят предлагать такой сервис.
Это программное обеспечение платежного шлюза, которое собирает все сценарии приема и выплат, нужные мерчантам, за одной интеграцией, одним бэк-офисом и одной моделью данных. Мерчант подключается один раз. Вы добавляете эквайеров, кошельки и локальные методы за этим подключением, не заставляя мерчанта менять код.
Альтернатива: набор отдельных инструментов. Мерчант, который продает на трех рынках, может использовать один шлюз для карт, второго провайдера для локального банковского перевода, сервис выплат и таблицу для их сверки. У каждого элемента свой API, свой формат отчетов и своя поддержка.
Шлюз «все в одном» заменяет этот набор одним слоем, которым управляете вы. Он не заменяет организации за ним: эквайеры по-прежнему проводят эквайринг, эмитенты авторизуют платежи, а провайдеры кошельков обслуживают свои кошельки.
| Область | Отдельные инструменты | Шлюз «все в одном» |
|---|---|---|
| Интеграция | Отдельный API на каждого провайдера, у каждого свои коды ошибок | Один API, одна платежная страница, один плагин на каждую CMS |
| Новый метод или рынок | Новый договор и новый проект интеграции у мерчанта | Вы включаете коннектор, интеграция мерчанта не меняется |
| Сбой эквайера | Платежи стоят, пока мерчант вручную не переключится | Правила маршрутизации переводят трафик на резервного эквайера |
| Отчетность | Отчет от каждого провайдера, сводится вручную | Один список транзакций и один набор отчетов по расчетам |
| Данные карт | Хранятся в нескольких местах, каждое в зоне PCI DSS | Токенизируются один раз и доступны на любом подключенном эквайере |
«Все в одном» описывает состав, а не бизнес-модель. Шлюз можно запускать как собственный продукт или брендировать и продавать мерчантам как свой. Такой вариант называется White-Label шлюз, о котором рассказывает наше руководство по White-Label.
Полноценный шлюз покрывает девять областей: методы оплаты, каналы интеграции, типы транзакций вместе с выплатами, валюты, маршрутизацию, аутентификацию, хранение карт, управление мерчантами и сверку. Если чего-то не хватает, мерчанты покупают это у кого-то другого, и вы снова возвращаетесь к набору инструментов.
Три семейства: карты платежных систем; Apple Pay и Google Pay, чей токен карты эквайер обрабатывает как карточный платеж; и альтернативные методы оплаты (APM), большинство из которых подтверждают платеж позже уведомлением, а не в первом ответе.
Server-to-server API, платежная страница, встраиваемый платежный виджет, мобильные SDK, платежные ссылки и плагины для CMS интернет-магазинов.
Одно- и двухстадийные платежи, возвраты, отмены, рекуррентные платежи, выплаты на карты и переводы с карты на карту. Проверяйте полный список типов транзакций для каждого коннектора, а не только для платформы.
Прием в валюте покупателя и расчеты в валюте мерчанта с автоматической конвертацией валют, если валюта эквайринга отличается от валюты платежа.
Правила выбора эквайера по карте, стране, валюте или сумме, резервный маршрут на случай сбоев и каскадирование отказов, которые платежная система разрешает повторить.
Антифрод-правила, лимиты и черные списки, а также 3DS Server, который по правилу проводит 3-D Secure без challenge, с challenge или как принудительную аутентификацию.
Токенизация платежей в хранилище и сетевые токены (токены, которые платежные системы выпускают вместо номера карты), чтобы рекуррентные платежи и оплата в один клик работали на любом эквайере, выбранном правилами.
Онбординг, магазины, комиссии, лимиты, балансы и роли пользователей в одном бэк-офисе, с правилами, которые задаются один раз для всех мерчантов или для каждого отдельно.
Единый поиск транзакций по всем методам, отчеты по расчетам по каждому эквайеру и сверка ваших данных с банковскими выписками.
Выплаты стоит протестировать отдельно. Прием платежа и выплата используют разные коннекторы, а иногда и разных провайдеров. Убедитесь, что выплаты попадают в те же отчеты сверки, что и входящие платежи.
В него не входят эквайринг, лицензия, проверка мерчантов и связанная с ними ответственность. Шлюз передает платежные сообщения и данные. Договоры, разрешения регулятора и сами средства остаются за вами, вашими эквайерами и провайдерами методов оплаты.
| Вне шлюза | Кто отвечает | Что делает шлюз |
|---|---|---|
| Эквайринг | Эквайер: банк или лицензированная организация, которая заключает договор с мерчантом, передает транзакции в платежную систему и проводит расчеты | Подключается к эквайеру и маршрутизирует ему платежи |
| Лицензия | Вы или лицензированный партнер, под которым вы работаете | Ничего: программное обеспечение не дает лицензии |
| KYC/AML и андеррайтинг мерчантов | Вы и ваш эквайер, по вашей риск-политике | Хранит данные мерчантов, задает лимиты, помечает транзакции |
| Средства и расчеты | Эквайер или провайдер выплачивает мерчанту или вам, если средства собираете вы | Рассчитывает комиссии и балансы, фиксирует расчеты |
| Чарджбэки и потери от мошенничества | Вы и ваш эквайер, по договору | Фиксирует споры и предоставляет данные по транзакциям |
В ЕС вторая платежная директива (PSD2) не распространяется на технических провайдеров по статье 3(j), то есть на тех, кто поддерживает платежные услуги, ни в какой момент не владея средствами. Эквайринг по Приложению I является платежной услугой. Платежному учреждению, которое занимается эквайрингом, нужен начальный капитал не менее 125 000 евро (статья 7). В других странах правила отличаются: в Казахстане требования нужно уточнять у Национального банка (НБК).
Практическая проверка состоит в анализе вашего потока средств. Если эквайеры проводят расчеты напрямую с мерчантами, вы работаете как технический шлюз, а лицензии есть у партнеров. Если деньги мерчантов проходят через ваши счета, нужна собственная лицензия или лицензированный партнер. Организационные и административные вопросы запуска мы разбирали в статье о создании сервиса приема платежей.
Ответственность определяется договорами, а не программным обеспечением. Наше руководство по обработке карточных платежей объясняет ответственность за чарджбэки в разных моделях, а руководство по автоматизации онбординга high-risk мерчантов описывает сторону due diligence.
Шлюз работает как переводчик. Мерчант отправляет каждый платеж в одном формате; шлюз выбирает коннектор, преобразует запрос в формат провайдера и переводит ответ обратно. У каждого шага есть ответственный, и код мерчанта не меняется, когда вы добавляете провайдера.
Ответственный: мерчант. Его чекаут вызывает ваш API, или покупатель платит на вашей платежной странице или в виджете. Запрос содержит сумму, валюту, идентификатор магазина и выбранный покупателем метод.
Ответственный: вы, через правила шлюза. Сначала срабатывают лимиты и антифрод-правила. Там, где действует строгая аутентификация клиента (например, для электронных платежей по статье 97 PSD2 в ЕС), 3DS Server передает покупателя эмитенту.
Ответственный: вы задаете правила, шлюз их применяет. В eComCharge Smart Routing учитывает такие условия, как BIN, страна, валюта, сумма и тип карты, и задает резервный маршрут.
Ответственный: эквайер или провайдер метода. Для карты эквайер отправляет авторизацию через платежную систему, а эмитент одобряет или отклоняет ее. Для APM провайдер проводит собственный сценарий, часто это редирект в банк или кошелек покупателя.
Ответственный: шлюз. Он сопоставляет код ответа провайдера с понятным мерчанту статусом, уведомляет мерчанта через webhook и записывает транзакцию.
Ответственный: эквайер или провайдер проводит расчеты, вы сверяете. Каждый провайдер присылает свой отчет по расчетам. Шлюз сопоставляет их со своими данными, и вы видите комиссии, возвраты и чарджбэки по каждому мерчанту.
Слабое место: шаг 5. У каждого провайдера свои коды отказов и статусы, и шлюз, который сопоставляет их небрежно, выдает мерчантам расплывчатые ошибки. Спросите, как причины отказов отображаются в аналитике мерчанта по каждому коннектору.
Один шлюз дает мерчантам одну интеграцию, а вам одно место для управления маршрутизацией, рисками и отчетами. Несколько провайдеров параллельно дают мерчанту сильнейшего специалиста по каждому методу, но ценой большего числа интеграций и отчетов и без общей маршрутизации. Промежуточный вариант: слой оркестрации поверх нескольких шлюзов.
| Критерий | Шлюз «все в одном» | Несколько провайдеров у мерчанта | Слой оркестрации над несколькими шлюзами |
|---|---|---|---|
| Интеграции мерчанта | Одна | По одной на провайдера | Одна, со слоем оркестрации |
| У кого подключения к эквайерам | У шлюза, по вашим договорам | У каждого провайдера, по его договорам | У нижележащих шлюзов |
| Маршрутизация между эквайерами | Встроенная, в одном движке правил | Нет; мерчант выбирает на каждом чекауте | Между шлюзами, а не внутри них |
| Токены карт | Одно хранилище для всех маршрутов | Отдельно у каждого провайдера | Зависит от собственного хранилища слоя |
| Сверка | Один набор отчетов | Отчет от каждого провайдера | Сводится слоем из нескольких источников |
| Главный риск | Зависимость от одной платформы | Операционная нагрузка и разрозненные данные | Дополнительный слой и дополнительный поставщик |
Оркестрация и шлюз «все в одном» пересекаются: оба маршрутизируют и оба приводят ответы к единому виду. Разница в том, что шлюз сам подключается к эквайерам, а платежная оркестрация обычно подключается к другим шлюзам.
Для каждого рынка, где продают ваши мерчанты, проверьте пять вещей: работающий коннектор для каждого метода, которым там платят покупатели; эквайера с правом обслуживать мерчантов, зарегистрированных в этой стране; расчеты в нужной валюте; местные правила аутентификации; выплаты на местные карты или счета. Список коннекторов с пометкой «весь мир» не отвечает ни на один из этих вопросов.
| Проверка | Что спросить | Почему это важно |
|---|---|---|
| Юрисдикция эквайера | Какой из подключенных эквайеров вправе обслуживать мерчанта, зарегистрированного в этой стране? | По Visa Core Rules 1.5.1.1 эквайер принимает транзакции только от торговых точек в стране своего местонахождения, если не действует исключение, например паспортизация в ЕС, то есть использование лицензии одной страны ЕС в другой. |
| Локальные методы | Какие внутренние методы уже работают как коннекторы, а какие есть только в планах? | Метод из дорожной карты платежи не принимает; запросите список работающих методов по рынку. |
| Валюты | В каких валютах мерчант может принимать платежи и в каких валютах проводит расчеты каждый эквайер? | Прием в одной валюте и расчеты в другой добавляют шаг конвертации и его комиссию. |
| Аутентификация | Соответствует ли настройка 3DS местным правилам строгой аутентификации клиента? | В ЕС PSD2 требует ее для электронных платежей, инициированных плательщиком; в других странах правила задает местный регулятор. |
| Выплаты | Могут ли мерчанты через коннектор выплачивать на карты или счета в этой стране? | Маркетплейсам и гейминг-мерчантам выплаты нужны не меньше, чем прием платежей. |
Допущения: вы PSP с 40 мерчантами. Они продают на рынке A (ваш домашний рынок), рынке B (соседняя страна, где ваш эквайер вправе работать) и рынке C (страна, где у подключенных эквайеров нет такого права). Покупатели на каждом рынке платят картами и одним локальным методом. Рынки и цифры придуманы для примера.
Если вы банк с лицензией на внутренний эквайринг, вопрос стоит наоборот: ваш эквайринг покрывает местных мерчантов, а шлюз добавляет методы и рынки.
Главный риск связан с концентрацией: все методы, мерчанты и токены находятся на одной платформе. Из этого вытекают четыре риска, и для каждого есть решение в договоре, архитектуре или правилах маршрутизации.
| Риск | Почему это важно | Как снизить |
|---|---|---|
| Сбой платформы | Если шлюз остановится, все методы остановятся одновременно. | Запросите обязательства по доступности в соглашении об уровне сервиса (SLA), схему отказоустойчивости и историю инцидентов. |
| Привязка к поставщику | Мерчанты, токены и история хранятся на одной платформе. | Согласуйте условия выгрузки данных и миграции токенов до подписания договора. |
| Широта вместо глубины | Длинный список коннекторов может скрывать коннекторы с малым набором типов транзакций. | Протестируйте возвраты, выплаты и рекуррентные платежи на каждом коннекторе, который планируете использовать. |
| Комплаенс «по умолчанию» | Сертификат PCI DSS платформы не распространяется на ваши системы и сотрудников. | Письменно распределите обязанности по PCI DSS; отдавайте предпочтение платежным страницам и токенам. |
Перенос всех методов на один шлюз не распределяет риск эквайринга. Если весь карточный трафик по-прежнему идет одному эквайеру, сбой или отключение у него остановит ваш карточный бизнес. Держите минимум два маршрута и правило резервирования для рынков, на которые приходится ваш объем. Как настроить второй маршрут, показывает наше руководство по стратегии мульти-эквайринга.
Он не нужен, если ваши мерчанты продают в одной стране, принимают карты через одного эквайера и не делают выплат. С этим справится стандартное подключение к шлюзу. Смысл в шлюзе «все в одном» появляется вместе со вторым рынком, вторым эквайером или потоком выплат.
Если вы развиваете программную платформу и платежи для вас лишь одна из функций продукта, а не сам продукт, прочитайте, как их встраивает SaaS-платежная платформа.
Начинайте с мерчантов, а не со списка функций поставщика. Запишите, где они продают, какие методы и выплаты им нужны и с какими эквайерами вы работаете, а затем проверьте каждого поставщика по этому списку. Шесть шагов ведут от списка к решению.
Перечислите рынки, методы, валюты и потребности в выплатах ваших мерчантов с долей объема по каждому пункту.
Попросите у поставщика список работающих коннекторов на этих рынках с типами транзакций по каждому. Узнайте, как добавляются новые коннекторы и кто за это платит.
Убедитесь, что ваши текущие эквайеры уже подключены, или узнайте, сколько займет их подключение.
В песочнице проведите платеж, возврат, выплату и чарджбэк на каждом ключевом коннекторе и найдите каждую операцию в отчете сверки.
Отключите маршрут в тестовой среде и посмотрите, как переключается трафик. Проверьте, что правила можно задать для всех мерчантов и для одного мерчанта.
Закрепите в договоре выгрузку данных, миграцию токенов и распределение обязанностей по PCI DSS.
Полный список критериев выбора поставщика приведен в руководстве о том, как выбрать White-Label платежную платформу.
Как оператор зарабатывает на шлюзе, на что тратит и как спланировать запуск.
eComCharge разрабатывает White-Label платежный шлюз beGateway для PSP, банков-эквайеров и платежных организаций, которые обслуживают онлайн-мерчантов. Он объединяет прием, выплаты, маршрутизацию, аутентификацию и сверку в одной платформе по модели SaaS (установка от 1 недели) или на ваших серверах (от 3 месяцев).
Платформа обслуживает PSP с низким уровнем риска, банки, а также PSP в сегментах iGaming и Forex.
Стоимость решений eComCharge зависит от ваших задач (модели развертывания, объемов и коннекторов), поэтому свяжитесь с отделом продаж, чтобы получить предложение, и посмотрите все возможности нашего White-Label платежного шлюза.
Это платежный шлюз, который объединяет прием карт, кошельков и локальных методов оплаты, выплаты, мультивалютность, маршрутизацию, 3-D Secure и сверку за одной интеграцией. Мерчант подключается один раз (через API, платежную страницу или плагин), а вы добавляете эквайеров и методы за этим подключением.
Эти термины используют для одного и того же. «Шлюз» подчеркивает технический слой, который принимает и маршрутизирует платежи; «платформа» обычно добавляет бэк-офис вокруг него: управление мерчантами, комиссии, балансы и отчеты. Сравнивая предложения, проверяйте состав по пунктам, а не по названию.
Карты платежных систем, кошельки вроде Apple Pay и Google Pay и альтернативные методы оплаты: локальные банковские переводы и мгновенные платежи, каждый через коннектор к провайдеру, который его обслуживает. Важно, какие коннекторы работают на рынках ваших мерчантов, а не длина глобального списка.
Нет. Шлюз подключается к эквайерам и маршрутизирует им платежи, но эквайер представляет собой отдельный банк или лицензированную организацию, которая заключает договор с мерчантом и проводит расчеты. Вам по-прежнему нужны договоры эквайринга, а если средства мерчантов проходят через ваши счета, то и собственная лицензия или лицензированный партнер.
Лучше, если ваши мерчанты продают на нескольких рынках или им нужны несколько методов и выплаты: они интегрируются один раз, а вы маршрутизируете, формируете отчеты и сверяете всё в одном месте. Несколько отдельных провайдеров подойдут одному мерчанту с одной узкой задачей, но ценой большего числа интеграций и разрозненных отчетов.
Да. White-Label платежный шлюз представляет собой шлюз «все в одном», который вы брендируете и продаете мерчантам как собственный продукт: со своей платежной страницей, бэк-офисом и доменом. Как устроена эта модель, рассказывает наше руководство по White-Label платежному шлюзу.
Задайте по этой стране пять вопросов: какие локальные методы уже работают как коннекторы, какой из подключенных эквайеров вправе обслуживать мерчантов, зарегистрированных в ней, в каких валютах расчетов работает каждый эквайер, соответствует ли настройка 3-D Secure местным правилам аутентификации и могут ли мерчанты выплачивать на местные карты и счета. Затем проведите тестовый платеж, возврат и выплату.
Это зависит от модели развертывания, объемов, нужных коннекторов и доработок. Стоимость решений eComCharge определяется вашими конкретными задачами, поэтому свяжитесь с нашим отделом продаж, чтобы получить предложение. Отдельно заложите в бюджет договоры эквайринга, лицензирование и собственную команду риска и поддержки.
eComCharge разрабатывает и предоставляет сертифицированную по стандарту PCI DSS Level 1 White Label платформу для обработки платежей beGateway для поставщиков платежных услуг и оркестрации платежей.
Практическое руководство по запуску платежного сервис-провайдера: выбор модели, договор с эквайером, лицензирование, PCI DSS, выбор платформы, статьи затрат и план запуска в 9 шагов.
Руководство для PSP, банков и платформ: собственная разработка, готовый продукт или White-Label, что можно настроить, как описать и запустить новый коннектор или схему выплат, от чего зависят стоимость и сроки и какие риски учесть.
Четыре типа провайдеров токенизации для PSP и банков, сетевые и шлюзовые токены, переносимость и миграция токенов, влияние на область PCI DSS и вопросы, которые стоит задать до выбора.
Как PSP ведет портфель мерчантов на White-Label платформе: иерархия, онбординг и KYC, настройки магазинов, роли пользователей, мониторинг чарджбэков, выплаты и отключение мерчантов.
Узнайте, как построить успешную бизнес-модель платежного шлюза в Центральной Азии. Узнайте о ключевых источниках дохода, бизнес-моделях и стратегиях для быстрого выхода на рынок в 2025 году.
Изучите, как работает white-label система для обработки и приема платежей по банковским картам и как она помогает компаниям быстро, безопасно и экономически эффективно запускать брендированные платежные решения. Узнайте о преимуществах и особенностях white-label платежных решений.