Платіжний шлюз несе один платіж до одного банку-еквайера. Оркестрація стоїть над кількома шлюзами, обирає, кому віддати платіж, і перекладає їхні різні відповіді однією мовою. Це не конкуренти. Шлюз без оркестрації працює, а оркестрація без шлюзу під нею — ні.
Це коротка відповідь. Далі — що насправді закриває кожен шар, де стик між ними повзе і до якого з них належить саме ваша проблема.
Що таке платіжний шлюз
Ваш платіжний шлюз — це сервіс, який бере дані картки з 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 року.
