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 Создание Consent типа "detailed" | POST /consents/account-access

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

Требования к заголовкам и телу запроса описаны в документации соответствующей версии.

Предусловия:

Пользователь зарегистрирован в системе

Имеет действительный токен доступа (выполнен вход в систему)

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

Шаги выполнения:

Выбрать провайдера, для которого создается Consent, зафиксировать providerId

Выбрать список accounts для создания Consent, зафиксировать IBAN

Выполнить вызов 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" // не обязательно при redirect

PSU-ID-Type: "PHONE" // не обязательно при redirect

BODY:

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

Ожидаемый результат:

Создан Consent типа "detailed"

В ответе присутствует 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 типа "accountList" | POST /consents/account-access

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

Требования к заголовкам и телу запроса описаны в документации соответствующей версии.

Предусловия:

Пользователь зарегистрирован в системе

Имеет действительный токен доступа

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

Шаги выполнения:

Выбрать провайдера, зафиксировать providerId

Выполнить вызов API:

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

BODY:

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

Ожидаемый результат:

Создан Consent типа "accountList"

В ответе присутствует consentId

Тест-кейс №3 Создание Consent типа "aspspManaged" | POST /consents/account-access

Важно:

тип "aspspManaged" поддерживается только в версии спецификации 2.2.0 (2.0.6)

Предусловия:

Пользователь зарегистрирован в системе

Имеет действительный токен доступа

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

Шаги выполнения:

Выбрать провайдера, зафиксировать providerId

Выполнить вызов API:

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

BODY:

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

Ожидаемый результат:

Создан Consent типа "aspspManaged"

2. Тестовые сценарии авторизации Consent

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

Предусловия:

Пользователь имеет действительный токен доступа

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

Существует созданный Consent (см. тест-кейсы #1–#3), зафиксирован consentId

Шаги выполнения:

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

BODY:

 {} 

Ожидаемый результат:

Создана авторизация Consent

В ответе присутствуют scaStatus и authorisationId

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

Перейти за ссылкой scaRedirect (если Client-SCA-Approach-Preference: redirect) или инициировать SCA через другой канал (если Client-SCA-Approach-Preference: decoupled)

На странице Sandbox доступен обработчик, где можно принять или отклонить запрос на авторизацию:

Подтвердить авторизацию нажатием "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 секунду после создания авторизации.

Ожидаемый результат:

Происходит перенаправление на Google (или другой указанный TPP-Redirect-URI, если среда не sandbox)

При вызове статуса GET по ConsentId статус должен быть "valid" (см. Тест-кейс #5)

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

Тест-кейс №5 Получение статуса Consent | GET /consents/account-access/{consent-id}/status

Предусловия:

Пользователь имеет действительный токен доступа

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

Существует созданный Consent (см. тест-кейсы #1–#3), зафиксирован consentId

Шаги выполнения:

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

BODY:

null

Ожидаемый результат:

Ответ содержит текущий статус Consent

 { "consentStatus": "valid" } 

Тест-кейс №6 Получение списка всех Authorisations для одного Consent | GET /consents/account-access/{consent-id}/authorisations

Шаги выполнения:

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

BODY:

null

Ожидаемый результат:

Ответ содержит список authorisationIds

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

Тест-кейс №7 Получение статуса отдельной Authorisation Consent | GET /consents/account-access/{consent-id}/authorisations/{authorisation-id}

Шаги выполнения:

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

BODY:

null

Ожидаемый результат:

 { "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}

Шаги выполнения:

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

BODY:

{}

Ожидаемый результат:

Ответ содержит детали 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}

Шаги выполнения:

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

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–#3) со статусом "valid" (см. тест-кейс #4)

Зафиксирован consentId

Тест-кейс №10 Получение списка счетов | GET /accounts

Шаги выполнения:

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

Query parameters:

withBalance: boolean // игнорируется, если Consent не предусматривает доступ к балансам

BODY:

null

Ожидаемый результат:

Список счетов, соответствующих правам доступа Consent. Если доступ к балансам разрешен — они также включены.

Тест-кейс №11 Получение деталей счета | GET /accounts/{account-id}

BODY:

null

Ожидаемый результат:

Возвращает детали счета и при наличии прав — баланс.

Тест-кейс №12 Получение транзакций счета | GET /accounts/{account-id}/transactions

BODY:

null

Ожидаемый результат:

Возвращает список транзакций, если разрешено Consent.

Тест-кейс №13 Получение деталей транзакции | GET /accounts/{account-id}/transactions/{transactionId}

BODY:

null

Ожидаемый результат:

Возвращает детальную информацию по транзакции.

 

Инициация платежа (Payment Initiation Service)

1. Тестовые сценарии Payment Initiation Service

Тест-кейс №1 Создание initiation платежей (consent) | POST /payments/instant-credit-transfers | POST /payments/credit-transfers

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

Требования к заголовкам и телу запроса описаны в документации соответствующей версии.

Предусловия:

Пользователь зарегистрирован в системе

Имеет действительный токен доступа (выполнен вход в систему)

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

Шаги выполнения:

Выбрать провайдера, для которого создается платеж, зафиксировать providerId

Выбрать тип {payment-product} — instant-credit-transfers или credit-transfers

Выполнить вызов 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" ] } 

Ожидаемый результат:

Создан платеж со статусом "transactionStatus": "RCVD"

В ответе присутствует "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

Шаги выполнения:

Выполнить вызов 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" // использовать значение для sandbox

PSU-ID-Type: "PHONE"

BODY:

 {} 

Ожидаемый результат:

Создана авторизация платежа

В ответе присутствуют "scaStatus" и "authorisationId"

Пример ответа:

 { "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".

Перейти по ссылке в _links/scaRedirect (если redirect) или инициировать SCA через другой канал (если decoupled)

На странице Sandbox доступен обработчик, где можно принять или отклонить запрос:

Подтвердить авторизацию нажатием "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

Шаги выполнения:

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

Ожидаемый результат:

Тело ответа содержит текущий статус платежа

 { "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

BODY:

null

 { "transactionStatus": "RCVD" } 

Тест-кейс №5 Получение авторизаций платежа | GET /payments/{payment-product}/{payment-id}/authorisations

BODY:

null

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

Тест-кейс №6 Получение деталей авторизации платежа | GET /payments/{payment-product}/{payment-id}/authorisations/{authorisation-id}

BODY:

null

 { "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" } } }