Open Banking

Версія	Опис змін	Дата
v.1.0	Початкова версія	30.04.26

 

Наведено загальний опис спеціалізованих інтерфейсів. Детальний опис відповідно до версії, яку використовує НПП знаходиться за адресою https://docs.api.upc.ua/api-services/compliance-apis

НПП з обслуговування рахунку надає доступ до рахунку користувача сторонньому НПП (Third Party Provider, TPP) через такі спеціалізовані інтерфейси:

1. PIS (Payment Initiation Service) — Сервіс ініціювання платежів

   Базовий URL-шлях: /pis/v2/

   Версія API: v2

2. AIS (Account Information Service) — Сервіс надання інформації про рахунок

   Базовий URL-шлях: /ais/v2/

   Версія API: v2

Версія	Опис змін	Дата
v.1.0	Початкова версія	30.04.26
v.1.1	Внесено уточненя до п.2.4 стосовно терміну 31 день для обсягу історії операцій	05.06.26

 

1. PIS (Payment Initiation Service) — Сервіс ініціювання платежів

Сервіс ініціювання платежів (PIS) дозволяє сторонньому НПП (TPP) ініціювати платежі від імені користувача платіжних послуг (PSU). Для ініціювання платежу TPP потребує авторизації (підтвердження транзакції) від PSU. PSU надає свою згоду в рамках сесії сильної автентифікації клієнта (SCA).

Основні функції інтерфейсу PIS:

• 1.1. Ініціювання платежу

TPP надсилає запит на ініціювання платежу за допомогою методу POST /pis/v2/payments/{payment-product}. У запиті передаються дані про рахунок платника (IBAN), суму та валюту переказу, дані отримувача (ім'я, ідентифікатор, IBAN рахунку) та реквізити призначення платежу. Платформа повертає унікальний ідентифікатор транзакції (paymentId) та початковий статус платежу (RCVD — отримано).

• 1.2. Запуск авторизації (SCA)

Після ініціювання платежу TPP викликає метод POST /pis/v2/payments/{payment-product}/{payment-id}/authorisations для явного запуску процедури авторизації. Підтримуються два режими SCA:

Decoupled SCA: платформа повертає повідомлення для PSU ($.psuMessage), наприклад, "Авторизуйте платіж у мобільному застосунку банку". PSU авторизує платіж безпосередньо у застосунку банку (наприклад, через push-сповіщення).

Redirect SCA: платформа повертає URL-адресу для перенаправлення PSU ($.links.scaRedirect.href). TPP перенаправляє PSU на сторінку банку для автентифікації та підтвердження платежу. Після авторизації банк перенаправляє PSU назад до TPP за вказаним адресою (Client-Redirect-URI).

• 1.3. Перевірка статусу платежу

TPP може перевірити поточний статус платежу за допомогою методу GET /pis/v2/payments/{payment-product}/{payment-id}/status. Платформа повертає актуальний статус транзакції ($.transactionStatus), наприклад, ACCC (успішно завершено). Підтримувані продукти платежу: instant-credit-transfers.

 

2. AIS (Account Information Service) — Сервіс надання інформації про рахунок

Сервіс надання інформації про рахунок (AIS) дозволяє сторонньому НПП (TPP) отримувати доступ до інформації про рахунок користувача платіжних послуг (PSU). Для доступу до інформації TPP повинен спочатку отримати авторизацію (підтвердження згоди) від PSU. На підставі підтвердженої згоди TPP може отримувати інформацію про рахунки PSU: залишки, історію транзакцій та інші відповідні дані.

Основні функції інтерфейсу AIS:

• 2.1. Створення згоди на доступ до рахунку

TPP надсилає запит на створення згоди методом POST /ais/v2/consents/account-access. У запиті передаються: IBAN рахунку, права доступу ("accountDetails", "balances", "transactions"), тип згоди, ознака повторюваного доступу (recurringIndicator), строк дії (validTo) та максимальна частота запитів на день (frequencyPerDay, максимум 4 рази на добу). Платформа повертає унікальний ідентифікатор згоди (consentId).

• 2.2. Авторизація згоди (SCA)

Після створення згоди TPP ініціює авторизацію через метод POST /ais/v2/consents/account-access/{consent-id}/authorisations. Підтримуються два режими SCA (Decoupled та Redirect — аналогічно до PIS). TPP перевіряє статус згоди методом GET /ais/v2/consents/account-access/{consent-id}/status до отримання статусу "valid" або "rejected".

• 2.3. Отримання переліку рахунків

TPP отримує перелік рахунків PSU методом GET /ais/v2/accounts?withBalance=true, передаючи заголовок Consent-ID з ідентифікатором підтвердженої згоди. Платформа повертає список рахунків із IBAN, валютою, ідентифікатором ресурсу, назвою рахунку та поточними балансами.

• 2.4. Отримання історії операцій

TPP отримує історію операцій за рахунком методом GET /ais/v2/accounts/{account-id}/transactions. Банк надає історію операцій за останні 31 день, враховуючи дату запиту. У разі, якщо банк надає історію операцій за період від 31 до 90 днів, запит може оброблюватись без додаткової SCA-авторизації. Для отримання операцій давніше 90 днів необхідна одноразова AIS-згода (recurringIndicator: false). Підтримується посторінкова вибірка (пагінація) за параметрами limit та offset..

Версія	Опис змін	Дата
v.1.0	Початкова версія	30.04.26

 

1. Загальні технічні характеристики

• 1.1. Архітектура та стандарт

Спеціалізовані інтерфейси побудовані за принципами REST API та базуються на специфікації XS2A (Access to Account), яка реалізована через платформу відкритого банкінгу (Open Banking Platform, OBP). XS2A є стандартним інтерфейсом доступу третіх сторін до платіжних рахунків відповідно до вимог PSD2.

• 1.2. Транспортний протокол

Протокол: HTTPS (HTTP over TLS/SSL). Усі запити передаються виключно по захищеному каналу HTTPS. Використання незахищеного протоколу HTTP не допускається.

• 1.3. Формат даних

Формат тіла запитів та відповідей: JSON (JavaScript Object Notation). Заголовок Content-Type: application/json обов'язковий для всіх запитів, що містять тіло (POST).

• 1.4. Версіонування

Поточна версія обох інтерфейсів: v2. Версія зазначається у базовому шляху URL: /pis/v2/ та /ais/v2/.

• 1.5. Обов'язкові заголовки HTTP (загальні для обох інтерфейсів)

X-Request-Id — унікальний ідентифікатор запиту (UUID формат), наприклад: dc7b16a5-4ac8-4fdc-9c4e-9f9d0387dc07. Використовується для ідентифікації та трасування запиту.

Content-Type — тип вмісту тіла запиту: application/json (для POST-запитів).

PSU-ID — ідентифікатор користувача платіжних послуг (PSU) у системі банку.

PSU-IP-Address — IP-адреса пристрою PSU.

Consent-ID — ідентифікатор підтвердженої AIS-згоди (для запитів до AIS після авторизації).

Client-Redirect-URI — URL для перенаправлення PSU після успішної авторизації (SCA Redirect).

Client-Redirect-Nok-URI — URL для перенаправлення PSU у разі невдалої авторизації (SCA Redirect).

 

2. Технічні характеристики інтерфейсу PIS (Payment Initiation Service)

• 2.1. Базовий URL-шлях /pis/v2/
• 2.2. Ендпоінти (кінцеві точки)
• 2.2.1. Ініціювання платежу

Метод та шлях: POST /pis/v2/payments/{payment-product}

Параметр шляху: payment-product — тип платіжного продукту (наразі підтримується: instant-credit-transfers).

Тіло запиту (JSON):

paymentIdentification.endToEndId — наскрізний ідентифікатор платежу (рядок).

debtorAccount.iban — IBAN рахунку платника.

debtorAccount.currency — валюта рахунку платника (наприклад, "UAH").

instructedAmount.currency — валюта суми переказу.

instructedAmount.amount — сума переказу (рядок у десятковому форматі, наприклад "12.21").

creditor.name — ім'я отримувача.

creditor.creditorId — ідентифікатор отримувача.

creditor.creditorIdType — тип ідентифікатора отримувача (наприклад, "PSPT").

creditorAccount.iban — IBAN рахунку отримувача.

creditorAccount.currency — валюта рахунку отримувача.

remittanceInformationUnstructured — масив рядків із призначенням платежу.

Відповідь (JSON): paymentId (UUID), transactionStatus ("RCVD"), _links.startAuthorisation.href.

• 2.2.2. Запуск авторизації платежу (SCA)

Метод та шлях: POST /pis/v2/payments/{payment-product}/{payment-id}/authorisations

Параметри шляху: payment-product, payment-id (отримано з попереднього кроку).

Заголовки: Client-Redirect-URI, Client-Redirect-Nok-URI (обов'язкові для Redirect SCA).

Відповідь для Decoupled SCA (JSON): scaStatus ("received"), authorisationId (UUID), psuMessage (текст повідомлення для PSU).

Відповідь для Redirect SCA (JSON): scaStatus ("received"), authorisationId (UUID), _links.scaRedirect.href (URL для перенаправлення PSU на SCA-сторінку банку).

• 2.2.3. Перевірка статусу платежу

Метод та шлях: GET /pis/v2/payments/{payment-product}/{payment-id}/status

Параметри шляху: payment-product, payment-id.

Відповідь (JSON): transactionStatus — статус транзакції (наприклад, "ACCC" — успішно завершено).

• 2.3. Процедура взаємодії (PIS Flow)

TPP ініціює платіж (POST /payments/{payment-product}) → отримує paymentId.

TPP запускає авторизацію (POST /payments/{payment-product}/{payment-id}/authorisations) → отримує authorisationId та або psuMessage (Decoupled) або scaRedirect URL (Redirect).

PSU авторизує платіж (через застосунок банку або банківську веб-сторінку залежно від режиму SCA).

TPP перевіряє статус платежу (GET /payments/{payment-product}/{payment-id}/status) → отримує transactionStatus.

TPP інформує PSU про результат виконання платежу.

• 2.4. Коди помилок, специфічні для PIS

404 — PRODUCT_UNKNOWN: вказаний платіжний продукт не підтримується банком.

400 — PAYMENT_FAILED: запит на ініціювання платежу не вдалося опрацювати.

403 — SERVICE_BLOCKED: сервіс недоступний для PSU через незалежне блокування з боку банку.

 

3. Технічні характеристики інтерфейсу AIS (Account Information Service)

• 3.1. Базовий URL-шлях /ais/v2/
• 3.2. Ендпоінти (кінцеві точки)
• 3.2.1. Створення AIS-згоди

Метод та шлях: POST /ais/v2/consents/account-access

Тіло запиту (JSON):

access.payments[].account.iban — IBAN рахунку, до якого надається доступ.

access.payments[].rights — масив прав доступу: "accountDetails", "balances", "transactions". Якщо вказано "balances" або "transactions", право "accountDetails" надається неявно.

consentType — тип згоди: "detailed".

recurringIndicator — ознака повторюваного доступу: true (постійний) або false (одноразовий).

validTo — дата закінчення дії згоди (формат: YYYY-MM-DD).

frequencyPerDay — максимальна кількість запитів на добу без присутності PSU (максимум: 4).

Відповідь (JSON): consentId (UUID), consentStatus ("received"), _links.startAuthorisation.href.

• 3.2.2. Запуск авторизації згоди (SCA)

Метод та шлях: POST /ais/v2/consents/account-access/{consent-id}/authorisations

Параметр шляху: consent-id (отримано з попереднього кроку).

Заголовки: Client-Redirect-URI, Client-Redirect-Nok-URI.

Відповідь для Decoupled SCA (JSON): scaStatus, authorisationId, psuMessage.

Відповідь для Redirect SCA (JSON): scaStatus, authorisationId, _links.scaRedirect.href.

• 3.2.3. Перевірка статусу згоди

Метод та шлях: GET /ais/v2/consents/account-access/{consent-id}/status

Відповідь (JSON): consentStatus — статус згоди ("received", "valid", "rejected" тощо).

• 3.2.4. Отримання переліку рахунків

Метод та шлях: GET /ais/v2/accounts

Параметр запиту: withBalance=true (для отримання балансів у відповіді).

Заголовок: Consent-ID — ідентифікатор підтвердженої AIS-згоди.

Відповідь (JSON): масив об'єктів accounts з полями: iban, currency, resourceId, name, balances[].balanceAmount, balances[].balanceType, balances[].referenceDate.

• 3.2.5. Отримання історії транзакцій

Метод та шлях: GET /ais/v2/accounts/{account-id}/transactions

Параметри запиту:

dateFrom — дата початку вибірки (без додаткового SCA доступна до 90 днів назад; для давніших транзакцій потрібна одноразова AIS-згода з recurringIndicator: false та правом "transactions").

limit — максимальна кількість записів транзакцій у відповіді (для пагінації).

offset — кількість пропущених записів від початку вибірки (для пагінації).

Пагінація: TPP збільшує значення offset на кількість вже отриманих записів. Ознакою завершення є відповідь із кількістю записів, меншою за limit, або порожній список. Якщо параметри пагінації не передані, кількість повернутих транзакцій визначається конкретним банком.

• 3.3. Процедура взаємодії (AIS Flow)

TPP створює AIS-згоду (POST /consents/account-access) → отримує consentId.

TPP запускає авторизацію згоди (POST /consents/account-access/{consent-id}/authorisations) → отримує authorisationId та або psuMessage (Decoupled) або scaRedirect URL (Redirect).

PSU авторизує згоду (через застосунок банку або банківську веб-сторінку).

TPP перевіряє статус згоди (GET /consents/account-access/{consent-id}/status) до отримання статусу "valid".

TPP отримує інформацію про рахунки та транзакції, передаючи Consent-ID у заголовку запиту.

• 3.4. Обмеження та ліміти

Максимальна частота запитів без присутності PSU: 4 рази на добу (frequencyPerDay ≤ 4).

Доступна глибина історії транзакцій без додаткового SCA: 90 календарних днів

• 3.5. Коди помилок, специфічні для AIS

401 — CONSENT_INVALID: згода недійсна або не надає необхідних прав доступу.

403 — CONSENT_UNKNOWN: згода не існує.

429 — ACCESS_EXCEEDED: перевищено денний ліміт у 4 GET-запити без присутності PSU.

400 — FORMAT_ERROR (пагінація транзакцій): параметр dateFrom містить дату, що перевищує 90 днів у минулому, для повторюваної AIS-згоди.

 

4. Процедури сильної автентифікації клієнта (SCA)

Обидва інтерфейси (PIS та AIS) підтримують два режими SCA:

• 4.1. Decoupled SCA (роз'єднана автентифікація)

Процедура: PSU отримує повідомлення або push-сповіщення від банку та авторизує операцію безпосередньо у застосунку банку, не залишаючи інтерфейс TPP. TPP отримує у відповіді поле psuMessage з текстом для PSU. Банк самостійно сповіщає PSU про необхідність авторизації.

• 4.2. Redirect SCA (автентифікація з перенаправленням)

Процедура: TPP перенаправляє PSU на URL-адресу банківської SCA-сторінки (scaRedirect.href), де PSU проходить автентифікацію та підтверджує операцію. Після завершення авторизації банк перенаправляє PSU назад до TPP за адресою Client-Redirect-URI (успіх) або Client-Redirect-Nok-URI (невдача).

 

5. Інструменти та вимоги НПП

• 5.1. Реєстрація та сертифікати

Для підключення до спеціалізованих інтерфейсів сторонній НПП повинен:

Пройти реєстрацію на Developer Portal (portal.api.upc.ua).

Отримати та налаштувати цифрові сертифікати для взаємної автентифікації TLS (mTLS) — відповідно до розділу "Certificates" порталу.

Налаштувати електронні підписи запитів — відповідно до розділу "Electronic signatures" порталу.

Зареєструвати застосунок у розділі "Applications" та оформити підписку на відповідний API-сервіс.

• 5.2. Технічні вимоги

HTTP-клієнт з підтримкою HTTPS/TLS та мутуальної автентифікації (mTLS).

Підтримка формату JSON для серіалізації та десеріалізації даних.

Здатність формувати унікальні UUID для заголовка X-Request-Id.

Реалізація логіки опитування статусу (polling) для перевірки статусу платежу та згоди.

Реалізація механізму пагінації для обходу великих наборів транзакцій (параметри limit та offset).

Наявність публічно доступних URL-адрес для Client-Redirect-URI та Client-Redirect-Nok-URI (для Redirect SCA).

• 5.3. Середовища

Sandbox (тестове середовище): доступне для розробки та тестування інтеграції.

Production (продуктивне середовище): для реальної взаємодії з платіжними рахунками PSU.

Версія	Опис змін	Дата
v.1.0	Початкова версія	30.04.26

 

Доступ до рахунку (Account Information Service)

1. Тестові сценарії для створення account Consent

Тест кейс #1 Сreate Consent тип "detailed" | POST /consents/account-access

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Передумови:

• Користувач зареєстрований в системі

• Має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

Кроки виконання:

1. Обрати провайдера до якого створюється Consent, зафіксувати providerId

2. обрати список accounts для створення Consent, зафіксувати IBANи

3. Зробити Виклик до API:

POST /providers/{providerId}/ais/v2/consents/account-access

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

TPP-Redirect-URI: "https://google.com"

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

PSU-IP-Address: "1.1.1.1"

TPP-Explicit-Authorisation-Preferred: true

Client-SCA-Approach-Preference: decoupled

// АБО: Client-SCA-Approach-Preference: redirect

PSU-ID: "+380971112233" // Не обов'язковий при Client-SCA-Approach-Preference redirect

PSU-ID-Type: "PHONE" // Не обов'язковий при Client-SCA-Approach-Preference redirect

BODY:

{
  "access": {
    "payments": [
      {
        "account": {
          "iban": "UA1234567890123456789012134567"
        },
        "rights": [
          "accountDetails",
          "balances",
          "transactions"
        ]
      }
    ]
  },
  "consentType": "detailed",
  "recurringIndicator": true,
  "validTo": "2026-06-28",
  "frequencyPerDay": "4"
}

Очікуваний результат:

1. Створено Consent з типом "detailed"

2. У відповіді присутній consentId Приклад відповіді:

{
  "consentStatus": "received",
  "consentId": "019c0916-ef4d-7228-babe-e0b2a03d57dd",
  "_links": {
    "self": {
      "href": "/sandbox/ais/v2.0/consents/account-access/019c0916-ef4d-7228-babe-e0b2a03d57dd"
    },
    "status": {
      "href": "/sandbox/ais/v2.0/consents/account-access/019c0916-ef4d-7228-babe-e0b2a03d57dd/status"
    },
    "startAuthorisation": {
      "href": "/sandbox/ais/v2.0/consents/account-access/019c0916-ef4d-7228-babe-e0b2a03d57dd/authorisations"
    }
  }
}

 

Тест кейс #2 Сreate Consent тип "accountList" | POST /consents/account-access

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Передумови:

• Користувач зареєстрований в системі

• Має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

Кроки виконання:

1. Обрати провайдера до якого створюється Consent, зафіксувати providerId

2. Зробити Виклик до API:

POST /providers/{providerId}/ais/v2/consents/account-access

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

TPP-Redirect-URI: "https://google.com"

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

PSU-IP-Address: "1.1.1.1"

TPP-Explicit-Authorisation-Preferred: true

Client-SCA-Approach-Preference: decoupled

// АБО: Client-SCA-Approach-Preference: redirect

PSU-ID: "+380971112233" // Не обов'язковий при Client-SCA-Approach-Preference redirect

PSU-ID-Type: "PHONE" // Не обов'язковий при Client-SCA-Approach-Preference redirect

BODY:

{
  "access": {
    "payments": [
      {
        "rights": [
          "accountDetails",
          "balances",
          "transactions"
        ]
      }
    ]
  },
  "consentType": "accountList",
  "recurringIndicator": true,
  "validTo": "2026-06-28",
  "frequencyPerDay": "4"
}

Очікуваний результат:

1. Створено Consent з типом "accountList"

2. У відповіді присутній consentId Приклад відповіді:

{
  "consentStatus": "received",
  "consentId": "019c0916-ef4d-7228-babe-e0b2a03d57dd",
  "_links": {
    "self": {
      "href": "/sandbox/ais/v2.0/consents/account-access/019c0916-ef4d-7228-babe-e0b2a03d57dd"
    },
    "status": {
      "href": "/sandbox/ais/v2.0/consents/account-access/019c0916-ef4d-7228-babe-e0b2a03d57dd/status"
    },
    "startAuthorisation": {
      "href": "/sandbox/ais/v2.0/consents/account-access/019c0916-ef4d-7228-babe-e0b2a03d57dd/authorisations"
    }
  }
}

 

Тест кейс #3 Сreate Consent тип "aspspManaged" | POST /consents/account-access

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Важливо:

• тип "aspspManaged" підтримується лише зі специфікації версії 2.2.0 (2.0.6)

Передумови:

• Користувач зареєстрований в системі

• Має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

Кроки виконання:

1. Обрати провайдера до якого створюється Consent, зафіксувати providerId

2. Зробити Виклик до API:

POST /providers/{providerId}/ais/v2.0/consents/account-access

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

TPP-Redirect-URI: "https://google.com"

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

PSU-IP-Address: "1.1.1.1"

TPP-Explicit-Authorisation-Preferred: true

Client-SCA-Approach-Preference: decoupled

// АБО: Client-SCA-Approach-Preference: redirect

PSU-ID: "+380971112233" // Не обов'язковий при Client-SCA-Approach-Preference redirect

PSU-ID-Type: "PHONE" // Не обов'язковий при Client-SCA-Approach-Preference redirect

BODY:

{
  "access": {
    "payments": [
      {
        "rights": [
          "accountDetails",
          "balances",
          "transactions"
        ]
      }
    ]
  },
  "consentType": "aspspManaged",
  "recurringIndicator": true,
  "validTo": "2026-06-28",
  "frequencyPerDay": "4"
}

Очікуваний результат:

1. Створено Consent з типом "aspspManaged"

2. У відповіді присутній consentId Приклад відповіді:

{
  "consentStatus": "received",
  "consentId": "019c0916-ef4d-7228-babe-e0b2a03d57dd",
  "_links": {
    "self": {
      "href": "/sandbox/ais/v2.0/consents/account-access/019c0916-ef4d-7228-babe-e0b2a03d57dd"
    },
    "status": {
      "href": "/sandbox/ais/v2.0/consents/account-access/019c0916-ef4d-7228-babe-e0b2a03d57dd/status"
    },
    "startAuthorisation": {
      "href": "/sandbox/ais/v2.0/consents/account-access/019c0916-ef4d-7228-babe-e0b2a03d57dd/authorisations"
    }
  }
}

 

2. Тестові сценарії для авторизації Consent

Тест кейс #4 Авторизація Consent | POST /consents/account-access/{consent-id}/authorisations

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Передумови:

• Користувач має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

• Існує створений Consent (див. Тест кейс #1, #2 або #3), зафіксовано consentId

Кроки виконання:

1. Зробити Виклик до API:

POST /providers/{providerId}/ais/v2/consents/account-access/{consent-id}/authorisations

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

TPP-Redirect-URI: "https://google.com"

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

PSU-IP-Address: "1.1.1.1"

TPP-Explicit-Authorisation-Preferred: true

Client-SCA-Approach-Preference: decoupled

// АБО: Client-SCA-Approach-Preference: redirect

PSU-ID: "+380971112233" // Не обов'язковий при Client-SCA-Approach-Preference redirect

PSU-ID-Type: "PHONE" // Не обов'язковий при Client-SCA-Approach-Preference redirect

BODY:

{}

1. Створено авторизацію для Consent

2. У відповіді присутній scaStatus та authorisationId

Приклад відповіді:

 { "consentStatus": "received", "consentId": "019c7aab-5419-7046-bcf5-e718134e0adc", "_links": { "self": { "href": "/sandbox/ais/v2.0/consents/account-access/019c7aab-5419-7046-bcf5-e718134e0adc" }, "status": { "href": "/sandbox/ais/v2.0/consents/account-access/019c7aab-5419-7046-bcf5-e718134e0adc/status" }, "startAuthorisation": { "href": "/sandbox/ais/v2.0/consents/account-access/019c7aab-5419-7046-bcf5-e718134e0adc/authorisations" } } }

Для Client-SCA-Approach-Preference: redirect

1. Прейти за посиланням scaRedirect (якщо Client-SCA-Approach-Preference: redirect) або ініціювати SCA через інший канал (якщо Client-SCA-Approach-Preference: decoupled)

2. на Sandbox сторінці створено обробник, де можна прийняти або відхилити запит на авторизацію:

3. Підьтвердити авторизацію натиснувши "Accept"

Для Client-SCA-Approach-Preference: decoupled

Приклад відповіді:

 { "scaStatus": "finalised", "_links": { "scaStatus": { "href": "/sandbox/ais/v2.0/consents/account-access/019c7b2e-6a91-7644-ae5d-c2617e6931d5/authorisations/019c7b2e-7c47-7d5b-beb5-593ac088df1e" } }, "authorisationId": "019c7b2e-7c47-7d5b-beb5-593ac088df1e", "psuMessage": "Authorize payment in Bank's mobile application" }

Для sandbox доступний емулятор, який автоматично підтверджує авторизацію через 1 секунду після створення авторизації.

Очікуваний результат:

1. Відбувається перенаправлення на Google (або інший вказаний TPP-Redirect-URI, якщо середовище не sandbox)

2. При виклику статусу GET по ConsentId має бути статус "valid" (див. Тест кейс #5)

 

3. Тестові сценарії перевірки Consent та Consent Authorisation

Тест кейс #5 Отримання статусу Consent | GET /consents/account-access/{consent-id}/status

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Передумови:

• Користувач має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

• Існує створений Consent (див. Тест кейс #1, #2 або #3), зафіксовано consentId

Кроки виконання:

1. Зробити Виклик до API:

GET /providers/{providerId}/ais/v2/consents/account-access/{consent-id}/status

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

BODY:

null

Очікуваний результат:

1. Тіло відповіді містить поточний статус Consent Приклад відповіді:

 { "consentStatus": "valid" }

 

Тест кейс #6 Отримання статусу всіх Authorisations для одного Consent | GET /consents/account-access/{consent-id}/authorisations

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Передумови:

• Користувач має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

• Існує створений Consent (див. Тест кейс #1, #2 або #3), зафіксовано consentId

Кроки виконання:

1. Зробити Виклик до API:

GET /providers/{providerId}/ais/v2/consents/account-access/{consent-id}/authorisations

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

BODY:

null

Очікуваний результат:

1. Тіло відповіді містить список id авторизацій для Consent Приклад відповіді:

 { "authorisationIds": [ "019c0e6d-1ef7-7f4e-a552-d7cec5ff34d9" ] }

 

Тест кейс #7 Отримання статусу унікального Authorisation Consent | GET /consents/account-access/{consent-id}/authorisations/{authorisation-id}

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Передумови:

• Користувач має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

• Існує створений Consent (див. Тест кейс #1, #2 або #3), зафіксовано consentId

• Існує створена авторизація для Consent (див. Тест кейс #4), зафіксовано authorisationId (див. Тест кейс #6)

Кроки виконання:

1. Зробити Виклик до API:

GET /providers/{providerId}/ais/v2/consents/account-access/{consent-id}/authorisations/{authorisation-id}

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

BODY:

null

Очікуваний результат:

1. Тіло відповіді містить поточний статус авторизації Consent Приклад відповіді:

 { "scaStatus": "finalised", "_links": { "scaStatus": { "href": "/sandbox/ais/v2.0/consents/account-access/019c0e6c-f7cf-70f7-983f-05df521de43d/authorisations/019c0e6d-1ef7-7f4e-a552-d7cec5ff34d9" }, "scaRedirect": { "href": "https://portal.preprod.api.upc.ua/sca-client/mock/upc/bfdb6794-bcb8-4dde-9f3b-07acf73ef202/019c0e6d-1ef7-7f4e-a552-d7cec5ff34d9/consent" } }, "authorisationId": "019c0e6d-1ef7-7f4e-a552-d7cec5ff34d9" }

 

Тест кейс #8 Отримання об'єкту Consent | GET /consents/account-access/{consent-id}

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Передумови:

• Користувач має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

• Існує створений Consent (див. Тест кейс #1, #2 або #3), зафіксовано consentId

Кроки виконання:

1. Зробити Виклик до API:

GET /providers/{providerId}/ais/v2/consents/account-access/{consent-id}

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

BODY:

{}

Очікуваний результат:

1. Тіло відповіді містить деталі Consent: поточний стату, права доступу, тип, термін дії тощо Приклад відповіді:

 { "consentStatus": "valid", "_links": { "self": { "href": "/sandbox/ais/v2.0/consents/account-access/019c0e6c-f7cf-70f7-983f-05df521de43d" }, "status": { "href": "/sandbox/ais/v2.0/consents/account-access/019c0e6c-f7cf-70f7-983f-05df521de43d/status" }, "account": { "href": "/sandbox/ais/v2.0/accounts" } }, "access": { "payments": [ { "rights": [ "accountDetails", "balances", "transactions" ] } ] }, "consentType": "accountList", "recurringIndicator": true, "validTo": "2026-06-28", "frequencyPerDay": 4, "combinedServiceIndicator": false }

 

Тест кейс #9 Відкликання Consent | DELETE /consents/account-access/{consent-id}

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Передумови:

• Користувач має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

• Існує створений Consent (див. Тест кейс #1, #2 або #3), зафіксовано consentId

Кроки виконання:

1. Зробити Виклик до API:

DELETE /providers/{providerId}/ais/v2/consents/account-access/{consent-id}

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

BODY:

null

Очікуваний результат:

Отримано відповідь з кодом 204 No Content. При подальшому запиті статусу Consent (див. Тест кейс #5) має бути "terminatedByTpp" чи "revokedByPsu" залежно від того, хто ініціював відкликання.

 

4. Тестові сценарії використання account Consent

 

ВАЖЛИВО: Передумова для наступних тест кейсів

• Користувач має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

• Існує створений Consent (див. Тест кейс #1, #2 або #3) та він має статус "valid" (див. Тест кейс #4)

• Зафіксовано consentId

 

Тест кейс #10 Отримання списку рахунків | GET /accounts

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Кроки виконання:

1. Зробити Виклик до API:

GET /providers/{providerId}/ais/v2/accounts

Query parameters:

withBalance: boolean // Ігноється, якщо Consent не передбачає доступ до балансів

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

Consent-ID: "{consentId}"

PSU-IP-Address: "8.8.8.8"

PSU-Corporate-ID: "123456789" // Не обов'язковий

PSU-Corporate-ID-Type: "PHONE" // Не обов'язковий

BODY:

null

Очікуваний результат:

Список рахунків, які відповідають правам доступу, визначеним у Consent. Якщо Consent передбачає доступ до балансів, то у відповіді також будуть включені баланси для кожного рахунку.

Приклад відповіді без балансів:

 { "accounts": [ { "iban": "UA1234567890123456789012134567", "currency": "UAH", "resourceId": "e555222c-6304-40aa-9933-7952e2fd9999", "name": "Current account", "cashAccountType": "CACC", "_links": { "balances": { "href": "/sandbox/ais/v2.0/accounts/{resourceId}/balances" }, "transactions": { "href": "/sandbox/ais/v2.0/accounts/{resourceId}/transactions?dateFrom=2017-01-01&bookingStatus=both" } } } ] }

Приклад відповіді з балансами:

 { "accounts": [ { "iban": "UA313220000000026007233566001", "currency": "UAH", "resourceId": "e555222c-6304-40aa-9933-7952e2fd9999", "name": "Current account", "cashAccountType": "CACC", "balances": [ { "balanceAmount": { "currency": "UAH", "amount": "500000.00" }, "balanceType": "closingBooked" }, { "balanceAmount": { "currency": "UAH", "amount": "500000.00" }, "balanceType": "expected" } ], "_links": { "balances": { "href": "/sandbox/ais/v2.0/accounts/{resourceId}/balances" }, "transactions": { "href": "/sandbox/ais/v2.0/accounts/{resourceId}/transactions?dateFrom=2017-01-01&bookingStatus=both" } } } ] }

 

Тест кейс #11 Отримання деталей рахунку | GET /accounts/{account-id}

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Кроки виконання:

1. Зробити Виклик до API:

GET /providers/{providerId}/ais/v2/accounts/{account-id}

Query parameters:

withBalance: boolean // Ігноється, якщо Consent не передбачає доступ до балансів

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

Consent-ID: "{consentId}"

PSU-IP-Address: "8.8.8.8"

PSU-Corporate-ID: "123456789" // Не обов'язковий

PSU-Corporate-ID-Type: "PHONE" // Не обов'язковий

BODY:

null

Очікуваний результат:

Надає деталі по рахунку, якщо у Consent передбачені права доступу. Якщо Consent передбачає доступ до балансів, і withBalance=true то відповіді також будуть включені баланси для кожного рахунку.

Приклад відповіді без балансів:

 { "iban": "UA1234567890123456789012134567", "currency": "UAH", "resourceId": "e555222c-6304-40aa-9933-7952e2fd9999", "name": "Current account", "cashAccountType": "CACC", "_links": { "balances": { "href": "/sandbox/ais/v2.0/accounts/{resourceId}/balances" }, "transactions": { "href": "/sandbox/ais/v2.0/accounts/{resourceId}/transactions?dateFrom=2017-01-01&bookingStatus=both" } } }

Приклад відповіді з балансами:

 { "account": { "iban": "UA313220000000026007233566001", "currency": "UAH", "resourceId": "e55022cc-6304-40aa-9733-7952e2fd9597", "name": "Current account", "cashAccountType": "CACC", "balances": [ { "balanceAmount": { "currency": "UAH", "amount": "500000.00" }, "balanceType": "closingBooked" } ], "_links": { "balances": { "href": "/sandbox/ais/v2.0/accounts/e55022cc-6304-40aa-9733-7952e2fd9597/balances" }, "transactions": { "href": "/sandbox/ais/v2.0/accounts/e55022cc-6304-40aa-9733-7952e2fd9597/transactions?dateFrom=2017-01-01&bookingStatus=both" } } } }

 

Тест кейс #12 Отримання транзакцій рахунку | GET /accounts/{account-id}/transactions

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Кроки виконання:

1. Зробити Виклик до API:

GET /providers/{providerId}/ais/v2/accounts/{account-id}/transactions

Query parameters:

withBalance: boolean // Ігноється, якщо Consent не передбачає доступ до балансів

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

Consent-ID: "{consentId}"

PSU-IP-Address: "8.8.8.8"

PSU-Corporate-ID: "123456789" // Не обов'язковий

PSU-Corporate-ID-Type: "PHONE" // Не обов'язковий

BODY:

null

Очікуваний результат:

Надає деталі по транзакціям, якщо у Consent передбачені права доступу. Приклад відповіді:

 { "account": { "iban": "UA313220000000026007233566001", "currency": "UAH" }, "transactions": { "booked": [ { "transactionId": 123, "debtor": { "name": "Debtor name" }, "debtorAccount": { "iban": "LV80BANK0000435195001", "currency": "EUR" }, "creditor": { "name": "Creditor name" }, "creditorAccount": { "iban": "LV80BANK0000435195321", "currency": "EUR" }, "transactionAmount": { "currency": "EUR", "amount": 123.32 }, "bookingDate": "12.12.2012", "valueDate": "12.12.2012", "remittanceInformationUnstructured": "Some details" } ], "pending": [], "_links": { "account": { "href": "/sandbox/ais/v2.0/accounts/c59ab17b-6a71-4052-aef5-72165783f4bf" } } }, "size": 0, "limit": 20 } 

 

Тест кейс #13 Отримання деталей транзакції | GET /accounts/{account-id}/transactions/{transactionId}

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Кроки виконання:

1. Зробити Виклик до API:

GET /providers/{providerId}/ais/v2/accounts/{account-id}/transactions/{transaction-іd}

Query parameters:

dateFrom: date // Обов'язковий, у форматі YYYY-MM-DD

bookingStatus: string // обов'язковий. Можливі значення - booked, pending, both

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

Consent-ID: "{consentId}"

PSU-IP-Address: "8.8.8.8"

PSU-Corporate-ID: "123456789" // Не обов'язковий

PSU-Corporate-ID-Type: "PHONE" // Не обов'язковий

BODY:

null

Очікуваний результат:

Надає деталі по транзакції, якщо у Consent передбачені права доступу. Приклад відповіді:

 

 { "account": { "iban": "LV80BANK0000435195001", "currency": "EUR" }, "transactionsDetails": { "transactionId": 123, "debtor": { "name": "Debtor name" }, "debtorAccount": { "iban": "LV80BANK0000435195001", "currency": "EUR" }, "creditor": { "name": "Creditor name" }, "creditorAccount": { "iban": "LV80BANK0000435195321", "currency": "EUR" }, "transactionAmount": { "currency": "EUR", "amount": 123.32 }, "bookingDate": "12.12.2012", "valueDate": "12.12.2012", "remittanceInformationUnstructured": "Some details" } }

 

Ініціація платежу (Payment Initiation Service)

1. Тестові сценарії Payment Initiation Service

Тест кейс #1 Сreate consent initiation payments | POST /payments/instant-credit-transfers | POST /payments/credit-transfers

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Передумови:

• Користувач зареєстрований в системі

• Має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

Кроки виконання:

1. Обрати провайдера до якого створюється платіж, зафіксувати providerId

2. обрати тип {payment-product} - instant-credit-transfers або credit-transfers

3. Зробити виклик до API:

POST /providers/{provider-id}/pis/v2/payments/{payment-product}

HEADERS:

X-Request-ID: 123e4567-e89b-12d3-a456-426614174000 // {uuid}

PSU-IP-Address: "1.1.1.1"

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

BODY:

 { "debtorAccount": { "iban": "UA313220000000026007233566001", "currency": "UAH" }, "instructedAmount": { "currency": "UAH", "amount": "12.21" }, "creditor": { "name": "Coden Postal", "creditorId": "CP122540", "creditorIdType": "PSPT" }, "creditorAccount": { "iban": "UA633220000000029908753443001", "currency": "UAH" }, "remittanceInformationUnstructured": [ "Some details" ] } 

Очікуваний результат:

1. Створено платіж з "transactionStatus": "RCVD"

2. У відповіді присутній "paymentId" Приклад відповіді:

 { "transactionStatus": "RCVD", "paymentId": "019cfaf3-6d52-76a0-9064-969a181c03ee", "_links": { "self": { "href": "/sandbox/pis/v2.0/payments/instant-credit-transfers/019cfaf3-6d52-76a0-9064-969a181c03ee" }, "status": { "href": "/sandbox/pis/v2.0/payments/instant-credit-transfers/019cfaf3-6d52-76a0-9064-969a181c03ee/status" }, "startAuthorisation": { "href": "/sandbox/pis/v2.0/payments/instant-credit-transfers/019cfaf3-6d52-76a0-9064-969a181c03ee/authorisations" } } }

 

Тест кейс #2 Старт авторизації платежу| POST /payments/{payment-product}/{payment-id}/authorisations

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Передумови:

• Користувач має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

• Існує створений платіж (див. Тест кейс #1), зафіксовано paymentId

УВАГА: тип {payment-product} в запиті повинен відповідати типу, для якого створювався платіж у Тест кейс #1

Можливі значення {payment-product} - instant-credit-transfers або credit-transfers

Кроки виконання:

1. Зробити Виклик до API:

POST /providers/{provider-id}/pis/v2/payments/{payment-product}/{payment-id}/authorisations

HEADERS:

X-Request-ID: 123e4567-e89b-12d3-a456-426614174000

Client-Redirect-URI: https://google.com

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

PSU-ID: "2353909119" // use this value for sandbox

PSU-ID-Type: "PHONE"

BODY:

{}

Очікуваний результат:

1. Створено платіж з "transactionStatus": "RCVD"

2. У відповіді присутній "paymentId" Приклад відповіді:

 { "scaStatus": "received", "_links": { "scaStatus": { "href": "/sandbox/pis/v2.0/payments/instant-credit-transfers/019cfb75-7982-78b5-9a50-b92813afcd7b/authorisations/019cfb75-8e7d-755d-bbc2-e1e5928a3698" }, "scaRedirect": { "href": "https://portal.preprod.api.upc.ua/sca-client/mock/upc/bfdb6794-bcb8-4dde-9f3b-07acf73ef202/019cfb75-8e7d-755d-bbc2-e1e5928a3698/consent" } }, "authorisationId": "019cfb75-8e7d-755d-bbc2-e1e5928a3698" }

Для Client-SCA-Approach-Preference: redirect

Додатково: на sandbox доступна емуляція підтвердження платежу з боку користувача з PSU-ID: "2353909119".

1. Перейти за посиланням у _links/scaRedirect (якщо Client-SCA-Approach-Preference: redirect) або ініціювати SCA через інший канал (якщо Client-SCA-Approach-Preference: decoupled)

2. на Sandbox сторінці створено обробник, де можна прийняти або відхилити запит на авторизацію:

3. Підтвердити авторизацію натиснувши "Confirm"

2. Тестові сценарії перевірки платежу

Тест кейс #3 Отримання деталей платежу | GET /payments/{payment-product}/{payment-id}

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Передумови:

• Користувач має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

• Існує створений платіж (див. Тест кейс #1, #2), зафіксовано payment-id

Кроки виконання:

1. Зробити Виклик до API:

GET /providers/{provider-id}/pis/{apiGroupVersion}/payments/{payment-product}/{payment-id}

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

BODY:

null

Очікуваний результат:

1. Тіло відповіді містить поточний статус Consent Приклад, фрагмент відповіді:

 { "transactionStatus": "RCVD", "_links": { "self": { "href": "/sandbox/pis/v2.0/payments/instant-credit-transfers/019cfbb3-d015-7a47-bd16-76f18e90d58e" } //... } } 

Тест кейс #4 Отримання статус платежу | GET /payments/{payment-product}/{payment-id}/status

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Передумови:

• Користувач має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

• Існує створений Consent (див. Тест кейс #1, #2), зафіксовано consentId (він же payment-id)

Кроки виконання:

1. Зробити Виклик до API:

GET /providers/{provider-id}/pis/{apiGroupVersion}/payments/{payment-product}/{payment-id}/status

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

BODY:

null

Очікуваний результат:

1. Тіло відповіді містить поточний статус Consent Приклад, фрагмент відповіді:

 { "transactionStatus": "RCVD" }

 

Тест кейс #5 Отримання авторизацій платежу | GET /payments/{payment-product}/{payment-id}/authorisations

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Передумови:

• Користувач має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

• Існує створений платіж (див. Тест кейс #1, #2), зафіксовано consentId (він же payment-id)

Кроки виконання:

1. Зробити Виклик до API:

GET /providers/{provider-id}/pis/{apiGroupVersion}/payments/{payment-product}/{payment-id}/authorisations

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

BODY:

null

Очікуваний результат:

1. Тіло відповіді містить наявні authorisationIds Приклад відповіді:

 { "authorisationIds": [ "019cfbb3-eee5-771a-b877-89a5a17cd505" ] } 

Тест кейс #6 Отримання деталі авторизації платежу | GET /payments/{payment-product}/{payment-id}/authorisations/{authorisation-id}

Документація API

Вимоги до заголовків та тіла запиту описані в документації до відповідної версії

Передумови:

• Користувач має дійсний токен доступу (залогінений)

  • POST https://{portal_url}/auth/realms/participants/protocol/openid-connect/token

• Існує створений платіж (див. Тест кейс #1, #2), зафіксовано consentId (він же payment-id)

• зафіксовано authorisation-id (див. Тест кейс #5)

Кроки виконання:

1. Зробити Виклик до API:

GET /providers/{provider-id}/pis/{apiGroupVersion}/payments/{payment-product}/{payment-id}/authorisations/{authorisation-id}

HEADERS:

X-Request-ID: "72ebf0c7-31d4-43be-8786-261bd4e5d8a3" // {uuid}

Content-Type: application/json

Authorization: "Bearer {openid-connect/token}"

BODY:

null

Очікуваний результат:

1. Тіло відповіді містить деталі authorisationId Приклад відповіді:

 { "scaStatus": "finalised", "_links": { "scaStatus": { "href": "/sandbox/pis/v2.0/payments/instant-credit-transfers/019cfbb3-d015-7a47-bd16-76f18e90d58e/authorisations/019cfbb3-eee5-771a-b877-89a5a17cd505" }, "scaRedirect": { "href": "https://portal.preprod.api.upc.ua/sca-client/mock/upc/bfdb6794-bcb8-4dde-9f3b-07acf73ef202/019cfbb3-eee5-771a-b877-89a5a17cd505/consent"