Frequently Asked Questions

We do not currently implement any functionality related to the refresh_token. This applies to both "Development" (Sandbox) and "Production" states.

Should there be any changes in the implementation, the documentation available in our Portal will be properly updated.

The POST request to the Token URL requires the client_id and client_secret of your app:

  • either as body parameters,
  • or within the Authorization Header, with Basic Authentication as such:   Authorization: Basic <base64 encoded string client_id:client_secret>

For further details, please read the chapter "Authorization (OAuth)" in "Getting Started", here.

Yes. There are three available sets of credentials, one for each predefined user in Sandbox.

Please visit the chapter "Sandbox" in "Getting Started", here. There, you can find all the information you need to proceed, including valid input data to perform tests.

Once you receive the ExtraPin token you have to use it within 2 minutes. After its validation, the ExtraPin is valid until session expiration. If the ExtraPin token is not used on time or the current session expires (which forces a new login), you have to perform another request to generate a new ExtraPin token.

The parameter input_filter follows a format specified by a particular definition in each API.

For instance, as you can see in the image below, for "/assets/accounts/{accountId}/transactions/{input_filter}", the input_filter follows the definition Asset_Accounts_Transactions_Input, in which you can also find an example.


For your convenience, here is an example for input_filter :

      "fromDate": "2015-1-9",
      "toDate": "2015-4-9",
      "fromRow": "",
      "pageSize": 20,
      "lastBalance": 0.0

No. The base API endpoint is common for both states. This information is available within the section “API Products”, where you select each product, to view the APIs it contains along with all the required information. Currently, the base API endpoint for applications of both states is:

This information is located in the section API Products, where each available product is presented, along with the APIs it contains and any related information. Additionally, you can visit the section “Getting Started”, where the available documentation provides the basic knowledge regarding OAuth2 and the Authorization process.

When upgrading an application from “Development” to “Production”, the Authorization and Token URLs, as well as the scope used in the Authorization process change.

An example of the current URLs and scopes for each state is presented below, however you should always check each API’s specification for more accurate information.


Authorization URL

Token URL




Authorization URL

Token URL


winbankAccess winbankAccess.monetaryTransactions

For further information regarding the Development and Production states, read the respective Chapter in “Getting Started” (here).

This field is not necessary to complete the registration process. However, it is mandatory during the Authorization process followed when you need to call an API. You can fill in or change this information either upon registration or at a later time, but you always have to make sure that this Redirect URI is the same with the one you are using as input when you call the Authorize and Token URLs of OAuth.

When logged in, follow the next 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.

For further information, read the chapter “First Steps” in the section “Getting Started” (here).

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 of 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 what you need and choose the most suitable plan.

To do so, when logged in, you can visit the “API Products” page, either from the Menu or 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 your application may utilize.

For further information, read the chapter “First Steps” in the section “Getting Started” (here).

When logged in, click on the user menu and select “My Organization”. In this page you can:

  1. Edit your organization (change its name)
  2. Add new users
  3. Remove existing users
  4. Get Analytics for your applications

When logged in, click on the user menu and select “Create an Organization”. You can have multiple organizations 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)

Click the upper right link “Create an account” and fill in the form. All fields are mandatory.

In the case of PSD2 APIs, does Upgrade to Production require any contractual arrangement between TPPs and the Bank?

For applications subscribed to PSD2 APIs, Upgrade to Production does not require any formal paperwork or contractual arrangements between the TPPs and Piraeusbank.

TPPs must be registered AIS and/or PIS providers and send us their QWAC certificate. Upon certificate validation, their applications will be upgraded to Production.

Migrating from version 1.1 to version 1.2 of PB API Products involves the following changes:

1.  One-time pin (also known as "extra pin") has become transactional, i.e. it is required each time the end-user needs to perform a transaction, instead of once per session until now.

2.  Third-party applications do not request for otp generation. As long as the end-user's default SCA method is not CHIP_OTP, the backend system will automatically recognize which SCA method to apply and send the extra pin automatically. In any case, the third-party application will receive a proper message/error explaining which steps need to be followed prior to transaction execution.

3.  The flow of monetary transactions has been altered, as such:

        • When an end-user wants to perform a monetary transaction, i.e. money transfer, the third party application will call the /transferToIban/validate endpoint.
        • Based on the provided input, the system will recognize the type of transfer to check if a transactional pin is required:

   a)  If the transaction involves a single transfer to one of the end-user's own accounts, then no transactional pin is (currently) required.
   b)  If the transaction involves a single transfer to a third Pireausbank acccount or a single remittance to an account in a different bank, then a transactional pin is required.
   c)  If the transaction involves a bulk payment (mass transfer or payroll via file submission for corporate users only), then a transactional pin is again required.

        • When there is no need for transactional pin, the validate response object will be returned with a SessionKey, which will be required as input to the /transferToIban/execute endpoint.
        • On the contrary, if a transactional pin is needed, the system will check the end-user's available and default SCA methods:

   a)  If the user does not have any available SCA methods registered, a proper error will be returned, letting them know that the transaction cannot be completed.
   b)  If the user has at least one available SCA method registered, then the validate response object will be returned with a SessionKey, which will be required as input to the /transferToIban/execute endpoint, together with an error object, informing the user on the SCA method applied to receive the transactional pin which will also supplied as input to the /transferToIban/execute endpoint.

        • The third-party application then calls the /transferToIban/execute endpoint, sending the SessionKey and the TransactionalPin (when needed) into the request body.

4.  Due to the change in transactions' flow, the endpoints /transferToIban, /bulkPayments, /payroll, which performed monetary transactions in a single step, have been retired. From now on, monetary transactions can only be performed in two separate steps, validate and execute.

5.  Due to the abovementioned changes, the Security API has also changed. Old endpoints have been removed, and now there is only one endpoint, /security/token/select/{TokenType}/for/{SessionKey}, which is used when the third-party application, on behalf of the end-user, requests to change the SCA method applied to receive an one-time pin for a specific transaction. Acceptable values of {TokenType} include: SMS_OTP and PUSH_OTP. The change will be effective only for that particular transaction, which is why the {SessionKey} must be also provided, and as long as the selected SCA method is available to the end-user.