Оркестрація платежів — це шар між вашим checkout і платіжними провайдерами. Він вирішує, кому віддати конкретний платіж, надсилає його, читає відповідь і пробує іншого провайдера, якщо прийшла відмова. У вас лишається одна інтеграція замість п’яти, а правила маршрутизації змінюються без релізу коду.
Це коротка відповідь. Далі — як цей шар працює насправді, що в ньому ламається після запуску і як зрозуміти, чи потрібен він вам взагалі.
Що таке оркестрація платежів
Оркестрація платежів — це практика тримати кілька платіжних провайдерів за однією інтеграцією, з правилами, які вирішують, куди піде кожен платіж.
Розберіть слово — стане простіше. В оркестрі багато музикантів. Ніхто не просить скрипки грати ще й на барабанах. Хтось попереду вирішує, хто вступає. Оркестрація робить те саме з провайдерами: їх багато, а місце ухвалення рішення одне.
Без цього шару кожен провайдер — окремий проєкт. У кожного своя API, свій спосіб підписувати запити, свої коди помилок і своє уявлення про те, що таке «відмова».
Ось наскільки різними бувають ці деталі. У нашій платформі працює п’ять еквайерів, і жодні два не підписують запит однаково:
| Провайдер | Як підписується запит |
|---|---|
| UPC | RSA SHA-512 |
| Ощадбанк | HMAC-SHA1 |
| PayLink | HMAC-SHA1 |
| LiqPay | SHA1, Base64 |
| Hutko | SHA1 |
П’ять провайдерів — чотири схеми підпису. Нічого екзотичного тут немає. Це звичайна ціна розмови з банками. Шар оркестрації бере її на себе, і ваш checkout надсилає запит однієї форми, не знаючи жодної з цих схем.
Що таке платформа оркестрації платежів
Платформа оркестрації — це продукт, який дає вам цей шар готовим. У ньому вже є конектори до провайдерів, механізм маршрутизації і звітність зверху.
Роботу роблять три частини:
- Конектори. По одному на провайдера. Кожен перекладає ваш запит діалектом цього провайдера і перекладає відповідь назад.
- Механізм маршрутизації. Правила плюс живі сигнали. Він відповідає на одне питання щодо кожного платежу: кому його віддати.
- Спільна модель даних. Один запис платежу, один словник статусів, один звіт — незалежно від того, хто провів гроші.
Ось що дає «один словник статусів», на одному прикладі. Ощадбанк відповідає п’ятнадцятьма кодами результату. Більшість означають відмову, але три — ні: код 5 це відповідь емітента по 3DS, код 10 це перевірка OTP, код 11 просить клієнта підтвердити випадкову суму. Усі три означають «чекай», а не «ні».
Помилитесь тут — і завалите платіж, який був ще живий. У кожного провайдера свій такий список, і хтось має тримати в голові всі п’ять. Саме для цього і потрібна спільна модель.
Третя частина звучить нудно і важить найбільше. Коли кожен провайдер звітує своїми словами, ніхто в компанії не відповість на питання «який у нас відсоток схвалень цього тижня» без таблиці і суперечки. Спільна модель перетворює це питання на запит.
Детальніше про вимоги до платформи — в окремому матеріалі payment orchestration software: what it must do. Внутрішню будову шару розбираємо в what is a payment orchestration layer.
Як це працює по кроках
На слайді правила виглядають охайно. Насправді маршрутизація — це конвеєр, і кожна стадія може відкинути кандидата. Ось порядок, у якому працює наш механізм.
Крок 1. Завантажити правила. Правила прив’язані до однієї юридичної особи і можуть діяти за розкладом. Правило «тільки у вихідні» у вівторок просто відсутнє в наборі.
Крок 2. Перевірити блокування. Правило BLOCK зупиняє платіж до вибору провайдера. Так ви відсікаєте діапазон карт, країну або суму, не чіпаючи код.
Крок 3. Застосувати маршрут. Правило ROUTE називає пул провайдерів. Цей пул і стає списком кандидатів. Спрацювати може лише одне ROUTE-правило, і це перевіряється в момент збереження правил, а не в момент платежу. Правила, що перетинаються, — помилка конфігурації. Ловити її треба під час налаштування.
Крок 4. Взяти пул за замовчуванням. Жодне ROUTE-правило не підійшло? Тоді кандидатами стають усі акаунти провайдерів цієї юридичної особи.
Крок 5. Відсіяти за можливостями і середовищем. Пісочниця вилітає з бойового трафіку. Далі відсіюються провайдери, які фізично не приймуть цей платіж.
Тут ховається пастка, про яку варто сказати прямо. Наш каталог показує Click to Pay як підтримуваний метод у всіх п’яти еквайерів. Насправді криптограму гаманця на нашому власному checkout приймають лише два: Hutko і Ощадбанк. Решта троє підтримують гаманець на своїй сторінці. Слово в каталозі одне, інтеграції за ним різні.
Якби маршрутизація вірила каталогу, вона віддала б платіж провайдеру, який його не візьме. Клієнт побачив би помилку, якої не пояснює жодна панель. Тому перевірка можливостей читає інше, вужче джерело правди. Коли оцінюєте платформу, питайте, що саме читає її маршрутизація. «Підтримується» в маркетинговій таблиці і «підтримується» в коді — не завжди те саме слово.
Крок 6. Відсіяти за здоров’ям, відсортувати за вартістю. Здоров’я — це оцінка від 0 до 100 за рухомим вікном. Формула навмисно проста:
- 70% оцінки дає частка успішних запитів
- 30% дає час відповіді: менше секунди — максимум, десять секунд — нуль
- провайдер без свіжого трафіку отримує нейтральні 50, а не нуль
Усе, що нижче 40, вилітає. Решта сортується за вартістю, найдешевший перший. Він стає основним, другий за ціною — резервним.
Одне правило важить більше за решту п’яти. Якщо всі кандидати опустилися нижче порогу, фільтр здоров’я вимикається і кандидати повертаються. Провайдер у поганому стані кращий за відсутність провайдера. Платформа, яка завалює платіж, бо ніхто не виглядав здоровим, обрала чистоту метрики замість вашої виручки.
Один платіж через увесь конвеєр
Абстрактні кроки легко пропустити повз вуха. Ось один платіж, який іде через них.
Клієнт із Польщі платить 40 євро кредитною Visa. У мерчанта підключено чотири акаунти провайдерів.
- Правила. У мерчанта їх два. Одне діє лише в будні і сьогодні не працює. Лишається одне.
- Блокування. Правило, що лишилося, блокує платежі понад 5 000 євро. Наш — на 40, проходить.
- Маршрут. Жодне правило не називає пул для Польщі. Список поки не звужується.
- Пул за замовчуванням. Кандидатами стають усі чотири акаунти.
- Можливості і середовище. Один із чотирьох — пісочниця, вилітає. Лишається три. Клієнт платив звичайною карткою, фільтр гаманців не вмикається.
- Здоров’я і вартість. Один провайдер уже пів години віддає таймаути. Частка успішних запитів опустила його оцінку до 31 при порозі 40 — він вилітає. Лишається два. Для іноземної кредитної картки на цю суму рахується вартість, дешевший виграє.
Чотири кандидати перетворилися на основного і резервного за шість кроків і кілька мілісекунд. Нічого хитрого тут немає. Це бухгалтерія, зроблена послідовно, — саме те, що люди роблять погано, а код добре.
Тепер змініть одну деталь. Нехай усі три провайдери будуть нездорові. Крок 6 припиняє фільтрувати і віддає всіх трьох на сортування за ціною. Платіж усе одно піде. Ця єдина поведінка коштує вашій виручці більше, ніж будь-яке правило маршрутизації, яке ви колись напишете.
Хто цим користується
Мерчанти, які переросли одного провайдера, і платформи, що проводять гроші за інших.
На практиці це чотири групи:
Ті, хто продає за кордон. Провайдер, чудовий удома, за дві країни звідси часто посередній. Місцеві картки, місцеві методи і місцеві правила ведуть до місцевих провайдерів. Раптом їх у вас чотири.
Підписки. Їхня виручка тримається на продовженнях, а продовження зриваються з нудних причин: картка протермінована, банк відхилив першу спробу, емітент о третій ночі поводиться інакше. Спроба через іншого провайдера коштує їм реальних грошей.
Ризикові вертикалі. Тревел, ігри, маркетплейси — їх відключають без довгих попереджень. Другий живий провайдер для них не оптимізація, а безперервність.
Платформи і маркетплейси. Вони проводять гроші за продавців, тож успадковують географію і ризик усіх своїх продавців одразу.
Зверніть увагу, що спільного в цих групах. Це не розмір. Маленькому мерчанту, який продає в шести країнах, оркестрація потрібна більше, ніж великому з одним ринком і одним провайдером, що працює нормально.
Де воно ламається на практиці
Сторінки вендорів закінчуються на щасливому сценарії. Ось те, що кусається після запуску.
Резервна спроба не безкоштовна
Повторити відхилений платіж через другого провайдера звучить як чиста вигода. Це не так.
Частина відмов остаточна. Якщо картку вкрали або рахунок закрито, другий провайдер відмовить теж. Ви заплатили за ще один запит, додали секунди до оформлення і отримали другий запис у звіті. Гірше того, деякі емітенти читають повторні спроби на тій самій картці як ознаку шахрайства.
Повторюйте відмови, які означають «не зараз». Не повторюйте ті, що означають «ні». Платформа, яка повторює все підряд, — це не розумна маршрутизація, а дорогий шум.
Найдешевший не завжди найдешевший
Відсортувати за вартістю легко. Порахувати цю вартість правильно — ні.
Реальна ціна залежить від платіжної системи, типу картки, суми і методу. Провайдер, дешевший на локальному дебеті, буває дорожчим на іноземному кредиті. Якщо платформа сортує за плоскою ставкою, вона впевнено обиратиме не того провайдера і показуватиме вам охайний звіт про це.
Питайте, як рахується вартість конкретного платежу, а не тарифу в договорі.
Оцінка здоров’я відстає
Здоров’я міряється за вікном. У нас це година за замовчуванням. Вікно — компроміс, а не налаштування, яке можна поставити й забути.
Коротке вікно реагує швидко і смикається на шум. Довге стабільне, але повільно помічає провайдера, який почав падати десять хвилин тому. У будь-якому разі оцінка описує недавнє минуле, а не цю секунду. Маршрутизація за нею — це завжди маршрутизація за трохи застарілими даними.
Звірка стає складнішою
Один провайдер — один файл виписки. П’ять провайдерів — п’ять файлів, п’ять графіків, п’ять способів назвати повернення і п’ять наборів комісій, утриманих до зарахування.
Шар оркестрації зводить докупи вигляд платежів. Вигляд грошей він автоматично не зводить. Питайте, що відбувається після розрахунків, а не лише до авторизації.
Одна інтеграція стає однією залежністю
Ви прибрали п’ять інтеграцій. Ви додали одне місце, через яке тепер проходить кожен платіж.
Зазвичай це правильний обмін. Але це все одно обмін. Питайте про історію доступності, що відбувається під час релізу і чи зможете ви достукатися до провайдера напряму, якщо шар лежить.
Чого оркестрація не лікує
Варто сказати прямо, бо категорію продають так, ніби вона лікує все.
Поганий відсоток схвалень сама по собі вона не підніме. Маршрутизація веде платіж до провайдера, який імовірніше його схвалить. Якщо всі ваші провайдери відхиляють той самий трафік з тієї самої причини, маршрутизація лише розмаже відмови рівніше. Лікувати треба причину відмови, а не маршрут.
Із зони дії PCI DSS вона вас не виводить. Це робить те, як ви поводитеся з даними карток, і це окреме рішення. Шар, крізь який летять відкриті номери карток, лишає вас у зоні дії рівно там, де ви були.
Людину, яка відповідає за платежі, вона не замінює. Правила фіксують рішення. Ухвалювати ці рішення, дивитися на результат і міняти їх, коли ринок поїхав, усе одно комусь треба. Команди, які купили платформу і не призначили відповідального, отримали дорожчу версію того, що мали.
Слабкий провайдер сильнішим не стає. Якщо у вашого еквайера погане покриття на ринку, роутер попереду покриття йому не додасть. Він лише спростить відправку цього трафіку деінде.
Чи потрібна вам платформа оркестрації
Найімовірніше ні, якщо у вас один провайдер, один ринок і нормальний відсоток схвалень. Додавати шар маршрутизації туди, де все працює, — це додати рухомі частини і не вирішити нічого.
Потрібна, коли справджуються хоча б два пункти:
- У вас уже два або більше провайдерів. Хтось уже маршрутизує між ними. Зараз цей хтось — розробник з умовою в коді.
- Ви втрачаєте продовження або продажі на відмовах, які ніхто не розбирає. Якщо в компанії ніхто не назве три головні причини відмов — це і є сигнал.
- Падіння провайдера зупинить вашу виручку. Не сповільнить. Зупинить.
- Ви виходите на ринки, де ваш провайдер слабкий. Місцеві методи оплати зазвичай і стають тим, що змушує рухатись.
- Комісії провайдерів стали рядком, про який питають. Щойно вартість транзакції перетворюється на питання від керівництва, маршрутизація за ціною перестає бути теорією.
І чесна версія протилежного випадку. Якщо ви робите кількасот платежів на місяць в одній країні, зусилля належать вашому checkout, а не маршрутизації. Виграш там більший і дешевший.
Найпростіша перевірка займе у вас хвилину. Відкрийте свій звіт за минулий місяць і спробуйте відповісти на три питання, не звертаючись ні до кого. Скільки провайдерів ви використали? Який у вас відсоток схвалень у найгіршій країні? Хто у вашій команді змінить маршрут, якщо основний провайдер ляже завтра о десятій ранку?
Якщо на всі три ви відповіли за хвилину, оркестрація вам поки не потрібна: ви і так тримаєте платежі під контролем. Якщо хоча б на одне ви пішли шукати відповідь у розробника — ви вже платите за відсутність цього шару, просто не окремим рахунком.
Як обирати провайдера оркестрації
Ставте питання, на які важко відповісти слайдом. П’ять нижче відділяють продукти, які маршрутизують, від тих, що про це лише розповідають.
1. Що саме читає ваша перевірка можливостей? Ви питаєте, чи означає «підтримується» маркетингову таблицю, чи гілку коду, яка виконується о третій ночі. Приклад із Click to Pay вище — форма цієї проблеми, і своя версія є в кожної платформи.
2. Як рахується вартість конкретного платежу? Слухайте, чи прозвучать платіжна система, тип картки, сума і метод. Якщо у відповіді один відсоток на провайдера — маршрутизація за ціною тут декоративна.
3. Що станеться, коли всі провайдери виглядають нездоровими? Правильна відповідь: платіж усе одно піде. Будь-яка інша означає платформу, яка завалить ваш трафік, щоб захистити власну метрику.
4. Які відмови ви повторюєте і де цей список? Вам потрібен конкретний перелік, який можна редагувати, а не «наш розумний механізм вирішує сам».
5. Що я заберу з собою, якщо піду? Питайте окремо про збережені токени карток. Токени, які працюють лише всередині однієї платформи, — це механізм утримання, хай там що написано в договорі.
Як порівняти відповіді
П’ять питань дають п’ять історій. Оцінюйте їх у балах, інакше порівняння не переживе наради.
| Відповідь на питання 1–5 | Бал |
|---|---|
| Назвали конкретний механізм, файл або поле, які можна перевірити потім | 2 |
| Описали поведінку правильно, але загально | 1 |
| Переформулювали питання або відповіли на інше | 0 |
Всього 10 балів. Сім і вище — продукт, який уже стикався з цими задачами. Менше чотирьох означає, що демо випереджає інженерію, і розрив знайдете саме ви.
Оцінюйте того самого дня, поки наступний дзвінок не змішав відповіді. І запишіть дослівно відповідь на третє питання — про всіх нездорових провайдерів. Саме її потім переписують.
Ще дві речі, які варто перевірити, хоч вони й не про маршрутизацію. Питайте, хто відповідає, коли провайдер змінив API і конектор зламався. І попросіть показати модель звітності до підписання договору: саме в ній ваші фінансисти житимуть щомісяця.
Порівняння гравців ринку тримаємо в payment orchestration platforms compared. Різницю між оркестрацією і звичайним шлюзом розбираємо в payment orchestration vs payment gateway.
Що зробити цього тижня
Проєкт для цього не потрібен. Вам потрібні три числа, і всі три вже є у ваших звітах.
Подивіться відсоток схвалень у розрізі країн, а не загальний. Загальні 92% спокійно ховають 60% на одному ринку, де емітент ріже іноземні картки. Саме цей розріз запустив більше проєктів з оркестрації, ніж будь-яка презентація вендора.
Порахуйте головні причини відмов. Візьміть минулий місяць, згрупуйте за кодом причини і подивіться на трійку лідерів. Потім спитайте, які з них урятувала б спроба через іншого провайдера.
Проговоріть падіння провайдера на папері. Пройдіться по сценарію: основний провайдер лежить дві години у ваш найзавантаженіший день. Хто це помітить, як саме і на що перемкнеться? Якщо у відповіді є слово «реліз» — розрив ви вже знайшли.
Ці три числа скажуть більше за будь-яку порівняльну таблицю. Якщо вони вказують на проблему з маршрутизацією, наступний крок — зрозуміти, кому взагалі маршрутизувати.
Наш довідник провайдерів показує еквайерів і методи оплати за країнами та вертикалями. Подивіться в ньому, хто реально працює на ринках, куди ви йдете, перш ніж починати перемовини.
