7. Use Case 6. Ініціювання платіжної операції PSU через PISP
Редакція OpenBanking Ukraine
Ця сторінка описує Use Case 6 для PIS API v2.1: як PSU ініціює платіжну операцію через PISP із подальшим проходженням SCA на стороні ASPSP (підходи Redirect SCA або Decoupled SCA), а також як PISP отримує кінцевий статус платіжної операції.
Опис use case
| Параметр | Значення |
|---|---|
| Первинна дійова особа | PSU |
| Вторинна дійова особа | PISP, ASPSP |
| Передумова | PSU має діючий рахунок в UAH в ASPSP |
| Тригер | PSU ініціював платіжну операцію у платіжному застосунку PISP |
| Результат | Платіжна операція виконана успішно. Статус платіжної операції дорівнює одному з: ACCC — для миттєвого кредитового переказу; ACSC — для кредитового переказу, крім миттєвого. |
Activity diagrams
Use Case 6.1. Redirect SCA: явний початок процесу авторизації
Якщо ASPSP підтримує підхід Redirect SCA, потік повідомлень є таким: після ініціювання платіжної операції PSU через PISP відбувається перенаправлення PSU в платіжний застосунок ASPSP або web-сторінку ASPSP для надання згоди на виконання платіжної операції та проходження SCA. Для визначення статусу або вмісту платіжної операції PISP може здійснити відповідний виклик після перенаправлення сеансу в платіжний застосунок PISP.
Use Case 6.2. Decoupled SCA: явний початок процесу авторизації
Потік транзакцій у підході Decoupled SCA аналогічний підходу Redirect SCA. Різниця полягає в тому, що ASPSP просить PSU авторизувати згоду на виконання платіжної операції, наприклад, через спеціальний мобільний платіжний застосунок. ASPSP просить PISP повідомити PSU про цю автентифікацію, надіславши відповідне повідомлення PSU приблизно такого змісту: «Будь ласка, використайте застосунок ASPSP для підтвердження виконання платіжної операції».
Опис кроків activity diagram
| Крок | Опис |
|---|---|
| Основний сценарій | |
| 0. PSU пройшов SCA у платіжному застосунку PISP | Цей крок вказаний інформаційно, щоб акцентувати увагу, що у платіжному застосунку PISP теж потрібен SCA. Перехід до кроку 1 основного сценарію. |
| 1. Ініціювати через PISP платіжну операцію | Тригер для запуску цього use case, дію виконує PSU. Перехід до кроку 2 основного сценарію. |
2. Викликати POST /v2/payments/{payment-product} | PISP викликає POST /v2/payments/{payment-product} — параметри згідно опису у розділі 4. Перехід до кроку 3 основного сценарію. |
| 3. Успішно? | Цей крок не є обов’язковим і PISP може не реалізовувати повторення виклику. Якщо виклик здійснений успішно — перехід до кроку 4 основного сценарію. Якщо виклик був неуспішний (HTTP status code = 50Х та інші помилки) і кількість повторень не вичерпана — перехід до кроку 2 основного сценарію. Якщо виклик був неуспішний (HTTP status code = 50Х та інші помилки) і кількість повторень вичерпана — перехід до кроку 4.А альтернативного сценарію. |
| 4. Перевірити QWAC та відомості в РПІ, request | ASPSP перевіряє: QWAC та відомості в Реєстрі платіжної інфраструктури (див. розділ 6.3 документу “Протокол функцій та заходів безпеки”); request syntax; semantics. Перелік перевірок може бути значно ширшим і не наводиться у цьому документі. Перехід до кроку 5 основного сценарію. |
| 5. ОК? | Якщо всі перевірки пройдено успішно — перехід до кроку 6 основного сценарію, якщо ні — 6.А альтернативного сценарію. |
| 6. Створити платіжну операцію (status RCVD) | ASPSP створює платіж у статусі RCVD. Перелік полів таблиці у базі даних для збереження платіжної операції кожен ASPSP визначає самостійно. Перехід до кроку 7 основного сценарію. |
| 7. Надіслати OK response (HTTP code = 201) | ASPSP надсилає OK response з HTTP code = 201 відповідно до розділу 4. Перехід до кроку 8 основного сценарію. |
| 8. Зберегти платіжну операцію (status RCVD) | PISP створює платіжну операцію, у якій зберігає дані з request та response на створення платіжної операції. Перелік полів таблиці у базі даних кожен PISP визначає самостійно. Перехід до кроку 9 основного сценарію. |
9. Викликати POST /v2/{resource-path}/{resourceId}/{authorisation-category} | PISP викликає POST /v2/{resource-path}/{resourceId}/{authorisation-category} згідно розділу 9.1 Проколу функцій та заходів безпеки. Перехід до кроку 10 основного сценарію. |
| 10. Перевірити QWAC та відомості в РПІ, request | ASPSP перевіряє: QWAC та відомості в Реєстрі платіжної інфраструктури; request syntax; semantics; resourceId (paymentId). Перехід до кроку 11 основного сценарію. |
| 11. OК? | Якщо перевірки пройдено успішно — перехід до кроку 12 основного сценарію, у іншому випадку — 13.А альтернативного сценарію. |
| 12. Встановити SCA статус started/psuIdentified | ASPSP встановлює відповідний SCA status. SCA status=started встановлюється при Redirect SCA, якщо PISP не передав PSU-ID або PSU-Corporate-ID. SCA status=psuIdentified встановлюється, коли PISP передав PSU-ID або PSU-Corporate-ID. Структуру таблиці для збереження SCA status кожен ASPSP визначає самостійно. Перехід до кроку 13 основного сценарію. |
| 13. Надіслати OK response (HTTP code = 201) | ASPSP надсилає OK response з HTTP code = 201 відповідно до розділу 4. Перехід до кроку 14 основного сценарію. |
| 14. Відобразити інформацію про початок SCA | PISP інформує PSU про початок SCA. Повідомлення може бути взяте із параметру psuMessage, отриманому на кроці 7 або 13. Перехід до кроку 15 основного сценарію. |
| 15. Вибір PSU (крок виконується тільки для Redirect SCA) | PISP на власний розсуд проєктує UI переходу до SCA для підтвердження виконання платіжної операції PSU. Якщо PSU обрав опцію Перейти/продовжити SCA — перехід на крок 16 основного сценарію для Redirect SCA. Якщо PSU обрав будь-які інші дії — основний сценарій завершується. |
| 15. Надіслати PSU повідомлення (push) (крок виконується тільки для Decoupled SCA) | ASPSP надсилає PSU у web/mob версію платіжного застосунку ASPSP push-повідомлення для проходження SCA. Логіку пошуку PSU для надсилання push-повідомлення ASPSP розроблює самостійно. Перехід до кроку 16 основного сценарію для Decoupled SCA. |
| 16. Redirect PSU на веб-сторінку, web/mob app ASPSP (крок виконується тільки для Redirect SCA) | PISP перенаправляє PSU по лінку, отриманому від ASPSP у параметрі _links у відповіді на запит на ініціювання платіжної операції, для проходження SCA на стороні ASPSP. Перехід до кроку 17 основного сценарію для Redirect SCA. |
| 16. PSU самостійно заходить у платіжний застосунок ASPSP (крок виконується тільки для Decoupled SCA) | PSU самостійно заходить у платіжний застосунок ASPSP для проходження SCA та підтвердження виконання платіжної операції. Перехід до кроку 17 основного сценарію. |
| 17. Авторизуватись на web-page, у web/mobile app ASPSP (1+2 фактор SCA) | PSU авторизується у web/mobile платіжного застосунку ASPSP та вводить: 1 фактор SCA (наприклад, логін і пароль або біометрія), 2 фактор SCA (наприклад, електронний підпис, ОТП тощо). ASPSP самостійно визначає набір факторів SCA, які будуть застосовані. Стосовно електронного підпису слід керуватись вимогами ПП НБУ №172 від 20.12.2023р.: https://zakon.rada.gov.ua/laws/show/v0172500-23#Text. Перехід до кроку 18 основного сценарію. |
| 18. Валідувати 1+2 фактор SCA | ASPSP валідує 1+2 фактор SCA. Перехід до кроку 19 основного сценарію. |
| 19. Успішно? | Якщо валідація успішно пройдена — перехід на крок 20 основного сценарію. Якщо ні, спробувати ще (не більше 5 разів) — перехід на крок 17 основного сценарію, якщо кількість невдалих спроб менше або не дорівнює 5. Якщо ні (5 невдалих спроб авторизації або PSU відхилив платіж) — перехід до кроку 20.А альтернативного сценарію якщо кількість невдалих спроб більше 5. |
| 20. Встановити SCA статус psuAuthenticated | ASPSP встановлює SCA status=psuAuthenticated. Перехід до кроку 21 основного сценарію. |
| 21. Встановити статус платіжної операції ACTC | ASPSP встановлює статус платіжної операції ACTC. |
| 22. Підтвердити платіжну операцію і накласти 2 фактор SCA (електронний підпис, ОТП тощо) | PSU на web-page, у web/mobile платіжного застосунку ASPSP надає згоду на виконання платіжної операції та накладає 2 фактор SCA (1-й фактор наслідується із сторінки логування). Примітка: (1) всі реквізити, передані PISP при створенні платіжної операції, не можуть бути змінені на стороні ASPSP; (2) до цього кроку ASPSP може надати право PSU обрати рахунок, з якого буде здійснено платіжну операцію, якщо він не був переданий PISP при створенні платіжної операції (в полі debtorAccount); (3) до цього кроку ASPSP має право додати дані платника, яких не вистачає для виконання платіжної операції. Стосовно електронного підпису слід керуватись вимогами ПП НБУ №172 від 20.12.2023р.: https://zakon.rada.gov.ua/laws/show/v0172500-23#Text. Перехід до кроку 23 основного сценарію. |
| 23. Валідувати 2 фактор SCA | ASPSP валідує 2 фактор SCA введений PSU. Перехід до кроку 24 основного сценарію. |
| 24. Успішно? | Якщо валідація 2 фактору SCA пройдена успішно — відбувається перехід на крок 24 основного сценарію. Якщо Ні, спробувати ще (не більше 5 разів) — відбувається перехід на крок 21 основного сценарію. Якщо Ні (5 невдалих спроб авторизації або PSU відхилив платіжну операцію) — відбувається перехід на крок 20.А альтернативного сценарію. |
| 25. Встановити SCA статус finalised | ASPSP встановлює SCA status=finalised. Перехід до кроку 26 основного сценарію. |
| 26. Встановити статус платіжної операції PDNG | ASPSP встановлює статус платіжної операції PDNG. Перехід до кроку 27 основного сценарію. |
| 27. Відобразити інформацію про успішне підтвердження платіжної операції | ASPSP відображає PSU інформацію про успішне підтвердження платіжної операції. Перехід до кроку 28 основного сценарію. |
| 28. Повернути PSU у платіжний застосунок PISP (крок виконується тільки для Redirect SCA) | ASPSP повертає PSU у платіжний застосунок PISP. URI для повернення PSU ASPSP отримує у запиті на початок авторизації у параметрі TPP-Redirect-URI на кроці 9 основного сценарію. Перехід до кроку 29 основного сценарію. |
| 29. Виконати платіжну операції | ASPSP виконує платіжну операцію. Примітка: під час виконання платіжної операції ASPSP здійснює перевірки відповідно до внутрішніх процедур, які встановлені у ASPSP при здійсненні платіжних операцій, які ініційовані через інші канали обслуговування PSU. Перехід до кроку 30 основного сценарію. |
| 30. Статус виконання платіжної операції? | Якщо статус виконання платіжної операції “Успішно“ — перехід на крок 31 основного сценарію. Якщо статус виконання платіжної операції “Не успішно“ — перехід на крок 31.А альтернативного сценарію. |
| 31. Встановити статус платіжної операції: ACCC / ACSC | ASPSP в результаті виконання платіжної операції проставляє відповідний статус: ACCC — для миттєвого кредитового переказу, ACSC — для кредитового переказу, крім миттєвого. Перехід до кроку 32 основного сценарію. |
32. Виклик GET /v2/{payment-service}/{payment-product}/{paymentId} або GET /v2/{payment-service}/{payment-product}/{paymentId}/status | PISP для отримання статусу платіжної операції здійснює виклик GET /v2/{payment-service}/{payment-product}/{paymentId} або GET /v2/{payment-service}/{payment-product}/{paymentId}/status. PISP самостійно вирішує який із endpoints використовувати. Щоб не створювати ситуацію зайвих численних запитів, яку ASPSP може сприйняти як кіберзагрозу, рекомендовано PISP робити цей виклик при відкритті PSU розділу з платіжними операціями в платіжному застосунку PISP. Дія виконується тільки для Decoupled SCA. Параметри виклику описані у розділі 5. Перехід до кроку 33 основного сценарію. |
| 33. Перевірити QWAC та відомості в РПІ, request | ASPSP перевіряє: QWAC та відомості в Реєстрі платіжної інфраструктури (див. розділ 6.3 документу “Протокол функцій та заходів безпеки”); request syntax; semantics; paymentId. Перехід до кроку 34 основного сценарію. |
| 34. ОК? | Якщо перевірки пройдено успішно — перехід до кроку 35 основного сценарію, у іншому випадку — 35.А альтернативного сценарію. |
| 35. Надіслати OK response (HTTP code = 200) | ASPSP надсилає OK response з HTTP code = 200 відповідно до розділу 5. Перехід до кроку 36 основного сценарію. |
| 36. Оновити статус платіжної операції | PISP по paymentId знаходить платіжну операцію і оновлює її статус, отриманий на кроці 35. Завершення основного сценарію. |
| Альтернативний сценарій | |
| 4.А. Відобразити інфо про технічну помилку | PISP інформує PSU про технічну помилку, через яку ініцювання платіжної операції було завершено неуспішно. Альтернативний сценарій завершується. |
| 6.А. Надіслати NOK response (HTTP status code не = 201) | ASPSP надсилає NOK response згідно розділу 5 Протоколу функцій заходів безпеки та Data Dictionary. |
| 6.Б. Відобразити інфо про помилку | PISP інформує PSU про помилку, через яку ініцювання платіжної операції було завершено неуспішно. Альтернативний сценарій завершується. |
| 13.А. Надіслати NOK response (HTTP status code не = 201) | ASPSP надсилає NOK response згідно розділу 5 Протоколу функцій заходів безпеки та Data Dictionary. |
| 13.Б. Відобразити інфо про помилку | PISP інформує PSU про помилку, через яку ініцювання платіжної операції було завершено неуспішно. Альтернативний сценарій завершується. |
| 20.А. Відобразити інформацію про невдале підтвердження платіжної операції | ASPSP відображає PSU інформацію про невдале підтвердження платіжної операції (платіжна операція відхилена або не пройдено SCA). Для Decoupled SCA — перехід на крок 20.В альтернативного сценарію. Для Redirect SCA — перехід на крок 20.Б альтернативного сценарію. |
| 20.Б. Повернути PSU у платіжний застосунок PISP (крок виконується тільки для Redirect SCA) | ASPSP повертає PSU у платіжний застосунок PISP. За наявності TPP-Nok-Redirect-URI повертає PSU у платіжний застосунок PISP. Якщо TPP-Nok-Redirect-URI немає, то ASPSP використовує TPP-Redirect-URI. TPP-Nok-Redirect-URI ASPSP отримує у запиті на початок авторизації на кроці 9 основного сценарію. Перехід на крок 20.В альтернативного сценарію. |
| 20.В. Встановити SCA статус failed | ASPSP встановлює SCA status=failed. Перехід на крок 20.Г альтернативного сценарію. |
| 20.Г. Встановити статус платіжної операції RJCT | ASPSP встановлює статус платіжної операції RJCT. Альтернативний сценарій завершується. |
| 31.А. Встановити статус платіжної операції RJCT | ASPSP встановлює статус платіжної операції RJCT. Альтернативний сценарій завершується. |
| 35.А. Надіслати NOK response (HTTP status code не = 200) | ASPSP надсилає NOK response згідно розділу 5 Протоколу функцій заходів безпеки та Data Dictionary. Перехід на крок 35.Б альтернативного сценарію. |
| 35.Б. Повторити? | PISP визначає самостійно кількість повторень. Цей крок не є обов’язковим і PISP може не реалізовувати повторення виклику. Якщо кількість повторень виклику НЕ вичерпана — перехід на крок 32 основного сценарію. Якщо кількість повторень виклику вичерпана — альтернативний сценарій завершується. |