API Documentation

What services does CIB PSD2 API offer?

The CIB PSD2 API service provides an opportunity for your business to provide account information and payment initiation services to customers of our bank who have a payment account.In integrating the PSD2 API our bank follows the Berlin Group guideline version 1.3. Please review the CIB PSD2 API documentation and test your development using the Sandbox.Once the statutory conditions have been fulfilled and in possession of the required certificates, you can use our service starting from 14 September 2019.

Things to know about using CIB PSD2 API

From when can the system be used live?

According to the requirements of the PSD2 Directive, CIB PSD2 API Sandbox can be used live starting from 14 September 2019.

On what address can CIB PSD2 API Sandbox be accessed?

https://api.cib.hu

How can we learn of API changes?

The bank publishes the documentation of changes occurring in the technical information required for using the CIB PSD2 API Sandbox by version updates on its website (www.cib.hu).

What international standard does the bank follow in integrating the PSD2 API?

In integrating the PSD2 API our bank follows the Berlin Group guideline version 1.3 (https://www.berlin-group.org), with some differences. The summary of differences is included in the Related documents part.

What do the AISP, ASPSP, PISP, PSU, SCA, TPP abbreviations mean?

• AISP: Account Information Service Provider (TPP)
• ASPS: Account Servicing Payment Service Provider
• PISP: Payment Initiation Service Provider (TPP)
• PSU: Payment Service User
• SCA: Strong Customer Authentication
• TPP: Third-party PSD2 service provider.

Differences compared to the Berlin Group guideline

1. General information

The purpose of the documentation is to support interface integration testing in the following cases:
To service providers providing account information and payment initiation services to customers who have accounts at CIB Bank.
For the confirmation request activity of payment service providers that issue card-based cashless payment instruments.

CIB Bank applied version 1.3 of the guideline proposed by the Berlin Group in developing the interface, therefore we recommend studying it prior to starting the testing.

Below we present the differences compared to the Berlin Group guidelines.

2. Abbreviations and terms 

Abbreviation	Description
TPP:	A service provider other than the bank (so-called Third-Party Payment Service Provider) that provides account information or payment initiation services
AISP:	Account Information Service Provider
PISP:	Payment Initiation Service Provider
PIISP:	Payment Instrument Issuing Service Provider
PSU:	Payment Service User
SCA:	Strong Customer Authentication

 

3. Differences compared to the Berlin Group guideline version 1.3

Detailed field-level documentation for services implemented by CIB Bank is included in the interface definition (YAML) file.

At the time of submitting a consent and a payment, PSU-ID or PSU-Corporate-ID header (only one of them) must be fulfilled to make retail / corporate routing. It can be fulfilled with any kind of value, specific value does not matter

• CIB PSD2 API does not support the following requests:
• POST consents/{consentId}/authorisations
• PUT consents/{consentId}/authorisations/{authorisationId}
• GET card-accounts
• GET card-accounts/{account-id}
• GET card-accounts/{account-id}/balances
• GET card-accounts/{account-id}/transactions
• POST signing-baskets
• POST signing-baskets/{basketId}/authorisations
• PUT signing-baskets/{basketId}/authorisations/{authorisationId}
• GET signing-baskets/{basketId}/authorisations/{authorisationId}
• POST bulk-payments/{payment-product}
• GET bulk-payments/{payment-product}/{paymentId}
• GET bulk-payments/{payment-product}/{paymentId}/status
• POST {payment-service}/{payment-product}/{paymentId}/authorisations
• PUT {payment-service}/{payment-product}/{paymentId}/authorisations/{authorisationId}
• DELETE {payment-service}/{payment-product}/{paymentId}
• POST {payment-service}/{payment-product}/{paymentId}/cancellation-authorisations
• GET {payment-service}{payment-product}/{paymentId}/cancellation-authorisations
• PUT {payment-service}/{payment-product}/{paymentId}/cancellation-authorisations/{cancellationId}
• GET {payment-service}/{payment-product}/{paymentId}/cancelation-authorisations/{cancellationId}

OAuth process

• OAuth2 protocol (method) can be used for customer authorization
• OAuth server automatically registers the TPP when it submits its first consent or payment, as long as TPP is properly certified
• As a result of failed OAuth authorization the requester can not access the resource. In this case TPP callback URL is called given in the authorization request, supplemented with error code (?error? parameter), error description (?error_description parameter). Error code value will be ?access denied?.
  

The PSU can cancel (delete) payment initiations submitted via the TPPs only through other electronic channels provided by our bank.
On the following interface, use of the ?both? value in the bookingStatus parameter is not supported:

• GET accounts/{account-id}/transactions
• GET card-accounts/{account-id}/transactions

Only one transaction by bookingStatus can be queried at a time. bookingStatus parameters that can be used:

• pending: queries the items pending
• booked: items fulfilled

In the case of payment initiation requests, our Bank supports different payment order types (payment products), which are:

• fx-credit-transfers ? one-time foreign currency transfers, non SEPA (intrabank, interbank)
• hungarian-credit-transfers ? one-time and recurring forint transfers (intrabank, interbank)
• sepa-credit-transfers ? EUR one-time foreign currency transfer (intrabank, interbank)

Payment order types (payment products) and services can be interpreted in the following combinations:

payment product	payments	bulk-payments	periodic-payments
fx-credit-transfers	supported	not supported	not supported
hungarian-credit-transfers	supported	not supported	supported
sepa-credit-transfers	supported	not supported	not supported