Практическое руководство по запуску платежного сервис-провайдера: выбор модели, договор с эквайером, лицензирование, PCI DSS, выбор платформы, статьи затрат и план запуска в 9 шагов.
SaaS платежной платформой называют платежный стек, через который программная платформа дает своим пользователям принимать разовые и рекуррентные платежи прямо в продукте: шлюз, эквайринг, хранение учетных данных карт, онбординг и выплаты. Руководство написано для вертикальных SaaS-платформ, которые встраивают платежи, и для PSP и банков, которые их обслуживают.
SaaS платежная платформа (software-as-a-service) превращает платежи в функцию вашего программного продукта. Ваши пользователи (клиники, фитнес-клубы, школы или агентства) выставляют счета своим клиентам из тех же экранов, в которых уже работают, а вы получаете долю процессинговой маржи. За интерфейсом стоят шлюз, один или несколько эквайеров и биллинговый движок.
Это платежная часть встроенных финансов (embedded finance). Она отличается от SaaS-компании, которая выставляет счета только собственным подписчикам: там вы один мерчант, а здесь обслуживаете сотни или тысячи мерчантов.
Вы продаете софт и ежемесячно списываете оплату с клиентов. Достаточно одного мерчант-аккаунта, одной биллинговой системы и собственной налоговой настройки.
Каждый пользователь является мерчантом или субмерчант. Вы подключаете их, маршрутизируете их платежи, разделяете средства и делаете выплаты из одного бэк-офиса.
В каждом встроенном платеже участвуют пять сторон, и каждая отвечает за свое решение:
| Сторона | Что делает |
|---|---|
| Ваша платформа | Подключает пользователей, задает им тарифы, содержит логику биллинга и ведет управление субмерчантами |
| Платежный шлюз | Принимает и токенизирует данные карты, применяет правила маршрутизации и 3-D Secure (3DS) и отправляет авторизацию эквайеру |
| Эквайер | Проводит андеррайтинг мерчантов или платежного фасилитатора, передает авторизации в платежную систему и рассчитывается по средствам |
| Эмитент | Аутентифицирует держателя карты и одобряет или отклоняет каждый платеж |
| Клиент вашего пользователя | Соглашается на платеж или на условия хранения карты для продлений |
Процессинг платежей в SaaS представляет собой цепочку от онбординга до выплаты. Вы подключаете пользователя, клиент платит и соглашается на сохранение карты, шлюз хранит токен, вы инициируете каждое продление, эквайер проводит расчеты, а сторона, которая держит средства (вы как платежный фасилитатор, или PayFac, либо провайдер), делает выплату пользователю.
Продукт собирает данные о компании и владельце для проверок KYC (know your customer). Андеррайтинг проводит сторона, которая заключает договор с пользователем: вы как зарегистрированный PayFac, провайдер в реферальной модели или PayFac-as-a-service (PayFac провайдера, который подписывает ваших пользователей как своих субмерчантов) либо ваш эквайер. Автоматизированный онбординг мерчантов снижает число пользователей, которые бросают подключение до первого платежа.
Клиент платит на платежной странице или во встроенных полях и принимает условия рекуррентных списаний. Если требуется строгая аутентификация клиента, ваш 3DS-сервер проводит ее вместе с эмитентом.
Шлюз сохраняет карту в своем хранилище и возвращает токен вашему продукту. При платежной странице или встроенных полях номер карты не попадает на ваши серверы.
В каждую дату биллинга продукт списывает средства по токену как транзакцию, инициированную мерчантом (MIT): клиент при этом не участвует.
Эквайер, принявший авторизацию, проводит клиринг, рассчитывается по средствам и позже получает чарджбэки, если они будут.
Как PayFac вы удерживаете свою комиссию и платите каждому пользователю; в реферальной модели и PayFac-as-a-service выплачивает провайдер, а вы получаете свою долю. Разделение платежей и выплаты поставщикам автоматизируют этот шаг сразу для множества пользователей.
Прежде чем сохранить карту для продлений, первая авторизация или проверка счета должна быть одобрена; если нет, учетные данные сохранять нельзя. Если продление, инициированное мерчантом, отклонено, мерчант обязан письменно уведомить держателя карты и дать ему не менее 7 календарных дней, чтобы оплатить другим способом (Visa Product and Service Rules, Table 5-21).
Выбирайте модель по тому, какую ответственность вы готовы нести. Реферальная модель оставляет риск у провайдера, PayFac-as-a-service делит его. Зарегистрированный PayFac отвечает перед эквайером за своих пользователей. Собственный White-Label шлюз добавляет контроль над ценами и маршрутизацией; ответственность тогда зависит от того, кто заключает договор с пользователями: вы или ваши эквайеры.
| Модель | Кто заключает договор с пользователем | Ваша доля маржи | Кто несет убытки |
|---|---|---|---|
| Реферальная | Платежный провайдер; вы приводите пользователей как независимая сервисная организация (ISO) или партнер | Реферальное вознаграждение или резидуал (регулярная доля процессинговой маржи) | В основном провайдер |
| PayFac-as-a-service | PayFac провайдера; пользователи становятся его субмерчантами, подключенные в вашем продукте | Согласованная доля | Совместно, в основном провайдер |
| Зарегистрированный PayFac | Вы, по мастер-договору со спонсирующим эквайером | Вы задаете цены и оставляете маржу себе | Вы, затем ваш эквайер |
| White-Label шлюз | Вы или ваши эквайеры, в зависимости от выбранной модели | Вы задаете цены и выбираете эквайеров | Тот, кто заключает договор с пользователем: вы как PayFac или PSP либо ваши эквайеры |
Компания, которая по договору с эквайером подключает спонсируемых мерчантов (субмерчантов) и делает им выплаты в рамках своего мастер-аккаунта. Visa рассматривает каждого спонсируемого мерчанта как мерчанта эквайера PayFac.
Ответственность закреплена в правилах платежных систем. Согласно разделу 5.3.1 Visa Product and Service Rules, PayFac несет финансовую ответственность за каждую транзакцию спонсируемых мерчантов и обязан обеспечить их соответствие PCI DSS. Эквайер отвечает за PayFac и всех его спонсируемых мерчантов, поэтому проверяет, как вы проводите андеррайтинг, и может удерживать резервы.
White-Label шлюз подходит платформам, которые уже обрабатывают большой оборот, хотят работать с несколькими эквайерами или планируют стать PSP. White-Label шлюз beGateway от eComCharge дает вам брендированный шлюз, а руководство по бизнес-модели платежного шлюза показывает, откуда берутся его доходы и расходы.
Ей нужны модели ценообразования, которые продают ваши пользователи, и флаги платежных систем, благодаря которым продления одобряются. Биллинговый движок решает, кому, сколько и когда списать. Шлюз списывает средства по сохраненному токену, помечает первый платеж как инициированный клиентом, а каждое продление как инициированное мерчантом.
Visa требует передавать признак рекуррентной транзакции в авторизации первого платежа и каждого продления (Visa Product and Service Rules, Table 5-21). В европейском регионе Visa мерчант также обязан подтвердить держателю карты рекуррентное соглашение в течение 2 рабочих дней (Table 5-19).
Одна цена в месяц или год, часто с уровнями.
Сумма растет вместе с числом пользователей; места, добавленные в середине периода, считаются пропорционально.
Списание по факту на основе учетных данных, например бронирований или вызовов API.
Базовая плата плюс использование или дополнительные опции.
Триалы с автоматическим переходом на платный тариф и временные скидки.
Повышение тарифа, паузы и отмены с пропорциональным пересчетом и возвратами.
В Европейской экономической зоне статья 97 PSD2, второй директивы ЕС о платежных услугах, требует строгой аутентификации клиента (SCA), когда электронный платеж инициирует плательщик. Продление, которое ваш продукт инициирует по соглашению о хранении учетных данных, плательщик не инициирует, поэтому держатель карты, как правило, проходит аутентификацию один раз, при оформлении подписки.
Для серий платежей одной суммы действует отдельное правило. Статья 14 регуляторных технических стандартов по SCA требует SCA, когда плательщик создает, изменяет или впервые инициирует серию платежей одной суммы одному получателю, и разрешает последующие платежи серии без нее.
PSD2 и стандарты SCA действуют в ЕЭЗ. В Казахстане и других странах Центральной Азии требования к аутентификации и рекуррентным платежам могут отличаться: сверяйте их с местным регулятором, например с НБК в Казахстане, и с вашим эквайером.
Сохраненные токены также дают клиентам ваших пользователей оплату в один клик для дополнительных опций и повышения тарифа: такие платежи по-прежнему считаются инициированными клиентом.
Сократить неудачные продления помогают четыре инструмента: сетевые токены, которые переживают перевыпуск карты, сервис обновления данных карт (account updater) для сохраненных номеров, повторы с учетом кода отказа и банковские дебеты для клиентов, которые их предпочитают. Продление, сорвавшееся из-за истекшей карты, может стоить вашему пользователю клиента по причине, которую платежные инструменты часто способны устранить.
Источник: Visa, tokenization knowledge hub. CNP-транзакции Visa, токен против номера карты.
Visa публикует обе цифры в своем разделе о токенизации.
У каждого инструмента есть свой владелец:
| Инструмент | Что исправляет | Кто отвечает |
|---|---|---|
| Сетевые токены | Истекшие и перевыпущенные карты: если эмитент поддерживает обновление токенов, платежная система поддерживает токен актуальным | Шлюз запрашивает токены, платежная система их выпускает |
| Account updater | Изменившиеся номера сохраненных карт обновляются до следующего продления | Сервис платежной системы через вашего эквайера или шлюз |
| Повторы с учетом кода отказа | Мягкие отказы, например недостаток средств, повторяются позже в рамках правил платежных систем о повторных попытках (маршрутизация платежей) | Ваш биллинговый движок и шлюз |
| Уведомление клиента | Жесткие отказы: письменное уведомление и ссылка для обновления карты | Ваш продукт от имени пользователя |
| Банковские дебеты | Истечение карты: SEPA Direct Debit в зоне евро, Bacs Direct Debit в Великобритании или ACH-дебеты в США работают по банковскому мандату | Пользователь получает мандат, банк проводит списание |
Повторы отличаются от каскадирования отклоненных транзакций: каскадирование сразу отправляет отклоненный платеж на оформлении заказа другому эквайеру, а повтор продления выжидает и обычно идет по тому же маршруту.
Ей нужен локальный эквайринг в каждой стране, где находятся ваши пользователи, локальные способы оплаты для их клиентов и цены в местной валюте. Правила платежных систем привязывают эквайера к стране мерчанта, поэтому выход за рубеж становится сначала вопрос договоров и только потом технический.
Охват PCI DSS зависит от того, проходят ли данные карт через ваши системы. Платежная страница или встроенные поля на стороне шлюза оставляют номера карт у шлюза, и ваш охват невелик. Прямой API полностью включает ваши серверы в охват. Как PayFac вы также отвечаете за соответствие ваших пользователей.
| Интеграция | Куда попадают данные карты | Ваши усилия по PCI DSS |
|---|---|---|
| Платежная страница | Вводятся на странице шлюза | Минимальные: ваши страницы перенаправляют на нее |
| Встроенные поля или платежный виджет | Вводятся в поля шлюза внутри вашей страницы | Небольшие, но страницу, которая загружает поля, нужно защищать |
| Прямой API | Проходят через ваши серверы | Большие: эти системы полностью в охвате |
| Собственный PayFac или шлюз | Вы обрабатываете данные карт других мерчантов | Валидация как сервис-провайдера плюс соответствие ваших спонсируемых мерчантов |
Поставщик шлюза валидирует свою платформу; вы валидируете собственную среду, сотрудников и процессы. Аутсорсинг PCI DSS поставщику сокращает ваш охват, но не убирает его. Уточните, какой опросник самооценки (SAQ) подавать, у эквайера или квалифицированного аудитора (QSA).
Доход от платежей равен платежному обороту ваших пользователей, умноженному на чистую ставку (take rate), которая остается вам после интерчейнджа, сборов платежных систем и затрат провайдера. Ставка измеряется в базисных пунктах (bps), где 100 bps равны 1%. Выбранная модель определяет, какая часть маржи остается у вас.
Аналитики ждут быстрого роста встроенных платежей. Grand View Research оценивает рынок встроенных платежей в 39,1 млрд долларов США в 2025 году и прогнозирует 430,3 млрд долларов к 2033 году, то есть среднегодовой рост 35,5% в 2026-2033 годах (Grand View Research). В 2020 году a16z утверждал, что встроенный финтех может увеличить выручку на клиента вертикального SaaS в 2-5 раз. И то и другое является прогнозом, а не измеренным результатом.
Допущения придуманы для примера и не являются ориентирами: 2 000 бизнес-пользователей, каждый проводит через ваш продукт $100 000 в год, плата за софт составляет $200 в месяц на пользователя.
При $2 400 в год платы за софт сценарий с 50 bps добавляет около 21% к выручке на пользователя. Убытки, поддержка и комплаенс вычитаются из этой суммы.
Маржу определяют три рычага:
О том, как процессинговая система работает в модели SaaS, читайте в нашем материале «Процессинговая система как SaaS-платформа».
Встроенные платежи делают вас частью денежного потока. Основные риски: мошенничество и чарджбэки субмерчантов, пользователи, потерянные на онбординге, обращения по выплатам и спорам и сохраненные карты, привязанные к одному провайдеру. Для каждого риска есть мера контроля, которую нужно ввести до запуска, а не после первого убытка.
| Риск | Что идет не так | Как снизить |
|---|---|---|
| Убытки субмерчантов | Если договор с пользователями заключаете вы, их чарджбэки или отрицательный баланс ложатся на вас, а затем на эквайера | Андеррайтинг по уровню риска, резервы и лимиты транзакций для каждого пользователя |
| Мошенничество на страницах оплаты пользователей | Украденные карты приближают уровень мошенничества к порогам программ платежных систем | Антифрод-инструменты и правила 3DS до авторизации |
| Отток на онбординге | Пользователи подключают платежи и не завершают KYC | Собирайте данные KYC внутри продукта и отслеживайте время до первого платежа |
| Нагрузка на поддержку | Вопросы по выплатам и спорам превращаются в ваши тикеты | Дайте пользователям отчеты о выплатах и раздел споров в их бэк-офисе |
| Привязка токенов | Сохраненные карты принадлежат одному эквайеру, и его смена ломает продления | Храните токены в хранилище шлюза, которое контролируете вы, а не у одного эквайера |
Если вы выставляете счета только собственным подписчикам, проще подключить универсального платежного провайдера или merchant of record (реселлера, который продает ваши подписки от своего имени и берет на себя налоги и платежный комплаенс). Если оборот ваших пользователей невелик, реферальное партнерство принесет доход без новой ответственности. Переходите на собственный PayFac или шлюз, когда оборот окупает риск-команду, резервы и комплаенс.
Выбирайте исходя из того, что нужно вашим пользователям: быстрый онбординг, способы оплаты, привычные их клиентам, надежные продления, понятные выплаты и ваш собственный бренд. Затем проверьте то, за что отвечаете вы сами: ответственность, охват PCI DSS и свободу менять эквайеров. Задайте каждому поставщику вопросы ниже.
| Область | Вопрос поставщику |
|---|---|
| Субмерчанты | Можно ли управлять пользователями в иерархии, с настройками и лимитами для каждого? |
| Онбординг | Может ли мой продукт передавать данные KYC через API и показывать пользователю статус? |
| Рекуррентные платежи | Помечаются ли продления как инициированные мерчантом? Какие сетевые токены и варианты повторов поддерживаются? |
| Движение средств | Кто держит средства, как разделяются платежи и когда пользователи получают выплаты? |
| Эквайринг | Можно ли подключить нескольких эквайеров и маршрутизировать платежи между ними? |
| Переносимость токенов | Можно ли перенести сохраненные карты к новому эквайеру без повторного запроса у клиентов? |
| Комплаенс | Сертифицирована ли платформа по PCI DSS Level 1? Какая интеграция дает мне минимальный охват? |
| Бренд | Несут ли платежные страницы, письма и бэк-офис мерчанта только мой бренд? |
Переносимость токенов легко упустить, а при смене эквайера она обходится дорого. В одном из наших кейсов PSP, чей эквайер перестал работать, сохранил базу рекуррентных платежей: токены были перенесены за одну неделю.
Более широкий обзор поставщиков есть в нашем руководстве о том, как выбрать White-Label платежную платформу.
eComCharge предоставляет White-Label онлайн-шлюз beGateway, который PSP, банки-эквайеры и программные платформы запускают под своим брендом. Для SaaS-платформы это максимум контроля над ценами и эквайерами: собственный брендированный шлюз, подключенный к выбранным вами эквайерам.
Установка eComCharge по модели SaaS занимает от 1 недели, установка на ваших серверах от 3 месяцев.
Стоимость eComCharge зависит исключительно от ваших задач, поэтому свяжитесь с отделом продаж, чтобы получить предложение.
SaaS платежная платформа представляет собой платежный стек, который программная платформа использует, чтобы ее пользователи принимали разовые и рекуррентные платежи прямо в продукте. В него входят платежный шлюз, один или несколько эквайеров, инструменты для хранения учетных данных карт, онбординг мерчантов, разделение платежей и выплаты. Платформа зарабатывает долю процессинговой маржи с оборота своих пользователей.
Зарегистрированный PayFac подключает своих пользователей как субмерчантов по мастер-договору с эквайером и несет финансовую ответственность за их транзакции. В модели PayFac-as-a-service эту роль берет на себя провайдер, а ваши пользователи становятся его субмерчантами внутри вашего продукта. White-Label платежный шлюз дает вам собственный брендированный шлюз, подключенный к выбранным вами эквайерам, с контролем над ценами и маршрутизацией.
Нет. Многие платформы начинают с партнерской (реферальной) модели или PayFac-as-a-service, где андеррайтинг и убытки в основном остаются у провайдера. Регистрироваться как PayFac имеет смысл, когда оборот пользователей окупает риск-команду, резервы, валидацию PCI DSS и требования эквайера, ведь PayFac отвечает за каждую транзакцию субмерчанта.
В Европейской экономической зоне PSD2 требует строгой аутентификации клиента (SCA), когда платеж инициирует плательщик. Первый платеж, при котором сохраняются данные карты, проходит 3-D Secure. Продления, которые платформа инициирует на согласованных условиях, считаются инициированными мерчантом, поэтому повторная аутентификация держателя карты обычно не нужна. Правила в других странах отличаются: в Казахстане их стоит сверить с требованиями НБК. Каждое продление нужно правильно помечать, чтобы эмитент его распознал.
Сетевой токен заменяет номер карты для конкретного мерчанта, а платежная система и эмитент обновляют его при перевыпуске карты (если эмитент поддерживает обновление токенов), поэтому меньше продлений срывается из-за устаревшей карты. Visa сообщает о росте уровня авторизаций на 4,6% в мире для токенизированных CNP-транзакций по сравнению с номером карты.
Merchant of record подходит компании, которая продает только собственные подписки и хочет переложить налоги, НДС и платежный комплаенс на продавца записи. Но он не позволяет вашим пользователям принимать платежи от их клиентов. Для этого нужна модель встроенных платежей: реферальная, PayFac-as-a-service, собственный PayFac или White-Label шлюз.
Охват зависит от того, где вводятся данные карты. Платежная страница и поля на стороне шлюза не пропускают номера карт через ваши серверы, и охват остается небольшим, а прямой API полностью включает ваши системы в охват. По правилам Visa PayFac также должен обеспечивать соответствие PCI DSS своих субмерчантов. Требования к валидации уточняйте у эквайера.
Стоимость зависит от модели развертывания, оборота ваших пользователей, нужных подключений к эквайерам и способов оплаты, а также от доработок. Цена eComCharge определяется исключительно вашими задачами, поэтому свяжитесь с отделом продаж, чтобы получить предложение.
eComCharge разрабатывает и предоставляет сертифицированную по стандарту PCI DSS Level 1 White Label платформу для обработки платежей beGateway для поставщиков платежных услуг и оркестрации платежей.
Как PSP защититься от внезапного отключения эквайером, сбоя или снижения лимитов: риск концентрации, триггеры платежных систем и андеррайтинга, резервные эквайеры, переносимые токены, распределение объема, план действий при сбое, затраты и кому это не нужно.
Руководство по каскадированию платежей для PSP и банков-эквайеров: мягкие, жёсткие и технические отказы, коды ответа Visa, проектирование каскада, защита от двойных списаний, 3-D Secure, правила платёжных систем, метрики возврата и случаи, когда каскад не нужен.
Руководство для PSP, банков и эмитентов электронных денег, которые добавляют переводы между физлицами через API: как работают списание и зачисление, правила push-платежей платежных систем, лицензии и AML, KYC-лимиты, антифрод и варианты интеграции.
Что входит в программное обеспечение для PSP, кто пользуется каждым модулем, что нужно для работы со множеством мерчантов, как считаются комиссии и выплаты, разработка или White-Label и какие обязанности по комплаенсу остаются за вами.
Практическое руководство по запуску платежного сервис-провайдера: выбор модели, договор с эквайером, лицензирование, PCI DSS, выбор платформы, статьи затрат и план запуска в 9 шагов.
Как PSP, банки-эквайеры и эмитенты электронных денег подключают high-risk мерчантов: какие MCC считаются рискованными, проверки KYB, UBO и санкций, андеррайтинг и резервы, регистрация и мониторинг в Visa, что автоматизировать и как сохранять доказательную базу.