Home | Support
Picture

Support

  • Open Banking & APIs Glossary

    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.

  • How do I create an application?

    When logged in, follow these steps:
    1. Go to the Apps page and click on “Create New Application”.
    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.

  • How do I see my API usage?

    The numbers of requests, for different APIs, that your application has made appear under “My Account” at “Analytics” section.

  • How do I manage my account?

    When logged in, under "My Account" at "Profile" section choose "Edit Profile". In this page you can view and edit your relevant information.

  • How do I reset my application Client Secret?

    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 "Credentials" section click on "Regenerate" and follow the required steps.

  • What does our sandbox offer?

    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

  • Which users can be used to log-in to sandbox environment?

    Three retail users are available to log-in to sandbox.
    Please find user information below:
    Username:
    customer01 | customer02
    Password:
    11223344 | 11223344
    OTP:
    Not required

  • Which are the valid OTPs in sandbox transactions?

    Not required.

  • What endpoints will be used?

    Account Information
    Endpoint:
    GET /eurobank-cy/erb-apis/prod/v1/accounts/{account-id}/balances
    GET /eurobank-cy/erb-apis/prod/v1/accounts/{account-id}
    GET /eurobank-cy/erb-apis/prod/v1/accounts
    GET /eurobank-cy/erb-apis/prod/v1/accounts/{account-id}/transactions/{transactionId}
    GET /eurobank-cy/erb-apis/prod/v1/accounts/{account-id}/transactions?bookingStatus={bookingStatus}
    GET /eurobank-cy/erb-apis/prod/v1/accounts/{account-id}/transaction-report?dateFrom={dateFrom}&bookingStatus={bookingStatus}
    GET /eurobank-cy/erb-apis/prod/v1/accounts/{account-id}/transactions?dateFrom={dateFrom}&bookingStatus={bookingStatus}

    Account Consents
    Endpoint:
    POST /eurobank-cy/erb-apis/prod/v1/consents
    GET, DELETE /eurobank-cy/erb-apis/prod/v1/consents/{consentId}
    GET /eurobank-cy/erb-apis/prod/v1/consents/{consentId}/status

    Funds Confirmation
    Endpoint:
    POST /eurobank-cy/erb-apis/prod/v1/funds-confirmations

    Funds Confirmation Consents
    Endpoint:
    GET /eurobank-cy/erb-apis/prod/v2/consents/confirmation-of-funds/{consentId}/status
    POST /eurobank-cy/erb-apis/prod/v2/consents/confirmation-of-funds
    DEL,GET /eurobank-cy/erb-apis/prod/v2/consents/confirmation-of-funds/{consentId}

    Bulk Payments
    Endpoint:
    DEL /eurobank-cy/erb-apis/prod/v1/bulk-payments/cross-border-credit-transfers/{paymentId}
    GET /eurobank-cy/erb-apis/prod/v1/bulk-payments/cross-border-credit-transfers/{paymentId}/status
    GET /eurobank-cy/erb-apis/prod/v1/bulk-payments/cross-border-credit-transfers/{paymentId}
    POST /eurobank-cy/erb-apis/prod/v1/bulk-payments/cross-border-credit-transfers
    DEL /eurobank-cy/erb-apis/prod/v1/bulk-payments/sepa-credit-transfers/{paymentId}
    GET /eurobank-cy/erb-apis/prod/v1/bulk-payments/sepa-credit-transfers/{paymentId}/status
    GET /eurobank-cy/erb-apis/prod/v1/bulk-payments/sepa-credit-transfers/{paymentId}
    POST /eurobank-cy/erb-apis/prod/v1/bulk-payments/sepa-credit-transfers

    Payments
    Endpoint:
    DEL /eurobank-cy/erb-apis/prod/v1/payments/cross-border-credit-transfers/{paymentId}
    GET /eurobank-cy/erb-apis/prod/v1/payments/cross-border-credit-transfers/{paymentId}/status
    GET /eurobank-cy/erb-apis/prod/v1/payments/cross-border-credit-transfers/{paymentId}
    POST /eurobank-cy/erb-apis/prod/v1/payments/cross-border-credit-transfers
    DEL /eurobank-cy/erb-apis/prod/v1/payments/sepa-credit-transfers/{paymentId}
    GET /eurobank-cy/erb-apis/prod/v1/payments/sepa-credit-transfers/{paymentId}/status
    GET /eurobank-cy/erb-apis/prod/v1/payments/sepa-credit-transfers/{paymentId}
    POST /eurobank-cy/erb-apis/prod/v1/payments/sepa-credit-transfers

    Periodic Payments
    Endpoint:
    DEL /eurobank-cy/erb-apis/prod/v1/periodic-payments/cross-border-credit-transfers/{paymentId}
    GET /eurobank-cy/erb-apis/prod/v1/periodic-payments/cross-border-credit-transfers/{paymentId}/status
    GET /eurobank-cy/erb-apis/prod/v1/periodic-payments/cross-border-credit-transfers/{paymentId}
    POST /eurobank-cy/erb-apis/prod/v1/periodic-payments/cross-border-credit-transfers
    DEL /eurobank-cy/erb-apis/prod/v1/periodic-payments/sepa-credit-transfers/{paymentId}
    GET /eurobank-cy/erb-apis/prod/v1/periodic-payments/sepa-credit-transfers/{paymentId}/status
    GET /eurobank-cy/erb-apis/prod/v1/periodic-payments/sepa-credit-transfers/{paymentId}
    POST /eurobank-cy/erb-apis/prod/v1/periodic-payments/sepa-credit-transfers

  • How do I issue an access token?

    The first step for any API call is for the TPP to obtain an access token to initiate flow.
    In order to obtain a new access token for sandbox environment you should use this url:
    curl --location --request POST 'https://apigw.eurobank.com.cy/eurobank-cy/erb-apis/tppdev/oauth2/token' \
    --header 'Content-Type: application/x-www-form-urlencoded' \
    --data-urlencode 'scope={{scope}' \
    --data-urlencode 'grant_type=client_credentials' \
    --data-urlencode 'client_id={{clientID}' \
    --data-urlencode 'client_secret={{clientSecret}}'
    client_id, Your client ID.
    client_secret, Your client Secret scope.

    The scope the token will be used for accounts(account.setup), payments(payment.setup), funds-confirmation(funds).
    In order to authorize consent(accounts,funds confirmation) or approve payment with the PSU involvement and obtain an access token via OAuth2 authorization code flow you should use this url:
    https://apigw.eurobank.com.cy/eurobank-cy/erb-apis/oauth-t24-test/oauth2/authorize?response_type={response_type}&client_id={client_id}&scope={scope}&redirect_uri={redirect_uri}&consent={consentId}

    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(AISP), payments(PISP), funds-confirmation(CBPII).
    consent, ConsentId or PaymentId.

    After successful login using your ebanking credentials and assuming the redirect_uri is apigw.eurobank.com.cy, you will be redirected to url:
    https://apigw.eurobank.com.cy/?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.com.cy/eurobank-cy/erb-apis/oauth-t24-test/oauth2/token -H 'Content-Type: application/x-www-form-urlencoded' -H 'consent:{{consentId}}' -d 'grant_type=authorization_code&client_id={client_id}&client_secret={client_secret}&code={authorization_code}&redirect_uri={redirect_uri}'

    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 180 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.com.cy/eurobank-cy/erb-apis/oauth-t24-test/oauth2/token -H 'Content-Type: application/x-www-form-urlencoded' -H 'consent:{{consentId}}' -d 'grant_type=refresh_token&client_id={client_id}&client_secret={client_secret}&refresh_token={refresh_token}&redirect_uri={redirect_uri}'

    The access_token is passed in every API call via the header Authorization: Bearer "

    Production endpoints:
    https://apigw.eurobank.com.cy/eurobank-cy/erb-apis/oauth-infinity/oauth2/token

    https://apigw.eurobank.com.cy/eurobank-cy/erb-apis/oauth-infinity/oauth2/authorize

  • How do I create Bank-offered consent?

    With the acquired initation flow accessToken, you will be able to create the consent for accounts flow. To create a bank offered consent, you need to invoke the following:
    curl --location --request POST 'https://apigw.eurobank.com.cy/eurobank-cy/erb-apis/sandbox/v1/consents' \
    --header 'X-IBM-Client-Id: {{clientId}}' \
    --header 'X-Request-ID: {{requestId}}' \
    --header 'TPP-Redirect-URI: {{redirectUri}}' \
    --header 'Authorization: Bearer {{access_token}}' \
    --data-raw '{
    "access": {
    "allPsd2":"allAccounts"
    },
    "recurringIndicator": true,
    "validUntil": "2024-02-22",
    "frequencyPerDay": 4,
    "combinedServiceIndicator": false
    }'
    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:
    {
    "_links": {
    "scaRedirect": {
    "href": "redirectLink"
    },
    "status": {
    "href": "/v1/consents/AAACTGF3QW1YYdu4Lb/status"
    }
    },
    "consentId": "AAACTGF3QW1YYdu4Lb",
    "consentStatus": "RECEIVED"
    }
    The SCA url provided above is a Eurobank endpoint where the user will view –following further authentication—his accounts 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.

    Production endpoint: https://apigw.eurobank.com.cy/eurobank-cy/erb-apis/prod/v1/consents

  • How do I initiate payments?

    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 -g --request POST 'https://apigw.eurobank.com.cy/eurobank-cy/erb-apis/{{APIModeLive}}/v1/payments/sepa-credit-transfers' \
    --header 'X-IBM-Client-Id: {{Clientid}}' \
    --header 'X-Request-ID: {{RequesTID}}' \
    --header 'TPP-Redirect-URI: {{ClientRedirectURL}}' \
    --header 'psu-ip-address: 192.168.1.1' \
    --header 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MTU1OTQwODksInQiOiJhIiwibSI6ImwiLCJjIjoiMGVmMzdkY2NiNWMyMGQ1NmI4OGM5YmUzZTQzMWQ0NDIiLCJzIjoicGF5bWVudC5zZXR1cCIsImEiOiJwYXZsb3MtcHJvZC1hcHAiLCJrIjoiNWMwMjQzMDhhZjcwNGU5ODhiZWY5N2E0ZjliNWRiZWEifQ.KqbAxivgpRBXI8vChQbvf8qHbt9ownGuYwlNMKzS_eA' \
    --header 'Content-Type: application/json' \
    --data-raw '{
    "creditorAccount": {
    "currency": "EUR",
    "iban": "CY00000000000000000000000000"
    },
    "creditorAgent": "BCYPCY2N",
    "creditorAgentName": "Creditor Agent",
    "creditorName": "Creditor",
    "debtorAccount": {
    "bban": "000000000000",
    "currency": "EUR"
    },
    "endToEndIdentification": "CBCT-test4",
    "instructedAmount": {
    "amount": "2",
    "currency":"EUR"
    },
    "remittanceInformationUnstructured": "TPS-testing-9"
    }'
    The payment initiation response indicates the payment status.
    {
    "paymentId": "PI241350NRRRMVC7",
    "transactionFeeIndicator": true,
    "transactionFees": {
    "amount": 1.25,
    "currency": "EUR"
    },
    "_links": {
    "scaRedirect": {
    "href": "https://apigw.eurobank.com.cy/eurobank-cy/sandbox-cy/oauth-t24-test/oauth2/authorize?response_type=code&client_id=xxx&consent=PI241350NRRRMVC7&scope=PISP&redirect_uri=redirectUrl"
    },
    "status": {
    "href": "/v1/payments/sepa-credit-transfers/PI241350NRRRMVC7/status"
    },
    "self": {
    "href": "/v1/payments/sepa-credit-transfers/"
    }
    },
    "transactionStatus": "RCVD"
    }

  • How does Eurobank identify a TPP?

    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.

  • I send a request using QSEALC certificate and get a certificate validation error

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

  • How do I generate QSEAL request headers:

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

  • I have a question that is not included in the FAQ. What can I do?

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