Додаток 3. Приклад тест-кейсів для контрактного тестування

Цей додаток містить приклади тест-кейсів для контрактного тестування PIS API (версія 2.1) з очікуваними позитивними та негативними результатами.

Тест №1.1. Ініціювання платіжної операції

1. POST /v2/payments/{payment-product} (див. розділ 4.1) | | Очікуваний результат | Позитивний:

• Платіжна операція створена, HTTP code = 201 (див. розділ 4.1).

Негативний:

• Платіжна операція не створена, HTTP code ≠ 201 (див. розділ 4.1), зокрема у випадках:
  • невідповідність або невалідність даних QWAC та реєстрі платіжної інфраструктури;
  • переданий некоректний IBAN платника (якщо був переданий);
  • IBAN платника відсутній у цього ASPSP (якщо був переданий);
  • балансовий рахунок не входить у перелік рахунків відкритого банкінгу;
  • валюта переказу не дорівнює UAH;
  • рахунок платника не дорівнює UAH;
  • сума платіжної операції не відповідає лімітам, встановленим ASPSP (мінімальна, максимальна сума платіжної операції);
  • некоректний request syntax;
  • некоректний semantics. | | Постумова | Створений платіж |

Тест №1.2. Авторизація ресурсу платіжної операції

1. POST /v2/{resource-path}/{resourceId}/{authorisation-category} (див. розділ 4.2) | | Очікуваний результат | Позитивний:

• Ресурс платіжної операції авторизований, HTTP code = 201 (див. розділ 4.2).

Негативний:

• Ресурс платіжної операції не авторизований, HTTP code ≠ 201 (див. розділ 4.2), зокрема у випадках:
  • невідповідність або невалідність даних QWAC та реєстрі платіжної інфраструктури;
  • переданий некоректний resourceId;
  • недостатньо коштів на рахунку для здійснення платіжної операції (ця перевірка може здійснюватись і після авторизації ресурсу платіжної операції; ASPSP самостійно вирішує, на якому етапі буде реалізована перевірка);
  • некоректний request syntax;
  • некоректний semantics. | | Постумова | Для SCA Redirect отриманий лінк для перенаправлення PSU для проходження SCA на стороні ASPSP. Для Decoupled — PSU отримав push-повідомлення для проходження SCA. |

Тест №1.3. Перевірка статусу платіжної операції

1. GET /v2/{payment-service}/{payment-product}/{paymentId}/status (повертає тільки статус платіжної операції) (див. розділ 4.3.1)

або

1. GET /v2/{payment-service}/{payment-product}/{paymentId} (повертає повну інформацію про платіжну операцію) (див. розділ 4.3.2)

Примітка: PISP на власний розсуд вирішує, чи потрібно тестувати обидва ендпоінти. | | Очікуваний результат | Позитивний:

• HTTP code = 200, отриманий статус платіжної операції (див. розділи 4.3.1 та 4.3.2 відповідно).

Негативний:

• HTTP code ≠ 200 (див. розділи 4.3.1 та 4.3.2 відповідно), зокрема у випадках:
  • невідповідність або невалідність даних QWAC та реєстрі платіжної інфраструктури;
  • некоректний request syntax;
  • некоректний semantics;
  • некоректний/неіснуючий paymentId. | | Постумова | Отриманий статус платіжної операції |

Примітки щодо полів QWAC (термінологія TPP)

1. TPP Registration Number — OrganizationIdentifier у QWAC. Наприклад, PSDU-NBU-123456, де 123456 — це код ID НБУ (NbuId) — єдиний ідентифікатор, що присвоюється Національним банком України установі.
2. TPP Name — це поле Organization (O) у QWAC.
3. TPP Role — RolesOfPSP(0.4.0.19495.1) у X509v3 extensions.qcStatements.
4. TPP National Competent Authority — OrganizationIdentifier — PSDU-NBU.