Автор: Аван, веб-3 малий юрист
Цифрові платежі вже потрапили до основного потоку, але розрахунки ще ні.
Це думка Дана Моттіса, колишнього високопосадовця Visa та засновника Beam. Транзакції Visa авторизуються в будь-якій торговій точці світу, але розрахунки все ще здійснюються через SWIFT — збираючи пакети транзакцій, переказуючи кошти міжнародними переказами, проходячи через місцеве регулювання, святкові дні та багато рівнів проміжних банків, після чого торгові точки чекають на отримання коштів. Це не проблема Visa, а структурний борг усієї галузі. А PSP — це місце, де цей борг зосереджений найбільше.
Ця стаття зосереджена на постачальниках платіжних послуг (PSP), які перетворилися з простих інструментів для отримання платежів на ключову інфраструктурну шару, що керує грошовими потоками, розрахунками та бухгалтерським обліком. Спочатку вони були створені для більш простого часу — системи з однією дорогою, лінійних процесів транзакцій та сильно інтегрованої інфраструктури.
У сучасному середовищі платежів «платіж» більше не є окремою транзакцією, а є серією змін станів, що охоплюють кілька учасників та платіжних каналів. Сьогодні платіж може включати: додатки для клієнтів, PSP, сервіси протидії мошеництву та верифікації особи, депозитарні банки, один або кілька платіжних каналів, а також бухгалтерські системи всередині підприємства.
Компанії повинні підтримувати одночасно банківські картки, ACH, банківські перекази, RTP, FedNow, а також все більше кількості розрахунків на основі стабільних монет. Кожен канал має різні терміни结算, моделі відмов, формати даних та операційні вимоги.
Ця стаття є перекладом керівництва Modern Treasury, яке досліджує, як PSP еволюціонували, як має адаптуватися їхня базова архітектура до сучасних платіжних систем, а також яку стратегію повинні використовувати команди, що розробляють платіжні продукти, при виборі наступного PSP.
Основне твердження
01｜Цифрові платежі потрапили до основного потоку, але розрахунки — ні. Visa дозволяє вам здійснювати авторизацію в будь-якій торговій точці світу, але самі розрахунки все ще відбуваються через SWIFT. Інтерфейс вирішено, а базовий рівень — ні.
02｜PSP виконує платіж, але не пояснює рух коштів. Stripe розповідає вам, що відбулося на її частині, але не може сказати, який реальний статус цих коштів зараз. Виконання та реєстрація — це дві різні речі.
03｜ Кожна платіжна траєкторія — це окрема операційна система, а не варіант однієї моделі. ACH можна скасувати, RTP — ні; платіжні мережі можуть мати спори, а стабільні монети мають фінальне підтвердження в ланцюжку. Абстрактний шар PSP приховує ці відмінності, але лише до тих пір, поки не виникне проблема.
04｜ Реальний час оплати знищив буфер. Контроль повинен зміститися вперед. Логіка контролю ризиків, схвалення та звітності традиційних PSP базувалася на припущенні, що «якщо щось піде не так, ще є час виправити це». RTP і FedNow зробили це припущення застарілим. Рішення повинні прийматися до переміщення коштів, а не після.
05｜ Стабільні монети — це платіжний канал, а не новий спосіб оплати. Вони вирішують не проблему інтерфейсу оплати, а затримку між «закінченням обліку» та «реальним надходженням коштів». Найбільш практичний шлях реалізації — сендвіч-структура: фіат вхід, обіг у ланцюзі, фіат вихід — користувачі на обох кінцях не повинні розуміти стабільні монети.
06｜ Кошти в дорозі можуть приносити дохід — це майже неможливо в традиційній системі. У міжнародних платежах кошти заморожуються від 24 до 72 годин до завершення розрахунків, не приносячи доходу і займаючи оборотний капітал. Стабільні монети вперше дозволяють «коштам у русі» також створювати вартість.
07｜ Найбільша невдача в операціях з платежів — це неможливість відповісти на просте питання: куди поділися ці гроші? Звернення, обробка винятків, управління ліквідністю — ці проблеми не виникають під час ініціювання платежу, а з’являються після нього. Без єдиної координаційної шари кожен постачальник послуг може розповісти лише свою власну історію.
08｜ Справжній стратегічний ризик — не в тому, чи використовуєте ви стабільні монети, а в тому, що ваші конкуренти за допомогою стабільних монет перебудували свої витрати на розрахунки та ефективність капіталу, тоді як ви все ще чекаєте на ідеальний момент для входу.
I. Історичний розвиток PSP
За останні двадцять років роль PSP зазнала фундаментальних змін.
На початку електронної комерції PSP працювали переважно як платіжні шлюзи. Їхні обов’язки були простими: з’єднувати продавців із мережами карток та аквайринговими банками, щоб забезпечити авторизацію та розрахунок транзакцій.
Ці системи PSP були створені для дуже специфічного світу. Платежі здійснюються переважно за допомогою карток, проходять через єдиний рахунок продавця й слідують лінійному життєвому циклу від авторизації до розрахунку. PSP були оптимізовані для ефективної обробки транзакцій у межах цієї моделі.
У 2010-х роках marketplace, SaaS-платформи та фінтех-продукти почали безпосередньо інтегрувати оплати у свої продукти. Платформам потрібно було обробляти реєстрацію користувачів, розподіляти платежі між кількома сторонами та керувати виплатами. PSP розширили свої можливості, додавши інфраструктуру для реєстрації магазинів, виплат та інструменти протидії шахрайству.
Однак, незважаючи на постійне розширення можливостей PSP, їхня базова архітектура все ще ґрунтується на моделі, розробленій для лінійних платежових процесів — переважно оптимізованої для обробки транзакцій, а не для координації складних багатокрокових переміщень коштів між сервісами та каналами.
На початку 2020-х років підприємства почали функціонувати через кілька напрямків, регіонів та сценаріїв. Традиційні PSP продовжували об’єднувати багато компонентів, дозволяючи підприємствам взаємодіяти з однією платформою. Але зі зростанням складності платежів один платіжний процес може охоплювати кілька етапів: верифікація особи, перевірка ризиків, прийняття рішення щодо коштів, виконання каналу, внутрішнє відстеження.
Ця зміна перетворила роль PSP з «з’єднувачів» на «координаторів» (from connectors to coordinators), але їхня архітектура не розвивалася з такою ж швидкістю.
Результат: PSP все ще відповідає за переказ коштів, але функціонує в більш складному середовищі повного життєвого циклу платежів.
Друге: Сучасний стек технологій PSP для платежів
Щоб зрозуміти обмеження PSP, потрібно спочатку зрозуміти ширший платіжний середовище, в якому вони функціонують.
2.1 Технічний стек PSP
Сучасна платіжна середовище — це не єдина платформа чи постачальник послуг, а набір шарів інфраструктурних компонентів, які разом забезпечують переміщення, розрахунки та облік коштів.
Рівень застосунку: електронні платформи для покупок, Marketplace, фінтех-додатки, SaaS-продукти з вбудованими платежами.
Рівень PSP: відповідає за виконання платіжних інструкцій, таких як маршрутизація транзакцій до мережі карток, ініціювання банківських переказів та підключення до платіжних каналів. У більшості випадків ця нижчоуровнева складність абстрагована за інтерфейсом PSP, і користувач взаємодіє з однією системою, а не безпосередньо з кількома постачальниками, що стоять за ними.
Комплійність: сучасні платіжні процеси також залежать від провайдерів верифікації особи, інструментів виявлення шахрайства та інфраструктури комплійнсності, які визначають, чи слід дозволити продовження платіжної операції.
Банківський рівень: Контролюючий банк зберігає кошти, надає регульовані рахунки та забезпечує доступ до платіжних мереж ACH, банківських переказів, RTP та FedNow.
Внутрішній рівень звітності: система, яку підприємства використовують для відстеження балансів, відображення статусу транзакцій та підтримки послідовних записів фінансової діяльності.
Кожен з вищезазначених рівнів відіграє роль у пересуванні коштів, але жоден з них не надає повної картини того, що відбувається після ініціювання платежу. Саме тому внутрішній рівень звітності стає незамінним.
2.2 Синхронізація та асинхронність
Традиційні PSP мають фундаментальну конструктивну недолік: вони тільки відправляють гроші, але не стежать за тим, що відбувається після відправлення.
Проблема полягає в тому, що «після відправлення» саме найскладніша частина оплати.
Логіка API PSP є синхронною — ви надсилаєте команду, і вона повертає результат. Але реальний потік коштів є асинхронним: розрахунки завершуються пізніше, невдачі проявляються з затримкою, а повернення коштів та корекції можуть відбутися в будь-який момент. Ця невідповідність створює постійну інформаційну діру.
Конкретним проявом чорної діри є фрагментація стану:
Жоден вузол не може сказати вам, яким є справжній стан цих коштів зараз.
Наприклад, при виведенні коштів продавцем на ринковій платформі весь процес складається з довгої ланцюжки: перевірка кваліфікації → ризик-менеджмент і відповідність нормам → підтвердження коштів → відправлення інструкції → виконання транзакції → повернення підтвердження → післяопераційне розрахунок → оновлення бухгалтерських записів. PSP охоплює лише кілька середніх етапів; прийняття рішень на початку та звітність наприкінці не входять до його обов’язків. Якщо цей платіж не вдасться або буде повернений, жодна система не зможе надати повну відповідь.
Ось у чому полягає суть внутрішнього рівня відповідності: він не замінює PSP у виконанні платежів, а замість цього створює єдиний рівень спостереження над усією ланцюжком — постійно перетворюючи асинхронні події з різних постачальників, різних часів та різних форматів у єдиний стан, якому можна довіряти всередині компанії. Незалежно від того, скільки проміжних етапів пройшла грошова сума, завжди є місце, де можна відповісти на найпростіше питання: де зараз ці гроші?
Три: Обмеження традиційних PSP у платежах
Абстрактний рівень традиційних PSP побудований навколо платежів картками — авторизація, захоплення, розрахунок, життєвий цикл передбачуваний. Хоча існують винятки (наприклад, спори та повернення коштів), загальна структура передбачувана й добре зрозуміла. Ця модель вплинула на спосіб проектування PSP.
З появою нових способів оплати PSP розширює підтримку на більше треків, але ці треки поводяться інакше, ніж банківські картки, і не відповідають тим самим припущенням:
- ACH-переказ: введено затримку, а також можливість повернення платежу протягом кількох днів після його ініціювання.
- Bank transfer: Faster settlement, but typically requires manual processes and higher costs.
- Мережі реального часу, такі як RTP і FedNow: забезпечують миттєве переміщення коштів, але транзакції зазвичай є незворотними після завершення.
- Переказ стабільних монет: працює на зовсім іншій інфраструктурі з іншими механізмами захисту та експлуатаційними міркуваннями.
Наприклад, з платіжем американської компанії постачальнику на Філіппінах:
- ACH, T+2 до надходження, але філіппінські банки не приймають ACH безпосередньо — потрібна додаткова переказка через місцеву систему, тому фактично кошти можуть надійти лише T+4; протягом цього періоду транзакцію можуть відмовити через невідповідність інформації про рахунок.
- Використовуйте банківський переказ — швидше, але подайте заявку до 15:00, перед тим, як закриється обробка переказів; у випадку свят — термін переноситься. Комісія SWIFT — від 25 до 45 доларів США, отримувач може також сплатити додаткову комісію за проміжний банк, тому сума, що надійде, може відрізнятися від відправленої.
- Використовуйте стратегію стабільної монети: USDC відправляється з американського рахунку, підтвердження в ланцюжку — кілька секунд, після отримання партнером у Філіппінах він обмінює його на песо та вводить на місцевий рахунок — весь процес триває менше години, витрати менше 1% від суми переказу.
Три шляхи, ті самі гроші, час розрахунку відрізняється на 96 годин, витрати відрізняються на десятки доларів, а слідкованість повністю інша. Це не різниця в досвіді продукту, а різниця між трьома операційними системами. Абстракційний шар PSP не може приховати це — він лише передає цю різницю розробникам та командам операцій для вирішення.
Це не варіанти однієї і тієї самої платіжної моделі, а зовсім різні моделі функціонування.
Традиційні PSP реагували шляхом надання різних API та визначень стану для кожного напрямку — не об’єднуючи різниці, а лише переносячи їх на розробників. Інженерні команди почали писати спеціальну логіку для кожного напрямку, операційні команди почали вручну обробляти різні режими відмов, а фінансові команди почали вести звітність для однакових транзакцій, що проходили через зовсім різні шляхи.
Це і є витік абстракції: складність треків, які мали б бути приховані, починає проникати на рівень додатку.
Зі збільшенням кількості орбіт платіжне середовище перетворилося на сукупність роз’єднаних інтеграцій, а не на єдиний абстрактний рівень. На повільних орбітах затримка надає час для виявлення проблем. На реальному часі цей вікно зникає — платежі завершуються за кілька секунд, помилки не можна легко скасувати, а рішення повинні прийматися до переміщення коштів, а не після нього.
Чотири: реальний час оплати змушує PSP змістити контроль вперед
Перехід на мережу реального часу — це не просто прискорення швидкості руху коштів — це фундаментальна зміна вимог до проектування платіжної інфраструктури.
У епоху ACH та електронних переказів час є буфером.
ACH може вимагати кількох днів для розрахунків, операції картками можуть бути сперечані після авторизації, а електронні перекази часто передбачають ручний етап перевірки. Ці затримки, хоча й призводять до втрати ефективності, також надають можливість виявляти помилки, втручатися у підозрілу діяльність та завершувати звірку до завершення розрахунків.
Традиційна модель PSP побудована саме навколо цього буфера.
Однак такі мережі миттєвих платежів, як RTP і FedNow, повністю зруйнували це припущення. Кошти безпосередньо переказуються між рахунками за кілька секунд, і після завершення платежу вони зазвичай є незворотними.
- Виявлення шахрайства має бути завершено раніше
- Комплійнс-сканування має проводитися в реальному часі
- Фінансові рішення повинні бути точно виконані в момент вивільнення платежу
- Можливість виправлення помилок після події втрачена
Платформи, що надають миттєві виплати, не можуть опиратися на робочі процеси, розроблені для запізнених розрахунків. Внутрішні системи підприємств, що керують платіжними коштами через кілька рахунків, не можуть визначити ліквідність у миттєвому порядку. Команда служби підтримки не може гарантувати зворотність, коли базова інфраструктура взагалі не дозволяє цього.
Результатом є зміщення відповідальності: PSP повинні розвиватися, щоб підтримувати внутрішні системи, які вирішують, коли слід виконувати платіж. Іншими словами, контроль повинен зміститися вперед.
Інфраструктура оплати повинна бути спроектована так, щоб схвалення, логіка коштів, перевірка ризиків і верифікація статусу мали бути завершені до переміщення коштів, а не після нього. Це вимагає більш координованого погляду на залишки, статуси транзакцій і умови між сервісами, ніж того, що забезпечують традиційні архітектури PSP.
Реальний трек — це не кінцевий стан, а лише поворотний момент. Після входу стабільних монет проблема додатково ускладниться.
П’ять: Стабільні монети: нова траєкторія, а не новий спосіб оплати
Найбільш поширена помилка щодо стабільних монет — це вважати їх новим платіжним інструментом. Це не так. Це новий розрахунковий канал, який вирішує затримку між «завершенням обліку» та «реальним надходженням коштів».
На відміну від карток, ACH та банківських переказів, угоди з стабільними монетами відбуваються на блокчейн-мережах:
- Розрахунки проводяться неперервно, а не пакетно
- Майже миттєва фінальна підтвердження (залежить від мережі)
- Робота 7×24 години, без обмежень банківськими термінами та святами
- Не залежить від конкретних національних платіжних систем
- Примітиви для відстеження балансу, власності та історії транзакцій повністю відрізняються
Традиційна архітектура PSP побудована навколо інтеграції з банками та платіжними мережами, а стабільні монети вводять мережі, які не залежать від цих посередників. Виникнення, розрахунки та облік відбуваються поза межами первісного дизайну. Підприємство може одночасно потребувати координації банківських каналів, мереж у реальному часі та блокчейн-розрахунків, де кожен тип має різні припущення щодо фінальності, хронології та контролю — ці відмінності не можна уніфікувати за допомогою одного API, і позиція PSP як єдиної абстрактної шари стає все важче підтримувати.
Як і системи реального часу, які поставили під сумнів припущення щодо послідовності та відкликання, стабільні монети ставлять під сумнів припущення щодо місця та форми здійснення платежів.
У цьому процесі вони ввели новий рівень складності.
Стабільні міжшарові сендвічі — це найбільш практичний шлях реалізації: фіат входить → обіг у мережі → фіат виходить.
Клієнти та постачальники на обох кінцях угоди не повинні розуміти стабільні монети — стабільні монети є лише проміжним каналом, призначеним для вирішення проблем повільного, дорогого та нестабільного традиційного міжнародного розрахунку. Найбільш цінні застосування зосереджені на «складних каналах» — тобто міжнародних сценаріях, де традиційні методи повільні, дорогі або взагалі недоступні.
Підприємства не повинні і не будуть повністю переходити на стабільні монети; реалістичний підхід — вибрати один або два конкретні випадки використання для часткової заміни, сформувати розуміння, а потім розширити масштаб.
Стабільні монети також додають додатковий вимір: дохід від коштів у дорозі, який майже відсутній у традиційних системах. У традиційних платежевих процесах кошти від моменту відправлення до отримання заморожуються на 24–72 години, не приносячи доходу та займаючи оборотний капітал. Стабільні монети на ланцюзі можуть генерувати дохід під час перебування в русі — це не невелике поліпшення витрат на оплату, а повна перебудова логіки ефективності коштів.
Шість: Поточна екосистема: десять рівнів розподілу обов’язків і відсутній рівень
Зі збільшенням кількості треків, постачальників та типів інфраструктури, визначення ролі PSP стає все складнішим.
Раніше функції з переміщення коштів у межах одного PSP зараз розподілені між кількома рівнями технологічного стеку.
Робота PSP більше не обмежується лише переміщенням коштів, а полягає у поясненні потоків коштів.
Ця зміна відображає глибші зміни: саме виконання більше не є достатнім. PSP зараз повинні підтримувати внутрішні системи підприємств, щоб вони могли представляти, обліковувати та звіряти, як кошти рухаються між різними середовищами.
① Платформа рівня продукту: інтеграція оплати в програмне забезпечення
Платформи вертикального програмного забезпечення, такі як Shopify, Square, Toast, Mindbody, ServiceTitan, Housecall Pro, вбудовують оплату безпосередньо в свої продукти.
У цих сценаріях оплата інтегрована в досвід застосунку, а не обробляється як окрема платіжна система. Ці платформи зазвичай залежать від базових PSP, банківських партнерів та постачальників інфраструктури, додаючи ще один рівень абстракції між застосунком та потоками коштів.
② Рівень виконання: переміщення коштів між треками
Основу технічного стеку становлять сервіси, відповідальні за виконання платежів. До них належать традиційні PSP, такі як Stripe, Adyen, Checkout.com, Worldpay, PayPal, Nuvei, dLocal, чия роль полягає у підключенні бізнесу до платіжних систем та забезпеченні переміщення коштів.
Вони залишаються ключовими компонентами платіжного стеку, але працюють переважно на рівні виконання — ініціюють платежі, повідомляють про статус, відкривають API, але самі не надають повної моделі того, як кошти переміщуються між сервісами та внутрішніми системами.
Ви запитуєте Stripe: «Де зараз ці гроші?», а вона може сказати вам лише те, що відбулося в її частині. Stripe — це лише один вузол; у цій транзакції можуть брати участь PSP, банк, орбіта, внутрішній облік — п’ять-шість етапів, але вона бачить лише частину, а не загальну картину.
③ Рівень оркестрації та маршрутизації: підключення сервісів виконання
Зі зростанням використання підприємствами кількох PSP та способів оплати з’явилися платформи оркестрації, які відповідають за маршрутизацію між провайдерами. Компанії, такі як Primer, Gr4vy, Spreedly, Paydock, CellPoint Digital, дозволяють підприємствам направляти транзакції на основі географії, витрат або продуктивності. Ці системи підвищують гнучкість рівня виконання, але не забезпечують єдину модель поведінки після ініціювання оплати.
④ Рівень контролю ризиків та відповідності: вирішує, чи слід переміщати кошти
Незалежні постачальники послуг відповідають за визначення, чи слід дозволити продовження платежу. Системи верифікації особи, виявлення шахрайства та відповідності від постачальників, таких як Persona, Sardine, Alloy, Unit21, Sift та Sumsub, оцінюють користувачів та транзакції до виконання. У реальному часі ці рішення повинні бути прийняті до переміщення коштів, тому ключова логіка контролю була переміщена за межі PSP.
⑤ Рівень банківської інфраструктури: зберігає кошти та забезпечує підключення
Трастові банки, такі як Cross River Bank, Lead Bank, Column, Sutton Bank, надають регульовані рахунки та доступ до платіжних мереж. Вони зберігають кошти клієнтів, керують ліквідністю та слугують вхідними точками для доступу до систем, таких як ACH, електронні перекази, RTP та FedNow. Цей рівень критично важливий для підключення до фінансової системи, але працює незалежно від логіки застосунку та API PSP.
⑥ Рівень випуску карток: розширення функцій оплати
Платформи випуску карт, такі як Marqeta, Lithic і Rain, дозволяють компаніям випускати дебетові та кредитні карти як частину своїх продуктів, підтримуючи сценарії використання, такі як управління витратами, корпоративні карти та роздрібні покупки. Платформи випуску карт з’єднують банки та платіжні мережі, але працюють як окремий рівень у технічному стеку, додаючи додаткові робочі процеси, механізми контролю та стани, які потребують координації з іншими частинами платіжного технічного стеку.
⑦ Шар оплати: базова виконавча мережа
Платіжні канали — це мережі, які переміщують кошти між фінансовими установами. Традиційні канали включають ACH, електронні перекази та платіжні мережі, тоді як нові мережі, такі як RTP і FedNow, підтримують миттєве розрахунок. Кожен канал має різні припущення щодо таймінгу, фінальності та зворотності, що створює непослідовності, які PSP повинні відкривати або обходити (а не повністю абстрагувати).
⑧ Сітковий рівень стабільних монет: розширення за межі банківської інфраструктури
Мережі стейблкоїнів, такі як Ethereum, Solana, Polygon, Base, ввели нову форму інфраструктури для платежів, що функціонує поза традиційною банківською системою. Ці мережі забезпечують переказ цифрових доларів на глобальній інфраструктурі за допомогою різних моделей розрахунків та механізмів захисту. Вони розширюють діапазон платіжних систем за межі банківських каналів, додаючи до існуючих робочих процесів додатковий рівень складності, який потрібно інтегрувати.
⑨ Рівень банк як сервіс: з’єднання додатків із банками
Платформи банківських послуг (BaaS), такі як Unit, Galileo та Treasury Prime, надають інфраструктуру для підключення фінтех-додатків до регульованих банків. Вони дозволяють компаніям надавати облікові записи, картки та платіжні функції, не будучи банками. Цей рівень спрощує доступ до банківської інфраструктури, але додає ще один посередній елемент між додатком, PSP та базовою фінансовою потоковою системою.
⑩ Відсутній рівень: єдина PSP, що охоплює повний життєвий цикл руху коштів
Огляд дев’яти рівнів показує єдину закономірність: кожен провайдер відповідає за певну функцію, і жоден з них не може надати повної картини руху коштів — включаючи розуміння, контроль та звітність.
Виконання обробляється одним постачальником послуг, прийняття рішень щодо ризику — іншим, кошти зберігаються в банку, а процес оплати може охоплювати мережі карток, реальні часи та ланцюгові системи. Кожна система надає різні дані, часові шкали та визначення стану.
У фрагментованому середовищі ця проблема не проявляється на етапі ініціювання — вона виникає після: коли система розходиться, кошти затримуються або повертаються, а команда потребує відповідей. Саме тут починає руйнуватися платіжна система.
Сім. Де збій у роботі з платежами
О 14:55 у п’ятницю фінансова команда надіслала переказ постачальнику на $50 000. О 15:00 — кінець обробки банківських переказів. Система показує «надіслано», але підтвердження не надійшло.
О 16:00 постачальник надіслав повідомлення з запитом про статус платежу. Фінансовий відділ перевірив бекенд PSP — там відображалося «У обробці». Перевірили банківський рахунок — там було «Очікує розрахунку». Дві системи, один і той самий грошовий переказ, два різні статуси — жодна з них не може сказати, де саме зараз знаходяться кошти.
Опівдні у п’ятницю банківські служби підтримки закриваються. Постачальники чекають на організацію оплати для відправлення вихідних. Фінансова команда не знає, що сказати постачальникам, чи автоматично надійдуть гроші в понеділок ранком, чи вони вже були повернені і потрібно відправити їх знову.
Це не екстремальна ситуація, а сценарій, який команди з операцій з платежів переживають щотижня. Він не зустрічається в інструкціях до продукту PSP, але присутній у звітах кожної команди міжнародних платежів.
Найскладніші проблеми в оплаті часто виникають не на початковому етапі, а після — коли команді потрібно пояснити, що саме сталося.
Карта ринку з попереднього розділу розкриває широту екосистеми платежів. Один, на перший погляд, простий платіж часто проходить через кілька посередників у технічному стеку до того, як він буде розрахований. Кожна сторона може мати різне представлення одних і тих самих рухів коштів, різний час, різні статуси, документи надходять за різними графіками, а винятки повідомляються через різні канали.
Саме тут операції з оплатою стають складними.
Аудит: кілька версій однієї події
Фінансовий відділ повинен зіставляти внутрішній облік з банківськими витягами, звітами про розрахунки та даними обробників. Якщо один постачальник вказує, що платіж завершено, а інший — що він ще обробляється, компанії потрібна модель для вирішення розбіжностей. Якщо повернення коштів надходить після оновлення внутрішнього балансу, облік повинен відповідно скасувати або скоригувати цю операцію.
Обробка винятків: неозначена поломка
Вивід коштів може зазнати невдачі через неправильний отримувач, використання неправильного рахунку коштів, призупинення транзакції через перевірку відповідності або пропуск терміну виконання. Ці помилки різні і відбуваються в різний час, але користувачі очікують однакову відповідь, а внутрішні команди все ще повинні обробляти ці процеси.
Ліквідність і кошти: гроші не там, де треба
Підприємства, які працюють через кілька сервісів та облікових записів, повинні забезпечити, щоб кошти з’являлися у правильному обліковому записі у правильний час. Навіть якщо загальний баланс достатній, але кошти залишаються у неправильному обліковому записі, виконання платежів все ще може зазнавати невдачі — це створює розрив між логікою продукту та оперативною реальністю.
Аудитованість та контроль: відновлення того, що відбулося
Операції схвалення, призупинення, вивільнення та звірки відбуваються між командами та системами; компаніям потрібні надійні записи про те, хто, коли та чому зробив те чи інше. Це не лише вимога відповідності, а й основа для відстеження історії транзакцій у разі виникнення проблем.
Ці питання є як операційними, так і архітектурними.
Найбільші невдачі в операціях з платежів часто виникають, коли команда не може відповісти на просте питання: куди поділися ці гроші?
Відсутнім є не ще один постачальник послуг, який виконує платежі, маршрутизує транзакції чи зберігає кошти в межах існуючої моделі, а еволюційний PSP, здатний координувати всі ці функції, відстежувати статус між постачальниками послуг, керувати робочими процесами руху коштів та протягом часу підтримувати надійні фінансові записи.
Вісім: Наступна еволюція PSP
Виклик полягає не в підключенні платіжної інфраструктури, а в здатності мати послідовне та надійне розуміння того, як кошти рухаються всередині неї.
Поточне розподілення обов’язків у екосистемі: PSP виконує платежі, банки зберігають кошти, системи відповідності оцінюють ризики, а інструменти оркестрування маршрутизують транзакції. Однак жоден окремий постачальник не відповідає за надання повної та уніфікованої картини руху коштів протягом усього життєвого циклу платежів.
Наступний етап розвитку PSP — забезпечення уніфікованої видимості по всьому технічному стеку — щоб кожна оплата, від ініціювання до фінального розрахунку, була зрозумілою, облікованою та надійною.
Цей рівень повинен здати:
- Виконання платежів через міжбанківські, традиційні та мережі стабільних монет
- Підтримка єдиної системи реєстрації за допомогою внутрішнього обліку
- Робочий процес управління схваленням, коштами та обробкою винятків
- Зіставте зовнішні заходи з внутрішнім фінансовим станом
- З ростом масштабу — вбудована відповідність, інфраструктура облікових записів та підключення до треків постійного зростання
Заключення: З чого почати
Сучасна платіжна інфраструктура більше не визначається одним обробником чи однією системою. Це середовище, що складається з кількох постачальників послуг, кожен з яких відповідає за різні етапи руху коштів, схвалення, розрахунків та обліку.
Оглядаючи цей посібник, ми бачимо еволюцію цієї середовища:
Платіжні сервіси вийшли за межі обробки транзакцій, кількість платіжних каналів зростає, реальні системи прибрали безпекову мережу відстроченого розрахунку, а нові форми інфраструктури, такі як стабільні монети, додатково розширили всю систему.
Для команд, які розробляють фінансові продукти або інтегрують платежі в програмне забезпечення, шлях входу важливіший, ніж стратегічні обговорення.
Не починайте з питання «чи повністю прийняти стабільні монети», а знайдіть конкретну проблему: надто повільне розрахунки по міжнародному каналу, надто багато ручних операцій у процесі оплати постачальнику, частина вільних коштів не приносить доходу під час переказу. Виберіть один випадок використання, відкрийте рахунок, здійсніть реальну оплату. Спочатку проведіть внутрішній пілотний проект, почавши зі сценаріїв управління скарбницею (treasury), а не відразу змінюючи процеси на стороні клієнта. Це дозволить контролювати ризики та сформувати розуміння.
На рівні відповідності правила KYC, AML та перевірки на санкції залишаються повністю застосовними; стабільні монети — це лише зміна нижчого рівня. Регуляторна рамка після закону GENIUS Act стала значно чіткішою порівняно з двома роками тому і не повинна бути перешкодою для пілотного проекту.
Справжній стратегічний ризик — не в тому, чи використовуєте ви стабільні монети, а в тому, що ваші конкуренти за допомогою стабільних монет перебудували свої витрати на розрахунки та ефективність капіталу, тоді як ви чекаєте на ідеальний момент для входу.
Без єдиної координаційної шари складність зростає пропорційно до масштабу. З нею компанії можуть керувати грошовими потоками зі зрозумілістю, контролем і впевненістю.
Частина інформації походить з: Modern Treasury — Практичний посібник з PSP у 2026 році