Платёжный шлюз несёт один платёж в один банк-эквайер. Оркестрация стоит над несколькими шлюзами, выбирает, кому отдать платёж, и переводит их разные ответы на один язык. Это не конкуренты. Шлюз без оркестрации работает, а оркестрация без шлюза под ней — нет.
Это короткий ответ. Дальше — что на самом деле закрывает каждый слой, где стык между ними ползёт и как понять, к какому из них относится ваша проблема.
Что такое платёжный шлюз
Ваш платёжный шлюз — это сервис, который берёт данные карты с checkout и шлёт запрос на авторизацию в банк-эквайер от вашего имени.
У него четыре работы. Принять данные карты, защитить их в канале, говорить на протоколе банка и вернуть вам «да» или «нет». Всё остальное, что продаётся под словом «шлюз», стоит сверху этих четырёх.
Слово используют широко, и отсюда половина путаницы. Спросите пять вендоров, что такое шлюз, — получите пять ответов: большинство из них продаёт под тем же словом ещё и эквайринг с антифродом.
Что такое оркестрация платежей
Оркестрация платежей — это работа с несколькими провайдерами через одну интеграцию, где правила решают, куда пойдёт каждый платёж.
Слой держит подключения, правила маршрута и одну общую модель платежа. Пришёл отказ — слой пробует следующего провайдера, а ваш checkout об этом даже не знает. Механика самого слоя разобрана в статье что такое оркестрация платежей; здесь речь только о границе между двумя слоями.
Что такое платформа оркестрации платежей
Платформа оркестрации — это тот же слой, только купленный. Вы получаете готовые коннекторы, движок правил и отчётность, вместо того чтобы всё это писать.
Ключевое слово — сверху. Платформа не отменяет ваши договоры со шлюзами. Она встаёт над ними и вызывает их. Шлюзы остаются. Уходит код в checkout, который знал про каждого из них.
Дальше покупателю обычно нужен список требований к продукту. Это отдельный разговор — он в статье софт для оркестрации платежей: что он обязан уметь. А если вам интереснее не витрина требований, а сама механика внутри, загляните внутрь слоя оркестрации.
Разница построчно
Вот тот же раздел, каким он виден в договоре и в коде.
| Вопрос | Платёжный шлюз | Слой оркестрации |
|---|---|---|
| Со сколькими провайдерами говорит | С одним эквайером, изредка с парой | Со многими шлюзами |
| Кто решает, куда идёт платёж | Никто. Дорога одна | Правила плюс живые сигналы |
| У кого ваш мерчант-аккаунт | У эквайера за ним | Ни у кого. Своих нет |
| Кто двигает деньги | Эквайер | Никто |
| Что возвращает | Свои коды статусов | Один общий словарь |
| Где лежат сохранённые карты | Обычно в его хранилище | В его или в вашем |
| Кто ведёт чарджбек | Эквайер, через него | Он только показывает кейс |
Четвёртую строку стоит прочитать дважды. Слой оркестрации не касается ваших денег. Это слой решения и перевода, а средства идут от держателя карты к эквайеру и на ваш счёт ровно как раньше.
Один этот факт снимает половину вопросов на встречах с вендорами. Сроки зачисления не меняются. Ставка эквайринга не меняется. Доля чарджбеков в день включения слоя тоже не меняется.
Как два слоя работают вместе, по шагам
Один платёж, оба слоя, по порядку.
1. Checkout собирает карту. Или это делает hosted-страница. Запомните развилку: именно она решит ваш PCI-скоуп.
2. Слой выбирает провайдера. Сначала правила, потом фильтры. Sandbox-аккаунты выпадают из боевого трафика. Провайдеры, которые не тянут этот метод, выпадают тоже.
3. Слой переводит. Ваша единая форма запроса превращается в то, что хочет конкретный шлюз: его имена полей, его формат суммы, его подпись.
4. Шлюз делает банковскую часть. Он идёт к эквайеру, эквайер — в платёжную систему, она — в банк-эмитент. Два звена из трёх живут на рельсах, которыми в этой цепочке не владеет никто.
5. Случается 3DS, если случается. Держателя карты может унести на страницу его банка. Куда именно уедет клиент, решает шлюз, и только он.
6. Ответ приходит словами шлюза. Слой переводит его в общий статус и, если отказ был мягким, может отдать платёж следующему провайдеру.
Шаги 3 и 6 — это и есть вся ценность слоя. Остальное в списке случилось бы и без него.
Пять шлюзов — пять диалектов
Вот та часть, которую страницы вендоров пропускают. В платформе, которую я делаю, работает пять эквайринговых интеграций. Две из них живут внутри банков, остальные независимы, и для кода все пять — шлюзы. Ни одна пара из пяти не совпадает ни в чём, что видно на уровне протокола.
| Интеграция | Подпись запроса | Формат суммы | Полей в кредах |
|---|---|---|---|
| UPC | RSA SHA-512, ваш PEM-ключ | Целое в копейках | 6, из них 3 обязательных |
| Ощадбанк | HMAC-SHA1 по собранной MAC-строке, hex-ключ | Строка с двумя знаками | 10, из них 3 обязательных |
| PayLink | HMAC-SHA1 по «ключ + base64 тела + ключ» | Строка с двумя знаками | 4, из них 2 обязательных |
| LiqPay | SHA1 от «ключ + base64 тела + ключ», затем base64 | Обычное дробное число | 3, из них 2 обязательных |
| Hutko | SHA1 от значений, отсортированных и склеенных вертикальной чертой | Целое в копейках | 4, из них 2 обязательных |
Посмотрите на колонку суммы. Два шлюза из пяти ждут 1250 за двенадцать пятьдесят. Ещё два ждут строку 12.50. Один ждёт число. Ошиблись в одну сторону — списали в сто раз меньше. Ошиблись в другую — списали в сто раз больше и узнали об этом от клиента.
Теперь на число полей. Двадцать семь полей учётных данных на пять шлюзов, и ни одна пара не называет идентификатор мерчанта одинаково. UPC хочет Merchant ID и Terminal ID. Ощадбанк хочет Merchant и Terminal. LiqPay хочет публичный ключ.
У троих есть поле private_key, и это три разные вещи: RSA-ключ в PEM у UPC, общий секрет у PayLink, соль для SHA1 у LiqPay. Подставьте одно вместо другого — ошибки не будет. Будет подпись, которая не сходится никогда, и тикет в поддержку на неделю.
Подпись работает в обе стороны. Шлюз подписывает колбэк вам, и проверить эту подпись нужно раньше, чем поверить хоть одному полю. Колбэк UPC вы проверяете сертификатом X.509, который берёте у них. Колбэк LiqPay — тем же общим секретом, каким подписывали запрос. Ощадбанк собирает четыре разные строки для подписи: на авторизацию, на отмену, на списание и на приходящий ответ. Возьмёте не ту — проверка упадёт, а внятной причины в логе не будет. Именно этот код проверки забывают написать. Именно он стоит между вами и поддельным колбэком, который пометит неоплаченный заказ оплаченным.
Проблема словаря статусов
Каждый шлюз придумал свой список ответов. Задача слоя — свести их в один список, который умеют считать ваши отчёты.
| Интеграция | Как выглядит ответ | Кодов в маппинге |
|---|---|---|
| PayLink | Один resultCode | 63 |
| UPC | Один TranCode | 25 |
| LiqPay | Одно слово статуса | 22 |
| Ощадбанк | ACTION и RC, читаются вместе | 14 действий, 60 кодов |
| Hutko | Слово статуса, смысл задаёт сам вызов | 3 отдельные карты |
Всё это сводится к 12 статусам платежа и 15 причинам отказа. Около двух сотен чужих слов превращаются в двадцать семь ваших.
В этой таблице спрятаны три ловушки, и ни одна не видна из спецификации.
Одно слово, два смысла. Hutko отдаёт hold в статусе заказа — значит, деньги захолдированы. Hutko отдаёт hold и в ответе на списание — а тут это отказ. Слово одно, смысла два, и какой из них ваш, говорит только сам вызов.
Успех, который не похож на успех. PayLink считает успешными 100, 101 и 102: полная сумма, частичная сумма и только сумма покупки. Признайте отказом всё, что не 100, — и откажетесь от денег, которые банк уже отдал.
Отказ, который не отказ. Код 131 у UPC значит, что нужна дополнительная аутентификация. Код 601 значит, что клиент ушёл, не закончив. Ни то ни другое не «нет» от банка, но оба попадут в отказы, если инструкцию никто не читал. У Ощадбанка так же ведут себя действия 10 и 11: первое просит OTP, второе — подтвердить случайную сумму.
У последней ловушки есть жало. В ответе Ощадбанка 10 в поле ACTION значит «ждём OTP», а 10 в поле RC — «одобрено частично». Цифры те же, поле другое, исход противоположный.
Поток, который не сводится к одному виду
Здесь красивая картинка ломается, и об этом честнее сказать прямо.
В нашем контракте провайдера есть один метод, который завершает 3DS после возврата клиента из банка. Из пяти шлюзов его реализует ровно один — Hutko, парой вызовов «шаг 1» и «шаг 2». Остальные четыре возвращают понятный отказ, и каждый по своей причине.
- UPC проводит 3DS на своей платёжной странице, так что завершать нечего.
- LiqPay делает всё внутри и сообщает результат позже.
- PayLink закрывает круг колбэком
getTranState. - Ощадбанк закрывает его колбэком
BACKREF.
Слой оркестрации выравнивает имена полей, суммы и коды статусов. Он не выравнивает то, куда уедет браузер клиента. Один поток забирает экран себе, другой нет, и никакой адаптер не сделает их одинаковыми.
Отсюда честная версия «одной интеграции»: одна интеграция для вашего сервера и две-три формы checkout, про которые фронтенд всё равно обязан знать. Кто обещает вам единицу, тот не собирал в одном продукте redirect-шлюз и host-to-host шлюз.
Где граница ломается на практике
После запуска кусаются пять вещей. Все пять сидят ровно на шве между слоями.
Часть ограничений остаётся за шлюзом, что бы ни стояло сверху. UPC откажет в списании, когда с авторизации прошло 30 дней, и ответит кодом 506. Никакое правило маршрута этот срок не сдвинет. Слой умеет предупредить заранее — и больше ничего.
Токены остаются там, где родились
Шлюз, который хранит карты ваших клиентов, выдаёт вам токен. Этот токен работает с этим шлюзом. Для соседнего шлюза он пустое место.
Доведите мысль до конца — и обещание рассыпается. Если сохранённые карты лежат в хранилище шлюза A, повторить неудавшееся продление на шлюзе B нельзя: в момент авторизации никто снаружи A не превратит этот токен обратно в номер карты. Первая попытка маршрутизируется, потому что карта у вас в руках. Все последующие списания привязаны к тому, кто её сохранил.
Выходов два, и оба чего-то стоят.
- Хранить данные карты у себя. Это втягивает хранилище в ваш PCI-скоуп со всеми последствиями.
- Получить сетевые токены на своё имя. Жить с ними легче, договориться дольше: это разговор с платёжными системами и эквайером, а не правка конфига.
Наш сервис хранения карт пошёл первым путём. Номера шифруются через HashiCorp Vault Transit ключом aes256-gcm96, а ключ настроен на ротацию каждые 2160 часов — это 90 дней. Цифра выбрана нами, а не стандартом: требование 3.7.4 PCI DSS v4.0.1 просит определить криптопериод и менять ключ по его окончании, а длину оставляет на вас.
PCI-скоуп идёт за формой карты, а не за слоем
Оркестрация сама по себе не двигает ваш PCI-скоуп. Его двигает то, где клиент набирает номер.
Форма отдаётся с hosted-страницы и вашего сайта не касается — вы в самой лёгкой анкете. Форма стоит на вашей странице, пусть даже во фрейме под вашим контролем, — вы в тяжёлой. Слой маршрутизации за спиной на это не влияет.
Два требования делают это осязаемым, и оба перестали быть необязательными 31 марта 2025 года. Требование 6.4.3 говорит: каждый скрипт на платёжной странице должен быть разрешён, внесён в инвентарь и проверен на целостность. Требование 11.6.1 говорит: изменения этой страницы надо отслеживать, минимум раз в неделю.
Тут есть поворот, о котором стоит знать. В январе 2025 года PCI Security Standards Council убрал оба из SAQ A и заменил их критерием допуска: подтвердите, что ваш сайт не подвержен атакам через скрипты, — или возьмите такое подтверждение письмом у провайдера. Бумаги стало меньше, ответственности столько же. Если вы отчитываетесь по SAQ A-EP или SAQ D, оба требования работают в полном объёме.
Вы платите за оба слоя
Шлюз берёт с вас за транзакцию. Платформа оркестрации тоже берёт, и обычно тоже за транзакцию.
Маршрут по стоимости окупается лишь тогда, когда разрыв между самым дешёвым и самым дорогим провайдером больше комиссии слоя. На одном рынке с одной валютой и почти равными ставками он часто меньше. Посчитайте это на реальном объёме прошлого месяца до того, как из идеи вырастет бизнес-кейс.
Сверка сначала усложняется
Один шлюз — один файл выписки. Пять шлюзов — пять файлов, пять расписаний, пять способов назвать возврат и пять вариантов удержать комиссию до того, как деньги дойдут.
Один вопрос отделяет серьёзные платформы от остальных: по чему идёт сопоставление? По вашему номеру заказа, по идентификатору транзакции самого шлюза или по сумме и дате? Только первое переживёт частичный возврат и удержание комиссии в один день.
Слой сводит воедино платёжную картину в день включения. Денежная картина остаётся такой же рваной, как ваш список провайдеров, — пока платформа не научится матчить выписки. Спрашивайте об этом отдельно: этот кусок достаётся финансистам, и его никто не показывает на демо.
Упасть могут оба слоя
Вы убрали пять интеграций и добавили одну штуку, через которую теперь идёт каждый платёж. Обычно это правильный размен. Но это размен.
Спросите, что происходит во время деплоя, попросите историю инцидентов и узнайте, можно ли достучаться до шлюза напрямую, если слой молчит. Продукт, который не отвечает на последний вопрос, тихо сделал себя единственной точкой отказа.
Шлюз, процессор, эквайер, агрегатор: кто есть кто
Четыре слова используют как синонимы. Они не синонимы, и разница решает, кому звонить, когда сломалось.
- Эквайер. Банк с лицензией платёжных систем. У него ваш мерчант-аккаунт, он же переводит деньги. Так умеет только банк.
- Процессор. Технический движок за эквайером. Часто отдельная компания. Напрямую вы с ним говорите редко.
- Шлюз. API перед всей этой конструкцией. Это то, что видит ваш код.
- Агрегатор, он же платёжный фасилитатор. Тот, чьим мерчант-аккаунтом вы пользуетесь вместо своего. Быстрее стартовать, меньше контроля потом.
- Слой оркестрации. Над всеми ними. Решает, какому из ваших шлюзов достанется этот платёж.
Слово middleware в выдаче обычно значит то же самое, что оркестрация, только описанную со стороны инженера, а не коммерсанта. Услышали его — спросите, маршрутизирует продукт или только переводит. Это разные вещи с одинаковой презентацией.
Нужна ли вам платформа оркестрации платежей
Скорее нет, если один шлюз закрывает ваш рынок и процент одобрений вас устраивает. Слой поверх работающей схемы даёт лишние детали и не решает ничего.
Одного шлюза хватает, пока верно всё это:
- один рынок, одна валюта, один набор карточных брендов;
- один эквайер, который ни разу не грозил отключить вашу вертикаль;
- перебой, который вы переживёте, просто переждав его;
- никто в финансах не спрашивает, сколько стоит платёж в разрезе бренда и страны.
Вы из него выросли, как только верны хотя бы два пункта:
- У вас уже два провайдера или больше. Что-то между ними уже маршрутизирует. Сейчас это
ifв checkout, и помнит о нём один разработчик. - Сохранённые карты заперты. Продление можно повторить только на том шлюзе, который держит токен, и вы это уже заметили.
- Падение одного провайдера останавливает выручку. Не замедляет. Останавливает.
- Вы заходите на рынок, где ваш шлюз слаб. Обычно решает наличие локальных методов.
- Стоимость провайдера стала вопросом совета директоров. Как только спросили цену в разрезе брендов, плоская ставка перестаёт работать.
Быстрая проверка на минуту. Откройте отчёт за прошлый месяц. Сколько в нём провайдеров? Какой процент одобрений в самой слабой стране, не в среднем? Если завтра в десять утра ляжет основной шлюз, кто поменяет маршрут и нужен ли для этого релиз?
Если в третьем ответе есть слово «релиз», вы за недостающий слой уже платите. Просто счёт за него вам не выставляют.
Что сделать на этой неделе
Начните с трёх цифр, а не с проекта.
Разложите процент одобрений по странам. Общие 92% умеют прятать 60% на рынке, где эмитенты режут иностранные карты. Этот разрез запустил больше проектов оркестрации, чем любая презентация вендора.
Прочитайте три главные причины отказов. Сгруппируйте прошлый месяц по кодам, а потом спросите, какие из них второй провайдер мог бы вытянуть. Мягкие отказы повторять стоит. Украденную карту не спасёт никто и нигде.
Спросите у шлюза, чьи токены. Возьмите ответ письменно до всех остальных планов. Он решает, возможна ли маршрутизация на второй попытке или только на первой, а дальше всё вытекает отсюда.
Эти три цифры скажут вам больше любой сравнительной таблицы. Если они показывают на проблему маршрута, следующий вопрос — куда маршрутизировать.
А если вы пока только выясняете, какие эквайеры и методы вообще работают в нужных вам странах, наш справочник провайдеров обойдётся дешевле, чем круг звонков в отделы продаж.
Стандарты и номера требований сверены с PCI DSS v4.0.1 1 сентября 2026 года.
