Pay by Bank починається в checkout, але сам переказ виконується між payment accounts. Merchant передає PISP order, amount і beneficiary; customer переходить до ASPSP, проходить authentication і підтверджує instruction; provider повертає status. Замовлення не слід fulfillment за одним browser redirect: потрібні signed callback/polling, bank reference, settlement reconciliation та окремий refund process.
У картковому checkout merchant часто покладається на familiar authorisation/capture vocabulary. Open Banking A2A має інші status semantics і не створює автоматично card chargeback або refund rail. Browser може закритися після SCA, callback — повторитися, а payment — залишитися pending, тому order state machine критичніша за кнопку.
Інформацію та офіційні джерела перевірено 2026-08-03. Якщо у матеріалі є майбутня дата набрання чинності, вона не означає, що правило вже діє.
Межі цього матеріалу
| Параметр | Сценарій |
|---|---|
| Хто платить | customer із payment account, який обирає Pay by Bank у checkout |
| Кому | merchant beneficiary, названий у payment instruction |
| Мета | провести A2A payment і зв’язати bank status із ecommerce order |
| Валюта / інструмент | PISP API, ASPSP redirect/SCA, callback, account transfer і refund rail |
| Що змінює висновок | provider/bank coverage, status model, beneficiary data, callback security, settlement timing і refund method |
Що потрібно знати до платежу
PISP ініціює, а ASPSP обслуговує account
НБУ Open Banking framework розділяє payment-initiation provider і account-servicing institution. PISP не стає bank, що зберігає customer balance. (НБУ — Відкритий банкінг)
Open Banking є regulated access model
FCA описує authorised third parties та bank APIs у UK Open Banking. Конкретний Pay by Bank journey і protections залежать від market implementation. (FCA — Open banking and the FCA)
EU reform ще не змінює current flow
Council provisional PSD3/PSR agreement передбачає improved access і anti-fraud measures, але до final adoption merchant не повинен проєктувати rights лише за summary. (Council — provisional agreement on payment services, 27.11.2025)
Покрокова підготовка
- Створіть payment intent. Передайте unique order ID, exact amount/currency, beneficiary account і expiry без card-specific assumptions.
- Переведіть customer до ASPSP. Покажіть bank selection і verified redirect; authentication та confirmation мають відбутися в bank-controlled journey.
- Обробіть asynchronous status. Перевіряйте signed callback, idempotency key і API polling; browser return не вважайте доказом payment.
- Відпускайте order за policy. Зіставте accepted/pending/completed status із fulfillment risk і не створюйте duplicate order при retry.
- Закрийте settlement і refund. Порівняйте provider reference з bank credit, а повернення оформіть визначеним transfer/provider process.
Які дані та документи зібрати
- Pay by Bank API/status specification і webhook security scheme
- payment intent із order ID, amount, currency та beneficiary
- callback log, bank/provider reference і settlement record
- refund, exception та duplicate-payment operating procedure
Документи мають пояснювати одну й ту саму операцію: хто платить, кому, за що, скільки, у якій валюті та до якої дати. Якщо назва отримувача, рахунок або призначення не узгоджуються між файлами, спочатку отримайте письмове пояснення й актуальну версію документа.
Практичний сценарій
Інтернет-магазин ставив order у paid, щойно browser повертався від банку. Під час outage customer закрив вкладку, а delayed callback прийшов двічі; склад створив duplicate shipment. Merchant ввів payment-intent ID, signed webhook і idempotent state machine, відпускав дорогі orders лише за визначеним status та звіряв final bank credit окремо.
Це приклад логіки перевірки, а не обіцянка результату для іншого клієнта. Навіть схожі платежі можуть відрізнятися через країну, банк, суму, валюту, тип отримувача та дату.
Типові помилки
- виконувати замовлення лише за customer redirect success
- очікувати card chargeback mechanics від A2A transfer
- не робити webhook idempotent при повторній доставці
- повертати кошти на неперевірені реквізити з email
Де проходить межа поради
Status names, finality, refunds і customer protections різняться за provider та jurisdiction. Технічний flow не є обіцянкою миттєвого settlement.
Матеріал має інформаційний характер і не є юридичною, податковою, фінансовою, інвестиційною, імміграційною або санкційною консультацією. Для дії перевірте актуальний первинний документ і, коли потрібно, зверніться до профільного спеціаліста.
Як перейти від статті до конкретної заявки
TradePay може прийняти конкретний платіжний сценарій на індивідуальну перевірку маршруту, реквізитів і доступності; це не є гарантією виконання, строку, курсу або відповідності до завершення перевірки. Після цього чекліста можна передати підготовлений контекст менеджеру TradePay — країни, суму, валюту, призначення, реквізити й дедлайн.
За змінами платіжних маршрутів і практичними розборами можна стежити в Telegram-каналі TradePay Desk.
Важливо
Матеріал має інформаційний характер. Доступність маршруту, строк, курс і підсумкова вартість залежать від країни, валюти, реквізитів та перевірки конкретної заявки менеджером.
Джерела та перевірка
- Council — provisional agreement on payment services, 27.11.2025
- НБУ — Відкритий банкінг
- FCA — Open banking and the FCA
Дата редакційної перевірки: 2026-08-03.
TradePay Desk
Перевірте маршрут до відправлення коштів
Менеджер уточнить реквізити, валюту та доступний спосіб розрахунку для вашої заявки.
Зворотний зв’язок
Наскільки корисним був матеріал?
Оцінка допомагає редакції обирати теми та оновлювати пояснення.
Оберіть оцінку від 1 до 5.