Практическое руководство по запуску платежного сервис-провайдера: выбор модели, договор с эквайером, лицензирование, PCI DSS, выбор платформы, статьи затрат и план запуска в 9 шагов.
Провайдеры токенизации платежей заменяют номер карты токеном и хранят связь между ними: платежные системы, хранилища платежных шлюзов, отдельные хранилища (vault) и эквайеры. Руководство написано для PSP, банков-эквайеров, организаций электронных денег и платформ, которые решают, где будут храниться карты их мерчантов и кто будет ими управлять.
Провайдер токенизации генерирует токены, которые заменяют основной номер карты (PAN), хранит PAN за ними и превращает токен обратно в платежные реквизиты в момент платежа. Такой обмен может выполнить только провайдер, поэтому тот, кто им управляет, контролирует сохраненные карты.
У термина две роли. В понимании платежных систем token service provider означает сервис платежной системы, который выпускает сетевые токены, например Visa Token Service. Сторона, которая запрашивает у него токены, называется token requestor: это мерчант, PSP или платежный шлюз. eComCharge, например, сертифицирован Visa как token requestor.
В повседневной речи «провайдером токенизации» называют и любое хранилище, которое выпускает собственные токены для хранимых данных карт. Именно с этим значением большинство операторов сталкивается первым, потому что их шлюз уже так работает.
Система, которая хранит каждый PAN, сопоставляет его с токеном и держит ключи для его защиты. В White-Label платежном шлюзе хранилище находится внутри платформы, а мерчанты получают только токены.
Токенизация не является шифрованием. Зашифрованные данные карты может расшифровать тот, у кого есть ключ. Токен не расшифровывают, а ищут: PAN возвращается только из таблицы соответствий хранилища и только тем системам, которым хранилище это разрешает.
Карту токенизируют один раз (при первом платеже или когда держатель сохраняет ее), и все последующие списания идут по токену. Свою часть работы выполняют ваш шлюз, токен-сервис платежной системы, эквайер и эмитент. После первого шага мерчант никогда не держит у себя PAN.
Платежная страница или виджет, который ваш шлюз размещает для мерчанта, принимает номер карты, срок действия и код безопасности и отправляет их в шлюз, а не на серверы мерчанта.
Шлюз записывает PAN в хранилище и вместе с результатом платежа возвращает мерчанту шлюзовой токен. Мерчант хранит у своего клиента только этот токен.
В роли token requestor шлюз запрашивает у токен-сервиса платежной системы сетевой токен для этой карты и мерчанта. Платежная система проверяет у эмитента, что карта за токеном содержит действующие реквизиты.
Для повторного или рекуррентного платежа мерчант передает шлюзовой токен, сумму и тип транзакции. Если к платежу, который инициирует держатель карты, применяется 3-D Secure, сначала его аутентифицирует ваш 3DS-сервер.
Шлюз меняет шлюзовой токен на сетевой и криптограмму, созданную для этой транзакции, и отправляет их эквайеру. Эквайер передает запрос на авторизацию в платежную систему.
Платежная система сопоставляет сетевой токен с PAN и передает запрос эмитенту, который одобряет или отклоняет платеж. Клиринг и расчеты проводит эквайер, отправивший платеж.
Каким бы токеном ни прошел платеж, чарджбэк получает эквайер, который его обработал, а вы остаетесь финансово ответственны перед каждым эквайером за своих мерчантов. Расчеты тоже следуют за эквайером, а не за типом токена.
Типов четыре: токен-сервисы платежных систем, хранилище внутри вашего шлюза или платформы PSP, отдельный vault стороннего оператора и эквайер или процессор, который хранит карты за вас. Они различаются тем, кто выпускает токен, где его можно использовать и кто может забрать его с собой при уходе.
| Тип | Кто выпускает токен и хранит PAN | Где работает токен | Кто его контролирует |
|---|---|---|---|
| Токен-сервис платежной системы | Платежная система выпускает сетевой токен; PAN хранят эмитент и платежная система | У любого эквайера, поддерживающего сетевые токены, для мерчанта, на которого он выпущен | Token requestor, который его запросил |
| Хранилище шлюза или PSP | Хранилище вашей платформы | У всех эквайеров, подключенных к шлюзу | Вы как оператор шлюза |
| Отдельный vault | Стороннее хранилище вне шлюза | У шлюзов и эквайеров, которым vault передает данные карт | Оператор vault по договору с вами |
| Эквайер или процессор | Собственная система эквайера | Только у этого эквайера | Эквайер |
Токен-сервис платежной системы работает за вашим хранилищем, а не вместо него: шлюз подключается к нему как token requestor. У Visa это Visa Token Service, который заменяет номера карт Visa токенами. У Mastercard есть Secure Card on File, который в конце 2026 года заменяет Mastercard Digital Enablement Service (MDES) for Merchants.
Хранилище внутри шлюза служит вариантом по умолчанию для большинства операторов. Одна интеграция закрывает прием карт, хранилище, сетевые токены и маршрутизацию на все подключенные эквайеры. В модульной платформе хранилище остается отдельным компонентом того же шлюза.
Отдельное хранилище держит карты вне шлюза и передает данные карты тому шлюзу или эквайеру, которого вы выбираете для каждого платежа. Такая схема часто встречается в оркестрации платежей, объединяющей несколько шлюзов, и добавляет еще один договор и еще одно звено в каждый платеж.
Эквайер, который хранит карты за вас, возвращает собственные токены, по которым не может списывать ни один другой эквайер. Это самый простой старт при одном эквайере и самый трудный выход, как показывает раздел о переносимости.
Шлюзовой токен выпускает ваше хранилище, и он работает только внутри платформы, которая его создала. Сетевой токен выпускает платежная система: он заменяет PAN вплоть до платежной системы и проверяется у эмитента как действующие реквизиты. Большинство операторов используют оба: мерчант хранит шлюзовой токен, а шлюз сетевой.
| Критерий | Шлюзовой токен | Сетевой токен |
|---|---|---|
| Кто выпускает | Хранилище вашего шлюза | Токен-сервис платежной системы |
| Что получает эквайер | PAN, который шлюз берет из хранилища | Сетевой токен и криптограмму для этой транзакции |
| Когда эмитент перевыпускает карту | Сохраненная карта устаревает, если ее не обновляет account updater | Платежная система сверяет карту за токеном с эмитентом |
| Переносимость | Переходит вместе со шлюзом между эквайерами | Не привязан к процессору, выпускается для одного мерчанта |
| Покрытие | Все карты, которые принимает шлюз | Только платежные системы, к которым шлюз подключен как token requestor |
Сетевые токены влияют и на уровень одобрений. Visa сообщает, что токенизированные транзакции без присутствия карты показывают рост авторизаций на 4,6% в мире по сравнению с PAN.
Сетевые токены остаются актуальными благодаря платежной системе: Visa сверяет с эмитентом, что карта за каждым токеном стоят действующие реквизиты, и в своем справочном разделе о токенизации описывает сетевые токены как содержащие актуальные данные. Visa Token Service также позволяет выпускать токены по сохраненным реквизитам с устаревшим сроком действия.
Шлюзовым токенам для актуальности нужен account updater или новая карта от клиента. Этот разрыв важнее всего в рекуррентных платежах SaaS и других моделях с сохраненной картой.
Согласно документации для разработчиков, Mastercard выведет MDES for Merchants (M4M) из эксплуатации в конце 2026 года. Текущим пользователям M4M нужно интегрироваться с Secure Card on File (SCOF) и перенести токены. Спросите любого провайдера, каким сервисом Mastercard он пользуется сегодня.
Переносимость токенов показывает, продолжат ли сохраненные карты работать при смене эквайера, шлюза или хранилища. Токены в собственном хранилище шлюза переходят с вами между эквайерами. Токены эквайера остаются у него. Без переносимости каждому клиенту с сохраненной картой придется ввести ее заново.
От переносимости зависит и то, что маршрутизация платежей может делать с сохраненными картами: платеж по сохраненной карте можно отправить второму эквайеру, только если тот может списать по токену.
В одном из наших кейсов high-risk PSP за одну ночь лишился эквайера. eComCharge извлек токенизированные данные карт, которые мог передать прежний эквайер, сгенерировал токены для нового эквайера и возобновил рекуррентные платежи без каких-либо действий клиентов. PSP перенес 95% доступных токенов примерно за неделю.
95% в этом кейсе означает долю технически доступных токенов. Перенести удалось не все, поэтому согласуйте условия выгрузки заранее, до того как она понадобится.
Цифры условные и придуманы для примера, это не бенчмарки. У вас 40 000 сохраненных карт с ежемесячными рекуррентными списаниями, средний платеж составляет 25 EUR. Эквайер уходит. Клиенты, которых просят ввести карту заново, делают это в 55% случаев.
| Условный показатель | Токены эквайера | Переносимые токены, 95% перенесено |
|---|---|---|
| Карты перенесены без действий клиента | 0 | 38 000 |
| Карты введены клиентами заново | 22 000 из 40 000 | 1 100 из 2 000 |
| Сохранено карт | 22 000 | 39 100 |
| Рекуррентный объем в месяц | 550 000 EUR | 977 500 EUR |
В этом примере переносимость сохраняет на 17 100 карт и 427 500 EUR ежемесячного объема больше. Ваши цифры зависят от доли повторного ввода и от того, что отдаст уходящий провайдер.
Токенизация сужает область PCI DSS для систем, которые хранят только токены и не могут превратить их обратно в номера карт. Хранилище, процесс детокенизации и все связанные с ними системы остаются в области. Токенизация не отменяет необходимости поддерживать и подтверждать соответствие.
PCI Security Standards Council описывает это в руководстве по токенизации, опубликованном в августе 2011 года для PCI DSS 2.0. Действующий стандарт: семейство PCI DSS v4.x, поэтому область каждой системы уточняйте у аудитора.
| Сторона | Что хранит | Позиция в PCI DSS |
|---|---|---|
| Мерчант, хранящий шлюзовые токены | Только токены, карта принимается на вашей платежной странице | Системы, которые хранят только токены и отделены от хранилища, могут оказаться вне среды данных держателей карт (CDE). Если мерчант может получить PAN, его среда в области |
| Вы как оператор шлюза | PAN в хранилище, таблица соответствий, ключи | В области как сервис-провайдер: для хранилища и всех связанных с ним систем |
| Вендор вашей платформы | Размещает и эксплуатирует ПО хранилища | Подтверждает соответствие платформы и дает письменное разделение ответственности. Область делится, а не передается |
| Оператор отдельного vault | PAN хранимых им карт | В области для своего хранилища. Ваши системы, которые отправляют ему или получают от него данные карт, остаются в области |
Раздел 4.1 того же руководства предупреждает: токены, которые можно использовать как платежный инструмент (high-value tokens), могут иметь для злоумышленника ту же ценность, что и данные карты. Такие токены могут попадать в область, даже если по ним нельзя получить PAN. Уточните у эквайера или платежных систем, какие требования применяются к вашим.
Передача хранилища сертифицированной платформе сокращает объем работы на вашей стороне, но часть требований все равно остается за вами. Требования к хранению данных карт в разных странах дополняются местным регулированием, поэтому в Казахстане их стоит также сверить с требованиями НБК.
Выбирайте сначала по контролю, потом по функциям. Решите, кто должен владеть токенами и статусом token requestor, затем проверьте покрытие сетевыми токенами по каждой платежной системе, область PCI DSS, обновление жизненного цикла и условия выхода. Задайте всем провайдерам одинаковые вопросы и получите ответы письменно.
Токенизация занимает лишь одну строку в более широкой оценке платформы. Остальные критерии описаны в руководстве о том, как выбрать White-Label платежную платформу.
Главные риски: привязка к токенам, которые нельзя выгрузить, хранилище, отказ которого останавливает все платежи по сохраненным картам, разное покрытие сетевыми токенами у платежных систем и high-value токены, привлекающие атаки. Для каждого есть известная мера контроля, они приведены в таблице.
| Риск | Что идет не так | Как снизить |
|---|---|---|
| Токены привязаны к эквайеру | Эквайер уходит или недоступен, и по его токенам нельзя списать нигде больше | Держите хранилище на уровне шлюза и подпишите условие о выгрузке с форматом и сроками |
| Отказ хранилища | Ни одну сохраненную карту нельзя списать, пока хранилище не восстановится | Спросите, как измеряется доступность хранилища и как оно изолировано от других компонентов |
| Неравномерное покрытие платежных систем | Карты одной платежной системы работают на сетевых токенах, остальные на сохраненных PAN с другим поведением обновлений | Отслеживайте долю сохраненных карт с сетевым токеном по каждой платежной системе |
| High-value токены | Украденный токен, которым можно инициировать платеж, используют для мошенничества | Привязывайте токены к одному мерчанту и мониторьте использование токенов на попытки фрода |
| Нет резервного маршрута для сохраненных карт | Рекуррентный платеж, отклоненный у одного эквайера, нельзя отправить другому | Используйте токены, по которым может списывать любой маршрут, чтобы каскадирование могло задействовать второго эквайера |
Сохраненные карты переживают сбой эквайера, только если токены от этого эквайера не зависят. В другом нашем кейсе медленный эквайер был изолирован за секунды.
Если ваш шлюз уже содержит хранилище, соответствующее PCI DSS, и подключен к токен-сервисам платежных систем, отдельный vault добавит договор, но не контроль. Если вы еще выбираете эквайера и лицензию, сначала прочитайте, как открыть процессинговую компанию. При одном эквайере и без сохраненных карт переносить пока нечего.
eComCharge выполняет токенизацию внутри своего White-Label шлюза. Карты токенизируются на платформе и хранятся в ее хранилище, а ваши мерчанты держат только токены для рекуррентных платежей, оплаты в один клик и возвратов. Поскольку хранилище находится на уровне шлюза, токены работают со всеми подключенными эквайерами.
Установка eComCharge в формате SaaS занимает от 1 недели, на ваших собственных серверах от 3 месяцев.
Стоимость eComCharge зависит от ваших задач, поэтому свяжитесь с отделом продаж, чтобы получить предложение.
Платформа, хранилище и подключение к токен-сервисам платежных систем описаны на странице White-Label платежного шлюза beGateway.
Провайдер токенизации заменяет номер карты (PAN) токеном, хранит номер карты за ним и превращает токен обратно в платежные реквизиты в момент платежа. Провайдером могут быть платежные системы, хранилище платежного шлюза, отдельный vault или эквайер, и тот, кто управляет хранилищем, контролирует сохраненные карты.
Типов четыре. Токен-сервисы платежных систем выпускают сетевые токены. Хранилище шлюза или PSP выпускает токены, которые работают со всеми эквайерами, подключенными к этому шлюзу. Отдельный vault хранит карты вне шлюза и передает их дальше. Эквайер или процессор выпускает токены, по которым может списывать только он. Большинство операторов сочетают хранилище шлюза и сетевые токены платежных систем.
Шлюзовой токен выпускает ваше хранилище, и он работает только внутри платформы, которая его создала; эквайер по-прежнему получает номер карты. Сетевой токен выпускает платежная система, он уходит к эквайеру вместе с криптограммой для каждой транзакции и проверяется у эмитента как действующие реквизиты. По словам Visa, сетевые токены содержат актуальные данные карты.
Токены в собственном хранилище шлюза уже работают со всеми эквайерами этого шлюза. Токены у эквайера или стороннего vault можно перенести, только если провайдер передает токенизированные данные, новый эквайер их принимает и форматы совместимы. В одном из наших кейсов PSP перенес 95% доступных токенов примерно за неделю.
Нет. Токенизация сужает область только для систем, которые хранят токены и не могут восстановить номер карты. Хранилище, процесс детокенизации и все связанные с ними системы остаются в области, а соответствие по-прежнему нужно поддерживать и подтверждать. Так сказано в руководстве PCI Security Standards Council по токенизации. Область каждой системы уточняйте у аудитора.
Нет. Зашифрованные данные карты может расшифровать любой, у кого есть ключ. Токен не расшифровывают, а ищут: номер карты возвращается только из таблицы соответствий хранилища и только тем системам, которым хранилище это разрешает. Большинство платформ используют оба механизма: шифруют номера карт внутри хранилища и выдают мерчантам токены.
Согласно документации Mastercard для разработчиков, MDES for Merchants будет выведен из эксплуатации в конце 2026 года. Текущим пользователям нужно интегрироваться с Secure Card on File и перенести токены. Если провайдер токенизации все еще работает через MDES for Merchants, запросите его план и сроки миграции до подписания договора.
Это зависит от модели развертывания, количества сохраненных карт, нужных токен-сервисов платежных систем и подключаемых эквайеров. В eComCharge токенизация входит в White-Label платежный шлюз. Стоимость eComCharge зависит от ваших задач, поэтому свяжитесь с отделом продаж, чтобы получить предложение.
eComCharge разрабатывает и предоставляет сертифицированную по стандарту PCI DSS Level 1 White Label платформу для обработки платежей beGateway для поставщиков платежных услуг и оркестрации платежей.
Практическое руководство по запуску платежного сервис-провайдера: выбор модели, договор с эквайером, лицензирование, PCI DSS, выбор платформы, статьи затрат и план запуска в 9 шагов.
Руководство для PSP, банков и платформ: собственная разработка, готовый продукт или White-Label, что можно настроить, как описать и запустить новый коннектор или схему выплат, от чего зависят стоимость и сроки и какие риски учесть.
Как PSP ведет портфель мерчантов на White-Label платформе: иерархия, онбординг и KYC, настройки магазинов, роли пользователей, мониторинг чарджбэков, выплаты и отключение мерчантов.
Для PSP, банков-эквайеров и эмитентов электронных денег: что включает платежный шлюз «все в одном», что остается вне его, один шлюз или несколько провайдеров и как проверить покрытие по каждому рынку.
Узнайте, как построить успешную бизнес-модель платежного шлюза в Центральной Азии. Узнайте о ключевых источниках дохода, бизнес-моделях и стратегиях для быстрого выхода на рынок в 2025 году.
Изучите, как работает white-label система для обработки и приема платежей по банковским картам и как она помогает компаниям быстро, безопасно и экономически эффективно запускать брендированные платежные решения. Узнайте о преимуществах и особенностях white-label платежных решений.