Водич за започнување Водич за започнување
Добре дојдовте во „Водичот за започнување“ на развојниот веб портал. Тој нуди суштински информации за да им помогне на давателите на услугата - плаќања од трети страни (TPP) да го започнат своето движење низ API услугите, вклучително и детали за процесот на регистрација на развојниот веб портал, API услугите, нивните функционалности и соодветните безбедносни мерки.
Регистрација
За да се добие пристап до развојниот веб портал, треба да се направат следните чекори:
- Да се регистрира и да пополни формулар за регистрација за да се креира корисничка сметка на развојниот веб портал. По регистрацијата ќе биде побарано да се пополнат информациите за вашиот профил и да се креира лозинка. Поседувањето на корисничка сметка овозможува креирање на апликации кои се неопходни за тестирање на интеграцијата со нашите API услуги.
- Да се прочитаат и прифатат Правилата и условите и Известувањето за приватност на податоците.
- Да се пополни и поднесе формуларот за регистрација. По поднесувањето на формуларот за регистрација, се добива e-mail со линк за активирање. Со кликнување на линкот за активирање, се комплетира процесот на регистрација, се активира вашата сметка и ве пренасочува на страницата „Најави се“. По регистрацијата, се добива пристап за тестирање на нашите API услуги во Sandbox околината, но пред да се започне со работа со нашите API услуги во продукциската околина, задолжително е да имате дозвола од Народна Банка на Република Македонија и eIDAS сертификати согласно ЗПУПС.
Најавување
Најавување на порталот на банката е дозволено по успешна регистрација и активирање на корисничката сметка. За најава, потребно е да се внесе корисничко име или e-mail адреса и лозинка. Најавувањето овозможува пристап до функционалностите на овластениот развоен веб портал: управување со апликации, управување со сертификати, кориснички поставки и Sandbox.
Околини
Ние нудиме две различни околини: продукциска и Sandbox (тестна) околина.
Продукциската околина е дизајнирана за API повици, обезбедувајќи целосно оперативна поставка за реални интеракции.
Од друга страна, Sandbox околината служи како околина наменета за тестирање, овозможувајќи да експериментирате, развивате и тестирате функционалности на API услугите.
Sandbox околината е изолирана од продукциската околина, така што операциите што се извршуваат во неа не влијаат на продукциската околина. Продукциската верзија на API услугите обезбедува пристап до вистинските податоци за корисниците, односно ќе може да се иницираат реални плаќања, да се пристапи до информациите за платежната сметка, да се потврди расположливост на средства со дозвола на корисникот на платежната услуга (PSU). Ова се URL-адресите за крајните точки за да пристап до околините.
Продукциска околина:
https://api.ob.kb.mk/xs2a/{version}/{service}Sandbox:
https://sandbox-api.ob.kb.mk/xs2a/{version}/{service}API каталог со производи
API каталогот со производи на развојниот веб поратал е сеопфатна колекција на API производи. Секој API производ во каталогот претставува збир на функционалности што им се достапни на давателите на услугата - плаќања од трети страни (TPP).
Развојниот веб портал нуди краток опис за секој производ и со следење на соодветните линкови, достапни во Каталогот на производи, може да се види поврзаната API спецификација за секој производ.
Во моментов ги нудиме следниве API производи:
- Услуга за информации за сметката. Оваа услуга му овозможува на TPP безбедно да пристапува до податоците за платежната сметката на корисникот на платежната услуга.
- Услуга за иницирање плаќање. Оваа услуга му дава овластување на TPP да иницира плаќања во име на корисникот на платежната услуга.
- Услуга за потврда на расположливост на парични средства. Оваа услуга му овозможува на TPP да ја верификува расположливоста на средствата.
API Референца
API референцата обезбедува концизен и структуриран опис на API крајните точки, заедно со примери на податоци за барање и одговор. Дополнително, вклучува корисни информации за кодовите за грешки и нивните значења, помагајќи при ефикасно интегрирање и интеракција со API производите. Нашиот развоен веб портал нуди API спецификација за сите наши наведени API производи.
API БЕЗБЕДНОСТ
Токени за пристап со податоци за идентификација на клиентот
API услугите се обезбедени со користење на OAuth 2.0 протоколот и користење на Client Credentials Grant видот на авторизациски процесен тек, кои обезбедуваат силен механизам за автентикација. За да се пристапи до API услугите, потребно е да се добие токен за пристап (Access Token). За да се добие овој токен за пристап, треба да се поднесе барање што ги вклучува сигурносните обележја за апликацијата т.н. client ID и client secret, кои се генерираат при креирањето на апликацијата.
Безбедност на транспортно ниво (Transport Layer Security – TLS)
Комуникацијата помеѓу TPP и нас е секогаш обезбедена со користење на TLS верзија 1.2 или понова. TLS е криптографски протокол што се користи за обезбедување комуникација преку мрежа. Обезбедува безбедна и шифрирана врска помеѓу давателите на услугата – плаќањa од трети страни (TPP) и нашите API производи.
Апликации
Апликациите имаат клучна улога во процесот на авторизација, давајќи му на TPP дозвола за пристап до нашите API производи. Тие се клучни за добивање токени за пристап OAuth 2.0, кои пак овозможуваат пристап до нашите API услуги.
За да се конфигурира апликација, потребно е да се пристапи до делот Апликации во рамките на развојниот веб поратал. Постои флексибилност за креирање на апликации и за Sandbox и за продукциската околина. По креирањето на апликацијата, потребно е да се наведе нејзиното име, да се даде опис, да се постави опсегот на API производите и да се назначи верзијата.
Опсегот на API производите го определува степенот на вашиот пристап до нив. Може да се креираат апликации само за API услугите, дозволени со соодветната TPP улога. Опсегот на API производите е дефиниран со низа фактори, вклучувајќи група на API, верзија на група, API услуга, верзија на API услуга, како и специфични операции и карактеристики.
Откако апликацијата е успешно креирана, таа генерира OAuth 2.0 client ID и client secret. Овие идентификатори се од суштинско значење за добивање на OAuth 2.0 токени, кои пак се користат за безбедно извршување на API повици и пристап до нашите API услуги.
Управување со апликации
Во делот на Апликации, давателот на услугата – плаќања од трети страни (TPP) може да ги направи следниве активности:
- Креирање на апликации - TPP има можност слободно да креира апликации според своите потреби. Кога се креира апликација, TPP треба да обезбеди детали за апликацијата, како што се името на апликацијата, опис и да постави опсег на API производи кои што ќе ги користи апликацијата. Апликацијата може да има неколку опсези на API производи. По креирањето на апликацијата, ќе се генерираат client ID и client secret.
- Уредување на апликации - TPP има можност да ажурира различни атрибути на апликацијата, вклучувајќи го името, описот и опсегот на API производите.
- Креирање на нови верзии - TPP има можност да креира нови верзии на постоечката апликација, овозможувајќи ажурирања и подобрувања без влијание на стабилноста на претходните верзии. Секоја верзија може да вклучува еден или неколку нови опсези на API производи.
- Бришење на апликација - TPP има можност на едноставен начин да ги брише апликациите кога ќе станат застарени или повеќе не се потребни.
Sandbox
Sandbox во рамките на развојниот веб поратл му обезбедува на TPP алатки и информации за целите на тестирање на API производите. Ги обезбедува истите API услуги како нашата продукциска околина, но со податоци за тестирање, дозволувајќи му на TPP слободно да експериментира со API услугите.
За да му помогне на TPP да обезбеди точни API повици, развојниот веб портал има API спецификација за секоја од нашите API услуги. Спецификациите на API услугите содржат детални описи на нашите API крајни точки и содржат различни сценарија за барања со практични примери на код.
Дополнително, со движењето до деловите за преглед на секоја API услуга, ќе се најдат детални сценарија на барања со примери, кои ќе овозможат подобро разбирање како функционираат нашите API услуги.
Со користење на спецификацијата и примерите достапни во документацијата, TPP може да ги тестира следните API услуги:
- API услуга за пристап до информации за сметка
- API услуга за иницирање плаќање
- API услуга за согласност за платежна сметка
- API услуга за потврдување на расположливост на средства
Податоците од Sandbox може ефикасно да се користат од следните TPP:
- Даватели на услуги за информации за сметка (AISP)
- Даватели на услуги за иницирање плаќање (PISP)
- Даватели на услуги за издавање платежен инструмент (PIIS)
За користење на Sandbox, сертификатите QWAC и QSeal не се потребни. Сертификатите се потребни за продукциската околина.
Достапни услуги
Sandbox ги обезбедува следниве услуги за TPP:
- Услуга за иницирање плаќање - Услугата за иницирање плаќање овозможува иницирање барање за плаќање.
- Услуга на информации за сметката - Услугата на информации за сметки (AIS) ги нуди следниве услуги: листа на платежни сметки, давање информации за состојба на сметките и извештаи за трансакции во однос на дадената согласност.
- Услуга за потврда на расположливост на парични средства - Услугата за потврда на расположливост на парични средства овозможува да се потврди дали има доволно достапни средства на сметката.
Sandbox тест податоци
Во Sandbox околината, во рамките на развојниот веб портал, се вклучени тестни податоци кои помагаат во тестирањето на API услугите и симулираат реални сценарија. На пример, креирање согласност за информациите за платежната сметка е преуслов за пристап до деталите на сметката. Без постоење на експлицитна согласност, TPP не е во состојба да пристапи до потребните информации за сметката.
Тестните податоци во Sandbox околината вклучуваат симулирани информации за платежните сметки за двајца корисници на платежни услуги (PSU). Овие податоци опфаќаат клучни детали како што се кориснички имиња, лозинки и информации за сметките, вклучувајќи ги броевите на платежните сметки, валутата на сметката и расположливити парични средства.
За време на симулацијата на засилената автентикација на корисниците (SCA), користењето на кориснички имиња и лозинки е од суштинско значење. Како дел од оваа симулација, корисникот е пренасочен кон наменски банкарски SCA екран. На овој екран, потребно е да се внесат корисничкото име и лозинката на корисникот на платежните услуги (PSU) и на овој начин ефикасно се симулира неговото корисничко искуство. Следните информации се достапни како Sandbox тестни податоци:
- Име на клиент: Весна Спасовска
- Корисничко име: kobs001
- Лозинка: kobs001
| Назив на сметка | Тип на сметка | Број на сметка | Состојба | Валута |
|---|---|---|---|---|
| Платежна сметка | BBAN | 300007117612880 | 2630.00 | MKD |
| Платежна сметка | BBAN | 300000004822294 | 4632.00 | MKD |
| Платежна сметка | IBAN | MK07300000004635084 | 1230468.16 | EUR |
| Платежна сметка | IBAN | MK07300000004635763 | 1230.47 | EUR |
- Име на клиент: Милан Николов
- Корисничко име: kobs002
- Лозинка: kobs002
| Назив на сметка | Тип на сметка | Број на сметка | Состојба | Валута |
|---|---|---|---|---|
| Платежна сметка | BBAN | 300000004843052 | 1030352.00 | MKD |
| Платежна сметка | BBAN | 300007116161566 | 3527.00 | MKD |
| Платежна сметка | IBAN | MK07300097116152977 | 5000.00 | EUR |
| Платежна сметка | IBAN | MK07300081000000580 | 10000.00 | EUR |
Забелешка: Сите API услуги се имплементирани со користење на RESTful архитектурен модел. За сите барања и одговори може да се користи само JSON формат.
Забелешка: Сите податоци поврзани со платежната сметка (т.е. имиња на корисници на платежни услуги, броеви на платежни сметки, состојби на платежни сметки, итн.) кои се користени во примерите се тестни, односно не станува збор за вистински податоци.
Ресетирање на Sandbox околината
Во секоја ситуација, давателите на услугата – плаќања од трети страни (TPP) секогаш може да ја вратат својата конфигурација на Sandbox околината во почетна состојба. За да се направи тоа, потребно е да се кликне на копчето „Reset Sandbox".
Достапност
Sandbox околината е достапна 24/7/365 за тестирање на банкарските услуги. Доколку се појават проблеми, можете да го контактирате го нашиот тим за поддршка.
Тестирање со користење на Postman алатката
Postman е одлична алатка за тестирање и интегрирање на API услуги (линк за преземање на Postman овде). За помош при користењето на алатката, може да се користи документацијата и упатствата за Postman.
eIDAS сертификати
За пристап до продукциската околина, потребно е давателите на услугата - плаќања од трети страни (TPP) да обезбедат eIDAS сертификати од овластениот давател на квалификувани услуги од доверба, потоа преку развојниот веб портал да го прикачат во делот за управување со сертификати и да го поврзат со една или повеќе апликации.
eIDAS сертификатите се неопходни за обезбедување на безбедна конекција со XS2A интерфејсот. Воедно, овие сертификати ги содржат и PSD2 улогите (PISP, AISP, PIISP), врз основа на кои платформата ограничува користење на задолжителните по ЗПУПС API производи од страна на клиентските апликации. На пример, доколку давателите на услугата - плаќања од трети страни (TPP) немаат соодветна “PISP” улога во сертификатот, нема да бидат во можност да ги користат API производите за иницирање на плаќање.
QWAC
Квалификуваниот сертификат за автентичност на интернет-страница (Qualified Web Authentication Certificate) се користи за востпоставување на безбедна TLS конекција помеѓу давателите на услугата - плаќања од трети страни (TPP) и платформата. Се наоѓа во транспортното ниво и се валидира од страна на веб прелистувачот. Овој сертификат содржи идентификатор на компанијата кој што се користи од страна на платформата за верификација на правниот статус на давателите на услугата - плаќања од трети страни (TPP) во регистарот на платежни инситуции.
QsealC
Квалификуваниот сертификат за електронски печат (Qualified Electronic Seal Certificate) се користи за потпишување на HTTP повиците до XS2A интерфејсот. Тој помага да се обезбеди неотповикливост на пораките кои што се разаменуваат со платформата. За правилно потпишување на повиците, потребно е давателите на услугата - плаќања од трети страни (TPP) да ја пресметаат hash вредноста на HTTP Body и да ја стават во полето “digest” во header на повикот. Потоа, потребно е да се формира енкодиран стринг со Base64 алгоритам од полињата “digest”, “x-request-id”, “psu-id” и “tpp-redirect-uri” во header на повикот, да се потпише стрингот со приватниот клуч на поврзаниот QsealC и да се постави во полето “signature” во header на повикот, заедно со поврзаните мета-податоци. Платформата врши верификација на “signature” полето со помош на QsealC сертификатот кој што се наоѓа во полето “tpp-signature-certificate” во header на повикот.
Тестни сертификати
Развојниот веб портал за секој давател на услугата - плаќања од трети страни (TPP) обезбедува тестни QWAC и QsealC сертификати за овозможување на посеопфатно тестирање на API производите во Sandbox околината. Тестните сертификати се еквивалентни по структура со продукциските eIDAS сертификати. Единствена разлика е тоа што тие се изгенерирани од страна на развојниот веб портал единствено за тестна употреба.
Тестниот QWAC сертификатот е неопходен за воспоставување на успешна конекција со API производите во Sandbox околината. Користењето на QSealC сертификатот е опционално.
За тестирање со алатката Postman, потребно е да се извршат следните чекори:
- Под менито Sandbox -> Тестни сертификати;
- Преземете ги тестните сертификати и приватните клучеви;
- Отворете ја алатката Postman;
- Пристапете до Settings -> Certificates -> Add Certificate;
- Прикачете ги датотеките за сертификатот и клучот и пополнете го полето Host со sandbox URL. Притиснете "Add"
Откако ќе ја завршите опишаната постапка ќе можете успешно да направите Postman повици.
Продукциска околина
Пристапот до продукциската околина е достапен само за сертифициран давател на услугата – плаќања од трети страни . Давателот на услугата – плаќања од трети страни мора да се погрижи да има дозвола од Народна Банка на Република Македонија (PISP, AISP, PIISP).
Пристапот до продукциската околина ќе биде одобрен автоматски откако ќе се постави важечки eIDAS сертификат на развојниот веб портал. Откако ќе го потврдиме вашиот идентитет на давател на услугата – плаќања од трети страни и законските дозволи согласно ЗПУПС, може да се креираат и користат апликации за продукциската околина.
eIDAS сертификат во продукциска околина
Откако ќе се додели дозволата од Народна Банка на Република Македонија, TPP мора да обезбеди сертификат eIDAS QWAC (задолжителен) и QSeal сертификат (опционален) од давателот на квалификувани доверливи услуги (Qualified Trust Service Provider - QTSP). Овој сертификат ќе се користи за интеграција во продукциската околина. По успешното интегрирање, TPP мора да го користи истиот сертификат во секој API повик. Сите поврзувања во продукциската околина насочени кон API услугите без валиден eIDAS сертификат ќе бидат одбиени.
Валидација и поништување валидација на eIDAS сертифик
Кога се користи сертификатот на корисникот, тој секогаш ќе биде валидиран од наша страна. Валидацијата содржи валидација на синџирот на доверба на сертификатот, вклучувајќи проверка на истекување и верификација дали сертификатот е поништен, како дополнување на реалната валидација на потписот. Ако некоја од валидациите е неуспешна, пристапот ќе биде одбиен. Сопственикот на сертификатот има обврска да го обнови сертификатот пред неговото истекување. Доколку сертификатот истече и се користи нов сертификат, тогаш мора да се започне процедура за издавање на нов сертификат.
Забелешка: Го задржуваме правото да го поништиме пристапот на TPP до која било од нашите крајни точки во случај на намерна злоупотреба. Мора да се придржувате до соодветната законска рамка (ЗПУПС).
Контактирајте нè
Доколку имате посебен деловен случај и сакате да започнете деловна соработка со нас, што не се базира на ЗПУПС API услуги, ве молиме контактирајте со нас преку e-mail порака. Во пораката ве молиме додајте опис на вашите деловни барања за финансиската услуга што ви е потребна.
Потребна дозвола
Информации за платежната сметка
| API | AISP дозвола | PISP дозвола | Банкарска дозвола | Дозвола за издавање инструмент за плаќање |
|---|---|---|---|---|
| Согласности за сметка | ДА | НЕ | ДА | НЕ |
| Трансакции на сметка | ДА | НЕ | ДА | НЕ |
| Состојба на сметка | ДА | НЕ | ДА | НЕ |
| Детали за сметка | ДА | НЕ | ДА | НЕ |
| Потврда на расположливост на средства | НЕ | НЕ | ДА | ДА |
Иницирање плаќање
| API | AISP дозвола | PISP дозвола | Банкарска дозвола | Дозвола за издавање инструмент за плаќање |
|---|---|---|---|---|
| Плаќање | НЕ | ДА | ДА | НЕ |
Постапки на засилена автентикација на корисникот
Пренасочување на постапката за автентикација (Redirect)
Кај пристапот на пренасочување на SCA, кога PSU иницира трансакција или пристап до својата сметка преку TPP, тој се пренасочува на веб-страницата или интерфејсот на банката на корисникот (ASPSP). TPP ја повикува API крајната точка за авторизација за да го иницира овој тек, од која PSU е упатен да се автентицира преку нашата SCA страница и да даде согласност за постапката.
Вградување на постапката за автентикација (Embedded)
Текот на вградената SCA е процес на извршување на засилената автентикација на клиенти (SCA) во рамките на корисничкиот интерфејс на апликацијата на TPP, наместо да се пренасочи на страницата за автентикација на банката.
Во овој случај, откако TPP ќе направи првично барање до нас, ние ќе одговориме со проверка за автентикацијата на PSU, која што се прикажува директно на интерфејсот на TPP. Потоа, PSU може да се автентицира и да даде своја согласност директно преку интерфејсот на TPP.
Одвојување на постапката за автентикација (Decoupled)
Во текот на одвоената SCA, процесот на автентикација се одвива одвоено од самата трансакција. Во овој тек, PSU ја врши автентикацијата кај нас одделно од корисничкиот интерфејс на TPP, користејќи посебен уред или канал, како што е апликацијата за мобилно банкарство.
Текот започнува така што TPP испраќа барање до нас за иницирање на трансакција, а ние одговараме со URL-адреса за авторизација. Потоа, TPP го пренасочува корисникот до URL адресата за автентикација, каде што PSU се автентицира себеси користејќи го претпочитаниот метод, како лозинка или биометриска идентификација. Откако PSU успешно ќе се автентицира, PSU може да продолжи со давање на согласност, по што се враќа резултат на TPP преку повратна URL. TPP потоа може да продолжи со трансакцијата.
ЗА API услугите
API услуги
Наша цел е да обезбедиме искуства кои ги надминуваат очекувањата. Нашите отворени API услуги се изградени околу архитектурата на Representational State Transfer Service (REST), стандарден HTTP и лесен за читање и пишување JavaScript Object Notation (JSON). Ги следиме API спецификациите на Берлинската група (Berlin Group) и Водичот за имплементација (Implementation Guidelines), а исто така, ја проширивме поврзаната документација за да ги исполниме регулаторните барања.
API HTTP методи
До сите услуги се пристапува преку API со користење на REST базирани HTTPS методи:
- GET (Читање): Чита ресурс и го враќа;
- POST (Креирање): Креира нов ресурс;
- PUT (Модифицирање): Барањата кои ентитетот ги обезбедува се меморирани во обезбедената URL;
- DELETE (Бришење): Се брише ресурсот идентификуван со URL.
API статус на расположливост
Статусот на расположливост на API услугите се користи за информирање на програмерите на TPP за животниот циклус на API услугите. Статусот на расположливост е дефиниран за API операции, параметри, модели и карактеристики.
| Статус | Опис |
|---|---|
| Beta | Овој статус се користи за API услуга којашто е имплементирана, но сè уште е предмет на промена. Оваа API услуга може да ја користат програмерите во Sandbox и на продукција, но банката не е обврзана да гарантира дека нема да се воведат значителни промени на оваа API услуга во иднина. Функционалностите на API услугата во Beta статусот, исто така, може целосно да се отстранат во следните верзии. Промените на API услугата во Beta најпрво се појавуваат на Sandbox околината, а подоцна и на продукциската околина. На овој начин, програмерите на TPP ќе имаат време да се прилагодат на претстојните промени на API услугата на продукција. |
| Draft | Статусот Draft се користи за API услугите кои сè уште се во фаза на дизајнирање. |
| Production | Статусот на API со статус Production се во употреба на продукциска околина и треба да се користат во продукциските апликации. Нема да се прават значителни промени на стабилните API функционалности. |
| Sandbox only | API со статус Sandbox Only се достапни само во Sandbox околината и нема да бидат достапни на продукциска околина. |
| Deprecated | API со статус Deprecated ќе бидат отстранети во иднина. Застарените API услуги ќе продолжат да бидат поддржани од развојниот веб портал „Комерцијална Банка“ шест месеци. |
API во OpenAPI формат
API спецификацијата на банката е достапна во OpenAPI формат. Повеќе информации за тоа може да најдете овде
API животен циклус
Бројот на верзијата на API услугите е секогаш е вклучен во API повикот
URL: https://api.ob.kb.mk/{sandbox|live}/xs2a/{version}/{service}
Бројот на верзијата на API услугата во URL ја означува главната верзија на API услугата. Може да има мали ажурирања на API функционалностите што не го менуваат бројот на главната верзија. Бројот на главната верзија се менува само кога се имплементираат голем број промени, кои може значително да влијаат на API повратната компатибилност. Новите главни верзии на спецификацијата ќе зависат од изданијата на спецификациите на Берлинската група и барањата на Народната Банка на Република Македонија, а таквите промени ќе се издадат 3 месеци пред датумот на објавување.
Постарите верзии на API ќе бидат со статус Deprecated, но ќе останат достапни до шест месеци по имплементацијата на објавувањето, а ќе се отстранат по овој период.
Бројот на главната верзија на API ќе се зголемува со секое ново големо API издание, на пр. следната верзија на API услугата обично ќе има URL во следниов формат:
HTTP Статусни кодови
HTTP статусниот код ја соопштува успешноста или неуспешноста на пораката за барање на TPP. 4XX HTTP статусните кодови се даваат само ако тековното барање не може да се исполни, на пример, доколку не може да се иницира плаќање или доколку трансакциите на сметката не може да се преземат. Доколку барањето го добие статусниот код HTTP 200, тоа значи дека пристапот до банката е успешен, но не и дека станува збор за успешно извршено плаќање или дадена согласност.
| Код | Опис |
|---|---|
| 200 OK | This return code is permitted if a request was repeated due to a time-out. The response in that might be either a 200 or 201 code. The POST for a Funds request will also return 200 since it does not create a new resource. DELETE Response Code where a payment resource has been cancelled successfully and no further cancellation authorisation is required. |
| 201 Created | POST response code where Payment Initiation or Consent Request was correctly performed. |
| 202 Accepted | DELETE response code, where a payment resource can be cancelled in general, but a cancellation authorisation is needed in addition. |
| 204 No Content | DELETE response code where a consent resource was successfully deleted. The code indicates that the request was performed, but no content was returned. |
| 400 Bad Request | Validation error occurred. This code will cover malformed syntax in request or incorrect data in payload. |
| 401 Unauthorized | The TPP or the PSU is not correctly authorized to perform the request. Retry the request with correct authentication information. |
| 403 Forbidden | Returned if the resource that was referenced in the path exists but cannot be accessed by the TPP or the PSU. |
| 404 Not found | Returned if the resource or endpoint that was referenced in the path does not exist or cannot be referenced by the TPP or the PSU. |
| 405 Method Not Allowed | This code is only sent when the HTTP method (PUT, POST, DELETE, GET etc.) is not supported on a specific endpoint. It has nothing to do with the consent, payment or account information data model. |
| 406 Not Acceptable | The ASPSP cannot generate the content that the TPP specified in the Accept header. |
| 408 Request Timeout | The server is still working correctly, but an individual request has timed out. |
| 415 Unsupported Media Type | The TPP has supplied a media type which the ASPSP does not support. |
| 429 Too Many Requests | The TPP has exceeded the number of requests allowed by the consent or by the RTS. |
| 500 Internal Server Error | Internal server error occurred. |
| 503 Service Unavailable | The ASPSP server is currently unavailable. Generally, this is a temporary state. |