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.