6. Use Case 5. Отримання балансу по рахунку або списку транзакції (до 31 календарного дня)

Цей розділ описує Use Case 5 для AIS API: отримання балансу по рахунку або списку транзакцій (до 31 календарного дня) за умови наявності дійсної згоди (consent) та доступу balances та/або transactions.

6.1. Опис Use Case 5

6.2. Activity diagram до Use Case 5

Примітка: activity diagram знаходиться у окремому файлі у додатку 1.

6.3. Опис кроків activity diagram

Основний сценарій

• QWAC та відомості в Реєстрі платіжної інфраструктури (див. розділ 6.3 Протоколу функцій та заходів безпеки);
• request syntax;
• semantics;
• consentId=valid (по ConsentID треба звірити всі дані, які є в базі даних по даній згоді з даними, які надійшли у request (наприклад, назва AISP, термін дії згоди, рахунок тощо).

Примітка: послідовність перевірок визначає ASPSP. Перелік перевірок, які може виконувати ASPSP на цьому кроці може бути значно ширшим і не наводиться у цьому документі тому, що не є предметом регулювання цього документу. | | 6. ОК? | Якщо всі перевірки пройдено успішно — відбувається перехід до кроку 7 основного сценарію, якщо ні — 7.A альтернативного сценарію. | | 7. Надіслати OK response (HTTP status code = 200) | ASPSP надсилає OK response з HTTP status code = 200 відповідно до розділу 3.1. У цій відповіді ASPSP надсилає у атрибуті accounts ідентифікатор кожного доступного рахунку для отримання інфрмації по рахунку (resourceId) для подальшого виклику потрібного endpoint. Перехід до кроку 8 основного сценарію. | | 8. Викликати GET /v2/accounts/{account-id}/balances або GET /v2/accounts/{account-id}/transactions {query-parameters} | AISP викликає GET /v2/accounts/{account-id}/balances для отримання балансу по рахунку (параметри відповідно до опису в розділі 5.2) або GET /v2/accounts/{account-id}/transactions {query-parameters} для отримання списку транзакцій по рахунку (параметри відповідно до опису в розділі 5.3). Перехід до кроку 9 основного сценарію. | | 9. Успішно? | Якщо виклик здійснено успішно — то відбувається перехід на крок 10 основного сценарію. Якщо виклик був неуспішний (HTTP status code = 50Х та інші помилки) і кількість повторень не вичерпана — перехід до кроку 8 основного сценарію. Якщо виклик був неуспішний (HTTP status code = 50Х та інші помилки) і кількість повторень вичерпана — перехід до кроку 9.A альтернативного сценарію. | | 10. Перевірити: QWAC та відомості в РПІ, request | ASPSP перевіряє:

• QWAC та відомості в Реєстрі платіжної інфраструктури (див. розділ 6.3 Протоколу функцій та заходів безпеки);
• request syntax;
• semantics;
• consentId=valid (по ConsentID треба звірити всі дані, які є в базі даних по цій згоді з даними, які надійшли у запиті (наприклад, назва AISP, термін дії згоди, рахунок тощо);
• frequencyPerDay — перевірка цього параметру здійснюється тільки якщо виклик ініційований AISP без участі PSU, тобто атрибут PSU-IP-Address не заповнений.

Примітка: На даний момент AISP (без участі PSU) дозволено у рамках множинної згоди (залежно від типу доступу: balances та/або transactions) здійснити по:

• 4 успішні виклики endpoint для отримання балансу GET /v2/accounts/{account-id}/balances;
• 4 успішні виклики для отримання списку транзакцій GET /v2/accounts/{account-id}/transactions {query-parameters} (отримання інформації у межах пагінації вважається одним викликом, оскільки здійснюється з одним і тим же X-Request-ID).
• 4 виклики для отримання ідентифікаторів рахунків GET /v2/accounts {query-parameters} без участі PSU (тобто AISP не передав IP-адреса PSU), якщо ASPSP підтримує повернення балансу у цьому endpoint (атрибут withBalance). Виклики GET /v2/accounts {query-parameters} не рахуються якщо ASPSP не підтримує повернення балансу у цьому endpoint (атрибут withBalance).

У рамках разової згоди дозволено 1 виклик одного з endpoint вище (залежно від типу доступу: balances та/або transactions).

Примітка: кількість викликів рахується по згоді, а не по рахунку.

Кількість викликів не обмежується, якщо отримання зазначеної вище інформації ініціюється самим PSU.

При перевищенні кількості викликів значення, вказаного у параметрі frequencyPerDay — у відповідь на виклик повертається HTTP status code 429. Для отримання інформації по API понад дозволене значення frequencyPerDay на комерційній основі — потрібно повторити запит згідно інструкцій виклику, вказаних цим ASPSP.

Примітка: послідовність перевірок визначає ASPSP. Перелік перевірок, які може виконувати ASPSP на цьому кроці може бути значно ширшим і не наводиться у цьому документі тому, що не є предметом регулювання цього документу. | | 11. ОК? | Якщо всі перевірки пройдено успішно — відбувається перехід до кроку 12 основного сценарію, якщо ні — 12.A альтернативного сценарію. | | 12. Надіслати OK response (HTTP status code = 200) | ASPSP надсилає OK response з HTTP status code = 200 відповідно до розділу 5.2 або 5.3 в залежності, який endpoint був викликаний. Перехід до кроку 13 основного сценарію. | | 13. Відобразити баланс або історію транзакцій | AISP відображає PSU інформацію відповідно до розділу 5.2 або 5.3 в залежності, який endpoint був викликаний. Основний сценарій завершується. |

Альтернативний сценарій