Support

AISP (Account Information Service Provider) 

Any financial provider who has access to customers’ bank accounts and is authorised to fetch payment account information and transactions but cannot initiate payments. Sometimes they are aggregating data to analyse the spending behaviour so to provide a complete overview  of their user financial situation. The account details can only be accessed with appropriate permission from the account holder. This service is sometimes also offered by primary banks.

API (Application Programming  Interface) 

A set of commands, functions, protocols, and tools acting as a software intermediary that allow two software programs to communicate with each other and exchange data.

ASPSP (Account Servicing Payment Service Providers) 

Entities having full and direct control of customers’ bank accounts, having a direct service contract with the bank account owner. 

CISP (Card Issuer Service Provider) 

Card-based payment service providers that can make a request to the users’ bank to verify funds availability before payment. 

EBA (European Banking Authority) 

The EBA is an independent European Union Authority that works to ensure effective and consistent prudential regulation and supervision across the European banking sector.

eIDAS (Electronic Identification, Authentication and Trust Services) 

A set of EU regulatory standards  designed for transactions and money transfers. It ensures that up-to-date, internationally admissible standards of digital identity, trust verification and validation are in place.​ 

PISP (Payment Initiation Service Provider) 

Any organization that, upon customers’ request and on their behalf, can initiate credit transfers to accounts held at another payment service provider. PISPs act as an intermediary between customers starting the payment and their own online bank account. 

PSD2 (Payment Services Directive 2) 

EU Directive 2015/2366 on payment services that entered into force on 13 January 2018. It represents an evolution of Directive 2007/64/CE, also known as PSD, and a step further towards complete harmonisation of the EU payments market. 

PSU (Payment Service User)

Any natural or legal person making use of a payment service in the capacity of payer, payee, or both. In other words, any user that has access to a payment account through the customer interface.

RTS (Regulatory Technical Standards) 

Technical  standards  defining PSD2 and eIDAS services. They provide detailed specifications to achieve the strict security  requirements  for payment service providers in the EU,  such as data security, legal accountability, and other processes.

SCA (Strong Customer Authentication) 

Strong Customer Authentication, also known as Two Factor Authentication (2FA),  as defined by EBA Regulatory Technical Standards, is an authentication based on the use of two or more elements categorized as knowledge (something only the user knows [for example, a password]), possession (something only the user possesses [for example, a particular cell phone and number]) and inherence (something the user is [or has, for example, a fingerprint or iris pattern]) that are independent, [so] the breach of one does not compromise the others and is designed in such a way as to protect the confidentiality of the authentication data and/or to ascertain the identity of a payment service user or the validity of the use of a specific payment tool.

TPP (Third-Party Provider) 

A service provider which is different from the one customers own their account or payment service at, that after customer approval, is authorized to access their bank account information. Thanks to TPPs, online account owners can process payments or access to their own reserved information through non-banking authorized services. TPP is the collective name for AISPs, CISPs and PISPs. 

XS2A (Access-to-Account) 

Authorized access to customers’ account: a service enabling an app which is not controlled by the bank to obtain information on users’ accounts. 

QSEAL (Qualified Certificate for Electronic Seals)

The QSEAL is used for identity verification at the application layer to protect transactional information from potential attacks. This means that the person receiving digitally signed data can be certain about who signed the data and that it has not been changed. QSEAL certificates are used to sign API/HTTP requests.

QTSP (Qualified Trust Service Provider) 

An entity that's qualified to provide trusted digital certificates under the eIDAS regulation.

QWAC (Qualified Website Authentication Certificate)

QWAC provides identification at the transport layer. QWAC is similar to SSL/TLS. It is used for website authentication so that ASPSPs and TPPs can be certain of each other’s identity.

You can use our developer portal to browse the different API products and plans that are available and select the ones that best suit your requirements.

A product is a bundle of specific APIs and plans to which you can subscribe in order to use the APIs.

Each plan sets limitations and subscription details on how you can use our API Products. Some plans are free and no approval is required, several plans require approval, and some may ultimately require approval and a monthly subscription. Consider your needs and choose the most suitable plan.

To do so, when logged in, you can visit the “API Products” page, either from the MENU or directly from the Products shown in the Homepage. There, you can select a product, see its description, along with the APIs it contains and the available plans. Select the plan that best suits your needs, click subscribe and select the application for which you want to subscribe. Repeat the process for each product you are interested in. You can select as many products as your application may utilize.

When logged in, follow these steps:
1.    Go to the Apps page and click on the “+ Create new App” link.
2.    In the respective form, fill in the title, a description and a redirect URI for the OAuth flow and click "Submit".
3.    In the next page, save the Client ID and Client Secret. The Client ID can be seen at any given time. On the contrary the Client Secret is only visible upon registration, so make sure you keep it stored. Otherwise, you will have to reset it and take note of the new value. At this point, the application is registered and you can browse and subscribe to the available APIs through specific product plans.

The numbers of requests, for different APIs, that your application has made apear on your application page.
Click 'Apps' in the main menu and then click on your application. Under 'Subscribed Plans' you will see all plans your application is subscribed to.
For each API contained in that plan you can see the usage compared to the rate limit of the plan.
 

When logged in, click on the user menu and select “My organisation”. In this page you can:
•    Edit your organisation (change its name)
•    Add new users
•    Remove existing users
•    Get Analytics for your applications

When logged in, click on the user menu and select “Create an Organisation ”. You can have multiple organisations managed by a single account.

When logged in, click on the user menu (by clicking on your email address at the upper right corner of the Portal Header) and select the first item on the menu (again your email address). In this page you can view and edit your information (first name, last name, company name, phone number, email address, password, preferred code snippet language etc).

Your application Client Secret is stored encrypted, so we cannot retrieve the unencrypted version to tell you the value if you forget it.
You can reset it, which will update the stored value and return the new value to you.
To do that, click 'Apps' in the main menu and then click on the application in question. Under the “Subspriptions” tab, click on the three dots on the right and then you can click the 'Reset client secret' link.
Your new Secret will be displayed at the top of the page.

Your credentials are stored encrypted, so we cannot retrieve the unencrypted version to tell you the value if you forget it.
You can reset it, which will update the stored values and return the new values to you.
To do that click, 'Apps' in the main menu and then click on the application you wish. Under the “Subspriptions” tab, click on the three dots on the right and then you can click the 'Reset Credentials” link.
Your new credentials will be displayed at the top of the page.

The sandbox provides users with the opportunity to simulate in a secure environment the flows currently available in production. Users can simulate strong customer authentication and creation of consent, as well as view account information and transactions, confirm funds and perform payments.

Key characteristics of sandbox environment are as follows:

• Authorization flows are identical to production functionality
• TPPs can issue tokens for a specific test user
• SCA redirect links lead to Eurobank pages
• Users view a confirmation page with mocked data corresponding to a specific test user
• An extra page for product selection is displayed for bank-offered AI consents
• Upon user confirmation, an OTP modal is displayed and to resume the flow, a mocked OTP specific for that user must be entered
• User is redirected to TPP-Redirect-URI

Three retail users are available to log-in to sandbox.

Please find user information below:

In sandbox environment, the OTP is dummy depending on the selected user.

Please find user information below:

The first step for any API call is for the TPP to obtain a valid access token with the PSU involvement. In order to obtain a new access token for sandbox environment you should use this url:

https://apigw.eurobank.gr/eurobank/apis/auth-demo/oauth2/authorize?response_type=code&client_id={client_id}&redirect_uri={redirect_uri}&scope=accounts

client_id, Your client ID

redirect_uri, The callback uri which will be redirected after successful login.

scope, The scope the token will be used for [accounts, payments, funds-confirmation]

After successful login using your ebanking credentials and assuming the redirect_uri is https://www.google.gr, you will be redirected to url:

https://www.google.gr/?code=AAJbzctb-RYlcnTy384NYSJluoB3Pq6nfB4Tf9XDnwjNXgHDF9h86_WAiY6ht29lNp_wa7NEzUNTwdwsBRqX2Lk5B54URNpYM3wSy8e1q_GcDAe8vSg0rWHhJlcfgWyWQja_Eandw4Fahnq0fsduno8UXhkPXndTPPzxMchgQyqVcA

The query parameter of the previous url is the <authorization_code> that will be used to generate an access token via the following POST:

curl -X POST https://apigw.eurobank.gr/eurobank/apis/auth-demo/oauth2/token -H 'Content-Type: application/x-www-form-urlencoded' -d 'grant_type=authorization_code&client_id={client_id}&code={authorization_code}'

The response of that call will contain the access and refresh token. The access token is valid for 30 min while the refresh token is valid for 90 days. After the 30min window elapses, you can use the refresh token to obtain a new valid access token via the call:

curl -X POST 'https://apigw.eurobank.gr/eurobank/apis/auth-demo/oauth2/token' -H 'Content-Type: application/x-www-form-urlencoded' -d 'grant_type=refresh_token&client_id={client_id}

The access token is passed in every API call via the header Authorization: Bearer <access_token>

With the acquired accessToken, you will be able to initialize the consent for accounts flow. To create a bank offered consent, you need to invoke the following:

curl -X POST https://apigw.eurobank.gr/eurobank/apis/sandbox/v1/consents 

  -H 'Accept: application/json' \

  -H 'Content-Type: application/json' 

  -H 'TPP-Redirect-URI: {redirect_uri}' \

  -H 'X-IBM-Client-Id: {client_id}' \

  -H 'Authorization: Bearer {access_token}'

  -H 'X-Request-ID: e6ef4cc6-3375-11e9-b210-d663bd873d93' \

  -d '{

  "access": {},

  "combinedServiceIndicator": false,

  "frequencyPerDay": 4,

  "recurringIndicator": true,

  "validUntil": "2020-12-30"

}'

The response of that call will contain the consentId and a SCA Url where the user must be redirected to in order to Authorize the consent request.

Please see the consent response below:

{
    "consentStatus": "received",
    "consentId": "1AZZmZRK8WTFfysrPe8s",
    "_links": {
        "scaRedirect": {
            "href": "https://auth-demo.eurobank.gr/auth/consent/1AZZmZRK8WTFfysrPe8s?api_key=14g7EZn6WQKmeCuQYmuf"
        },
        "self": {
            "href": "/v1/consents/1AZZmZRK8WTFfysrPe8s"
        },
        "status": {
            "href": "/v1/consents/1AZZmZRK8WTFfysrPe8s/status"
        },
        "scaStatus": {
            "href": "/v1/consents/1AZZmZRK8WTFfysrPe8s/authorisations"
        }
    }
}

The SCA url provided above is a Eurobank endpoint where the user will view –following further authentication—his accounts/cards in order to provide his final consent. During this step, second factor authentication will also be required. After the successful completion of the SCA flow, the user will be redirected to the TPP-Redirect-URI.

With the acquired accessToken, you will be able to initiate payments. Note that the Debtor Account utilized is dummy and the provision of consent is not required for Payments in sandbox environment.  Please find an example below:

Payment initiation request

curl --location --request POST

'https://apigw.eurobank.gr/eurobank/apis/sandbox/v1/payments/sepa-credit-transfers' \

--header 'Accept: application/json' \

--header 'Content-Type: application/json' \

--header 'X-Request-ID: e6ef4cc6-3375-11e9-b210-d663bd873d93' \

--header 'PSU-IP-Address: {clientIP}' \

--header 'X-IBM-Client-Id: {clientId}' \

--header 'TPP-Redirect-URI: {redirectUri}' \

--data-raw '{

  "creditorAccount": {

    "currency": "EUR",

    "iban": "GR123456789101****314151617"

  },

  "creditorAddress": {

    "buildingNumber": "string",

    "city": "string",

    "country": "GR",

    "postalCode": "string",

    "street": "string"

  },

  "creditorName": "Creditor Name",

  "debtorAccount": {

    "currency": "EUR",

    "iban": "GR78910111213****1617181920"

  },

  "endToEndIdentification": "text",

  "instructedAmount": {

    "amount": "1",

    "currency": "EUR"

  },

  "remittanceInformationUnstructured": "textInfo"

}'

The payment initiation response indicates the payment status and whether SCA is needed. SCA exemption for psd2 follows the same rules as e-banking (e.g. transfer to own account, transfer to trusted beneficiary). Please find below two response examples with and without SCA, the main difference is transactionStatus and the absence of startAuthorisation element:

Payment initiation response with SCA

{

    "transactionStatus": "RCVD",

    "paymentId": "13F6RS9DS1jWA9joHNqD",

    "transactionFees": {

        "currency": "EUR",

        "amount": "0"

    },

    "transactionFeeIndicator": false,

    "_links": {

        "self": {

            "href": "/v1/payments/sepa-credit-transfers/13F6RS9DS1jWA9joHNqD"

        },

        "status": {

            "href": "/v1/payments/sepa-credit-transfers/13F6RS9DS1jWA9joHNqD/status"

        },

        "scaStatus": {

            "href": "/v1/payments/sepa-credit-transfers/13F6RS9DS1jWA9joHNqD/authorisations/4FH5yvPdRRHpYZ2891aPaYaUMTRWdrscVSEJx3p9erey"

        },

        "scaRedirect": {

            "href": "https://auth-demo.eurobank.gr/auth/payments/sepa-credit-transfers/13F6RS9DS1jWA9joHNqD?api_key=14hforvgjuKeLw98k9E7"

        }

    }

}}

Payment initiation response without SCA

{

    "transactionStatus": "ACSC",

    "paymentId": "16ksdXsgxa3KPAnL2XPM",

    "transactionFees": {

        "currency": "EUR",

        "amount": "0"

    },

    "transactionFeeIndicator": false,

    "_links": {

        "self": {

            "href": "v1/payments/sepa-credit-transfers/16ksdXsgxa3KPAnL2XPM"

        },

        "status": {

            "href": "v1/payments/sepa-credit-transfers/16ksdXsgxa3KPAnL2XPM/status"

        },

        "scaStatus": {

            "href": "v1/payments/sepa-credit-transfers/16ksdXsgxa3KPAnL2XPM/authorisations/9QMtchGv3yfvaoN3z5i4d5njBS8fHKUFo8Gc1NJmu8y7"

        }

    }

}

In order to perform payment cancellation, you should first execute a successful payment following the steps mentioned earlier.

Please note that it is only possible to delete the following payment: “Transfer funds to my Eurobank Account” / “Πληρωμή Ιδίου”.

Payment Cancellation Request

curl --location –request

DELETE ‘https://apigw.eurobank.gr/eurobank/apis/sandbox/v1/payments/sepa-credit-transfers/15owGKCMmce3PZaK1jLB' \

--header 'Accept: application/json' \

--header 'Content-Type: application/json' \

--header 'X-Request-ID: e6ef4cc6-3375-11e9-b210-d663bd873d93' \

--header 'PSU-IP-Address: 91.195.152.24' \

--header 'X-IBM-Client-Id: 07b1a0323e2c391698c4cff6388b82a9' \

--header 'Authorization: Basic dXNlck5hbWVDOjE2MlprRkExYUQ0bjE0QnV4M1Bv' \

--header 'consent-id: 1AZZmZRK8WTFfysrPe8s' \

--header 'X-PSP-Role: PSP_PI' \

Payment Cancellation Response

{

    "transactionStatus": "ACTC",

    "_links": {

        "self": {

            "href": "/v1/payments/sepa-credit-transfers/15owGKCMmce3PZaK1jLB"

        },

        "status": {

            "href": "/v1/payments/sepa-credit-transfers/15owGKCMmce3PZaK1jLB/status"

        },

        "scaStatus": {

            "href": "/v1/payments/sepa-credit-transfers/15owGKCMmce3PZaK1jLB/cancellation-authorisations/4Zz5kWMKqzLzfWCitego7tFMSgi9Cv67271R6T6anA6P"

        },

        "scaRedirect": {

            "href": " https://auth-demo.eurobank.gr/auth/payments/sepa-credit-transfers/15owGKCMmce3PZaK1jLB/cancellation/1CdzJipCQkMpNUi2Y18Y?api_key=18bRSxACJYZHc3cPMybh"

        }

    }

}

In order for Eurobank to ensure that AISPs, PISPs and CBPIIs are able to identify themselves towards Eurobank, AISPs, PISPs, CBPIIs apply secure encryption throughout each communication session in order to safeguard the confidentiality and the integrity of the data.
The data provided are originated by the PSP identified in the certificate. Eurobank follows the EBA recommendation to use both QWACs and QSealCs in parallel. 

Eurobank supports all 3 alternatives below:

1. Use of QWACs only – this allows AISPs, PISPs and CBPIIs to communicate securely with and identify themselves towards Eurobank, but cannot provide evidence that the data submitted originates from the PSP identified in the certificate.

2. Use of QSealCs only - this allows AISPs, PISPs and CBPIIs to identify themselves towards Eurobank, but cannot ensure confidentiality during the communication session. 

3. Parallel use of QWACs and QSealCs – this allows  AISPs, PISPs and CBPIIs to identify themselves towards Eurobank and, at the same time, ensures that the communication is secure and that the data submitted originates from the PSP identified in the certificate.

Eurobank fulfills the special requirements laid down in Articles 32 and 33 of the Regulation (EU) No 389/2018 in relation to the dedicated interface allowing internet access to its payment accounts. Eurobank, has been exempted, pursuant to Article 33§6 of the above Regulation, by the Bank of Greece, by virtue of decision No 324/9/05.09.2019 of the Bank’s Committee for Credit and Insurance Matters, from applying contingency measures in the event that the above dedicated interface malfunctions or is unavailable.

Most of the times, the reason for this is that the required request headers are not properly set.
Please check the "Signature" header and especially the following elements:
•       headers: Our implementation expects the headers "digest" and "x-request-id" to be present
•       algorithm: Its value should be either "rsa-sha256" or "rsa-sha512". A different value will result in validation error.
•       there is no space between the keys and the values in the signature header
The following header is valid:
keyId="1.3.6.1.4.1.21528.2.2.99.11534",algorithm="rsa-sha256",headers="digest x-request-id",signature="ewqC5PWVqpNCW68mHW…”
 
The one below is invalid:
keyId = "1.3.6.1.4.1.21528.2.2.99.11534",algorithm = "rsa-sha256",headers = "digest x-request-id",signature = "ewqC5PWVqpNCW68mHW…”
 
Please also check that header “TPP-Signature-Certificate” has the following format:
-----BEGIN CERTIFICATE-----
MIIGEzCCBPugAwIBAgIQA5SSE1FOcAKjWjfVviKG
-----END CERTIFICATE-----

The first step for any API call is for the TPP to obtain a valid access token with the PSU involvement.
In order to obtain new access token you should use this url:
https://apigw.eurobank.gr/eurobank/apis/auth/oauth2/authorize?response_type=code&client_id={client_id}&redirect_uri={redirect_uri}&scope=accounts

client_id, Your client ID
redirect_uri, The callback uri which will be redirected after successful login.
scope, The scope the token will be used for [accounts, payments, funds-confirmation]
 
After successful login using your ebanking credentials and assuming the redirect_uri is https://www.google.gr, you will be redirected to url:
https://www.google.gr/?code=AAJbzctb-RYlcnTy384NYSJluoB3Pq6nfB4Tf9XDnwjNXgHDF9h86_WAiY6ht29lNp_wa7NEzUNTwdwsBRqX2Lk5B54URNpYM3wSy8e1q_GcDAe8vSg0rWHhJlcfgWyWQja_Eandw4Fahnq0fsduno8UXhkPXndTPPzxMchgQyqVcA
 
The query parameter of the previous url is the <authorization_code> that will be used to generate an access token via the following POST :
curl -X POST https://apigw.eurobank.gr/eurobank/apis/auth/oauth2/token -H 'Content-Type: application/x-www-form-urlencoded' -d 'grant_type=authorization_code&client_id={client_id}&code={authorization_code}'
 
The response of that call will contain the access and refresh token. The access token is valid for 30 min while the refresh token is valid for 90 days.
After the 30min window elapses, you can use the refresh token to obtain a new valid access token via the call:
 
curl -X POST 'https://apigw.eurobank.gr/eurobank/apis/auth/oauth2/token' -H 'Content-Type: application/x-www-form-urlencoded' -d 'grant_type=refresh_token&client_id={client_id}
 
The access token is passed in every API call via the header Authorization: Bearer <access_token>
 

To generate a QSEAL request header you need the following:

Digest Header: Contains the Hash of the message body. The only hash algorithms that may be used to calculate the Digest within the context of this specification are SHA-256 and SHA-512.

An example value is:

SHA-256=0ztZ09Pw+gr01lR0NaqYdkXUC4x5bLGFu8POBzPco/s=

TPP-Signature-Certificate: The pem-formatted certificate used for signing the request, in base64 encoding

An example value is:

-----BEGIN CERTIFICATE----- MIIGEzCCBPugAwIBAgIQA5SSE1FOcAKjW ….  -----END CERTIFICATE-----

Signature: The structure of the "Signature" header is defined in chapter 4.1 of https://datatracker.ietf.org/doc/draft-cavage-http-signatures/

The header consists of:

1.       keyId: Serial Number of the TPP's certificate included in the "TPP-Signature-Certificate" header of this request.

2.       Algorithm: The "Algorithm " parameter is used to specify the digital signature algorithm to use when generating the signature. Must be "rsa-sha256" or "rsa-sha512"

3.       Headers : The list of HTTP headers included when generating the signature for the message. Must include “Digest, X-Request-Id”

4.       Signature : The "signature" parameter is a base 64 encoded digital signature. The client uses the “algorithm” and “headers” signature parameters to form a canonical “signing string”. This “signing string” is then signed with the key associated with “keyId” and the algorithm corresponding to “algorithm”. The “signature” parameter is then set to the base 64 encoding of the signature. In other words, signature is  "Base64(RSA-SHA256(signing string))"

An example value is:

keyId="1.3.6.1.4.1.21528.2.2.99.11534",algorithm="rsa-sha256",headers="digest x-request-id",signature="ewqC5PWVqpNCW68mHWM0wniGI5CmzZm3HpBTsuAh5xYIAPwBQNna/UI917pnBdJoXflXFkLtoylvGUXNRLIvZ6C0rSB8vQugyt9A1XoU5qmqB37U6ICXC+NGYxMelzf/LR4vxXS5Lco1OI84/i0ooeODApgXsjHDyV8H9qe/bueO4Y3qhWQ8jey5QNuDK5xWRTlWwmqaMy58whXSN86XCvY/TOakCcoHxauQn7GUijdEcvRBnfLSN9+fpNZ/H72RpfG0V4H6JxiFrRbBIhA7oHiKcpc1q3XxWhzZKVKj3cMkXYL7AEyQC509RXE2ZLTyNJYa2g6Kaxp/MeTnW0xqzg=="

To create a bank offered consent, you need to invoke the following:

curl -X POST https://apigw.eurobank.gr/eurobank/apis/v1/consents 

  -H 'Accept: application/json' \

  -H 'Content-Type: application/json' 

  -H 'TPP-Redirect-URI: {redirect_uri}' \

  -H 'X-IBM-Client-Id: {client_id}' \

  -H 'Authorization: Bearer {access_token}'

  -H 'X-Request-ID: e6ef4cc6-3375-11e9-b210-d663bd873d93' \

  -H 'Digest: {digest}' \

  -H 'Signature: {signature}' \

  -H 'TPP-Signature-Certificate: {pem-formatted-certificate}' \

  -d '{

  "access": {},

  "combinedServiceIndicator": false,

  "frequencyPerDay": 4,

  "recurringIndicator": true,

  "validUntil": "2020-01-30"

}'

If you wish to use the App2App flow, you must include the header 'X-TPP-App-Redirect-Preferred' in your request and it should equal "true". The full list of the endpoints that support the flow can be found at each api product documentation.

You can send us your questions, comments or suggestions via the contact form.