Короткий опис функціоналу спеціалізованого інтерфейсу

PIS — сервіс ініціювання платежів

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

1. Ініціювання платежу: TPP надсилає запит на ініціювання платежу за допомогою методу POST /pis/v2/payments/{payment-product}. У запиті передаються дані про рахунок платника (IBAN), суму та валюту переказу, дані отримувача (ім'я, ідентифікатор, IBAN рахунку) та реквізити призначення платежу. Платформа повертає унікальний ідентифікатор транзакції (paymentId) та початковий статус платежу (RCVD — отримано) .
2. Запуск авторизації: Після ініціювання платежу 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).
3. Перевірка статусу: TPP може перевірити поточний статус платежу за допомогою методу GET /pis/v2/payments/{payment-product}/{payment-id}/status. Платформа повертає актуальний статус транзакції ($.transactionStatus), наприклад, ACCC (успішно завершено). Підтримувані продукти платежу: instant-credit-transfers.

AIS — сервіс надання інформації про рахунок

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

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

1. Створення згоди на доступ до рахунку. TPP надсилає запит на створення згоди методом POST /ais/v2/consents/account-access. У запиті передаються: IBAN рахунку, права доступу ("accountDetails", "balances", "transactions"), тип згоди, ознака повторюваного доступу (recurringIndicator), строк дії (validTo) та максимальна частота запитів на день (frequencyPerDay, максимум 4 рази на добу). Платформа повертає унікальний ідентифікатор згоди (consentId).
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".
3. Отримання переліку рахунків.TPP отримує перелік рахунків PSU методом GET /ais/v2/accounts?withBalance=true, передаючи заголовок Consent-ID з ідентифікатором підтвердженої згоди. Платформа повертає список рахунків із IBAN, валютою, ідентифікатором ресурсу, назвою рахунку та поточними балансами.
4. Отримання історії операцій.TPP отримує історію операцій за рахунком методом GET /ais/v2/accounts/{account-id}/transactions. Банк надає історію операцій за останні 31 день, враховуючи дату запиту. У разі, якщо банк надає історію операцій за період від 31 до 90 днів, запит може оброблюватись без додаткової SCA-авторизації. Для отримання операцій давніше 90 днів необхідна одноразова AIS-згода (recurringIndicator: false). Підтримується посторінкова вибірка (пагінація) за параметрами limit та offset.

Опис технічних характеристик спеціалізованих інтерфейсів

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

• Архітектура: REST API, специфікація XS2A.
• Транспортний протокол: HTTPS; незахищений HTTP не допускається.
• Формат запитів і відповідей: JSON.
• Поточна версія інтерфейсів: v2.
• Взаємна TLS-автентифікація (mTLS) та електронні підписи запитів.

Основні заголовки HTTP

X-Request-Id, Content-Type, PSU-ID, PSU-IP-Address, Consent-ID, Client-Redirect-URI, Client-Redirect-Nok-URI.

PIS

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

• Ініціювання платежу.
• Запуск SCA-авторизації.
• Перевірка статусу платежу.
• Коди помилок: PRODUCT_UNKNOWN, PAYMENT_FAILED, SERVICE_BLOCKED.

AIS

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

• Створення та авторизація AIS-згоди.
• Перевірка статусу згоди.
• Отримання рахунків, балансів та історії транзакцій.
• Максимальна частота запитів без присутності PSU — 4 рази на добу.

Детальний опис технічних характеристик спеціалізованих інтерфейсів: docs.api.upc.ua/ua/api-servisi/regulyatorni-api.

Опис програми тестування

Для розробників та авторизованих сторонніх надавачів платіжних послуг доступне тестове середовище Sandbox.