Some ASPSPs supports payment cancellation. Customer (PSU) / Initiating party (user) can cancel the initiated payment with ASPSP if payment settlement process not started by the customer’s (PSU) bank.

As an Open Banking Service provider, we are allowing to cancel the payment if payment status are as below,

PaymentStatus
{
       “Open”,
       “Pending”,
       “PartiallyAuthorised”,
       “Authorised” 
}

Remark : Payment cancellation is not allowed if payment status for initiated payment is apart from any other from mentioned above.

For this scenario, we have considered that payment status = “Authorised” for the initiated payment.

Take the following steps to complete this scenario.

 

Step – 1 : Get the reach details :

Reach details provides list of APIs needs to be used for this scenario and mandatory fields needs to be passed for successful API call towards ASPSP mock.

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Payment Cancellation” and the ASPSP ID = “20114”, which has to be used to cancel the initiated payment and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out.

 

Step – 2 : Initiate the payment :

Call the POST /payments API with mandatory fields in request header and body. In response of POST /payments, initiating party (user) will receive payment ID, ASPSP redirect link to authorise the initiated payment and link to call GET /payments/status API to get the status of the initiated payment.

If GET /payments/status endpoint has been called before user provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

 

Step – 3 : Authorise or Cancel the payment at ASPSP Mock :

With ASPSP redirect link received in response of POST /payments, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can provide dummy credential details as this is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

If customer (PSU) “Approve” the payment, payment will get initiated with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).

If customer (PSU) “Deny” the payment, ASPSP Mock will reject the initiated payment and customer (PSU) will redirect back to initiating party (user).

Remark : GUI page of ASPSP Mock to approve or deny the payment is just a demo purpose. Actual ASPSP GUI page to approve or deny the payment may vary based on ASPSP.

 

Step – 4 : Get the payment status :

Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

If payment is authorised by customer (PSU), initiating party (user) will receive payment status = “Authorised.

If payment is deny by customer (PSU), initiating party (user) will receive payment status = “Cancelled” as final payment status.

Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Step – 5 : Cancel the payment :

If payment status = “Authorised”, call DELETE /payments API to cancel the initiated payment.

 

Step – 6 : Get the payment status :

Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

If payment is cancelled by ASPSP Mock sucessfully, initiating party (user) will receive payment status = “Cancelled”.

 

Sequence Diagram :

 

Some ASPSP requires hybrid payment authorisation for payment processing.

Take the following steps to complete this scenario.

 

Step – 1 : Get the reach details :

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Payment Redirect with Embedded – Hybrid flow” and the ASPSP ID = “20121”, which has to be used to initiate the payment with hybrid mode of authorisation and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out.

 

Step – 2 : Payment initiation and customer authentication :

• Initiate the payment : Call the POST /payments API without ASPSP PSU-ID and with other mandatory fields in request header and body. In response of POST /payments, initiating party (user) will receive Payment ID, “AspspRedirectUrl” URL for  customer (PSU) authentication at ASPSP Mock & GET /payments/status API link.

• Customer Authentication : Customer (PSU) will be redirected to ASPSP Mock GUI page to provide his / her PSU-ID (Customer ID) which is known to the Bank. At this point, customer (PSU) can provide his / her authentication to ASPSP Mock or cancel the payment initiation.

Remark : Customer can provide dummy PSU-ID (Customer ID) to ASPSP Mock.

If GET /payments/status endpoint has been called, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

 

Step – 3 : Get the payment status and select authentication method :

• Get the payment status : Call the GET /payments/status API. If customer cancel the authentication process, ASPSP Mock will respond with payment status = “Cancelled” to initiating party (user). If customer (PSU) authenticated successfully at ASPSP Mock, Mock will respond with list of available SCA methods (if multiple SCA methods available at ASPSP) for the customer (PSU) to choose.

• Select authentication method : For this scenario, customer (PSU) need to choose ‘SCARedirect’ method for payment authorisation and initiating party (user) need to call the PUT /payments/authorisations to update the selected SCA method to ASPSP Mock. In response, ASPSP Mock will respond with “ASPSPRedirectURL” for payment authorisation.

Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Step – 4 : Authorise or Cancel the payment at ASPSP Mock :

With ASPSP redirect link received in response of PUT /payments/authorisation, customer (PSU) will get redirect to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

If customer (PSU) “Approve” the payment, payment will get initiated with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).

If customer (PSU) “Deny” the payment, ASPSP Mock will reject the initiated payment and customer (PSU) will redirect back to initiating party (user).

Remark : GUI page of ASPSP Mock to approve or deny the payment is just a demo purpose. Actual ASPSP GUI page to approve or deny the payment may vary based on ASPSP.

 

Step – 5 : Get the payment status :

Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

If payment is authorised by customer (PSU), initiating party (user) will receive payment status = “SettlementCompleted”.

If payment is deny by customer (PSU), initiating party (user) will receive payment status = “Cancelled” as final payment status.

Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Sequence Diagram :

 

For this scenario, explicit embedded Pre-Authentication is require with payment in embedded authorisation.

Take the following steps to complete this scenario.

Step – 1 : Get the reach details :

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Payment embedded with Explicit PreAuth Embedded” and the ASPSP ID = “20120”, which has to be used to initiate the payment and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out.

Below is example of pre-authentication reach details for ASPSP.

{
      "AspspId": "20120",
      "Name": [
        {
          "Label": "Payment embedded with Explicit PreAuth embedded",
          "Language": "en"
        }
      ],
      "Country": "XX",
      "CategoryLabel": [
        "Retail"
      ],
      "Details": [
        {
          "Api": "POST /payments",
          "Fieldname": "CommonPaymentData.EndToEndId",
          "Type": "MANDATORY",
          "ProtocolVersion": "CREALOGIX_V_1_0_5",
          "Condition": "!(PaymentProduct=IDEAL)"
        },
        {
          "Api": "POST /scheduled-payments",
          "Fieldname": "DebtorAccount",
          "Type": "MANDATORY",
          "ProtocolVersion": "CREALOGIX_V_1_0_5"
        },
        {
          "Api": "POST /payments",
          "Fieldname": "CommonPaymentData.InitiatingPartyReferenceId",
          "Type": "MANDATORY",
          "ProtocolVersion": "CREALOGIX_V_1_0_5",
          "Condition": "!(PaymentProduct=IDEAL)"
        },
        {
          "Api": "POST /v1/payments",
          "Fieldname": "PaymentProduct",
          "Type": "MANDATORY",
          "Value": "Normal|Instant|Domestic",
          "ProtocolVersion": "CREALOGIX_V_1_0_5"
        },
        {
          "Api": "POST /pre-authentication",
          "Type": "SUPPORTED",
          "ProtocolVersion": "CREALOGIX_V_1_0_5"
        },
        {
          "Api": "POST /payments/{paymentId}/identification",
          "Fieldname": "preferredScaMethod",
          "Type": "SUPPORTED",
          "Value": "REDIRECT",
          "ProtocolVersion": "CREALOGIX_V_1_0_5"
        }
      ],
      "Options": [],
      "BIC": "XXPIS003"
    },

 

In above example, POST /pre-authentication API is mentioned without FieldName and Type = “SUPPORTED” means, ASPSP is supporting pre-authentication.

"Api": "POST /pre-authentication", 
"Type": "SUPPORTED",
"ProtocolVersion": "CREALOGIX_V_1_0_5" 

 

Step – 2 : Initiate the payment :

 

To initiate the payments, below processes needs to be follow.

• Explicit Pre-Authentication in Embedded
• Payment authorisation in Embedded

Step – 3 : Initiate Explicit Pre-Authentication in Embedded :

Perform below steps to initiate explicit pre-authentication in embedded.

• Initiate explicit pre-authentication : Call POST /pre-authentication to initiate explicit Pre-Authentication process. In response of POST /pre-authentication, initiating party (user) will receive PreAuthenticationId, link for “UpdatePsuCredentialsForPreAuthentication” API endpoint for customer (PSU) authentication and “GetPreAuthenticationStatus” API link to get the status of the PreAuth from ASPSP Mock.
• Perform customer (PSU) authentication : Call the PUT /pre-authentication API with customer’s (PSU) credential details. Once ASPSP Mock identifies customer (PSU) successfully, it will response with list of available SCA methods with “SelectAuthenticationMethod” link (if multiple SCA methods available at ASPSP) for the customer (PSU) to choose.
• Authorisation method selection : Once appropriate SCA method chosen to authorise the payment by customer (PSU), initiating party (user) need to call the PUT /pre-authentication API to inform ASPSP Mock.
• Provide challenge data for selected SCA method : Based on selected SCA method by customer (PSU), ASPSP will response with Challenge Data for customer (PSU) for authentication. Once customer (PSU) respond with answer to Challenge Data, initiating party (user) need to call the PUT /pre-authentication API to inform ASPSP Mock. ASPSP Mock will verify the details.

Remark : If initiating party (user) calls GET /pre-authentication/status API during pre-authentication process, ASPSP Mock will respond back PreAuthenticationStatus = “Open”.

Step – 4 : Get the pre-authentication status :

Call the GET /pre-authentication/status API to get the pre-authentication status from ASPSP Mock.

If pre-authentication is authorised by customer (PSU), initiating party (user) will receive PreAuth status = “Authorised”.

If pre-authentication is deny by customer (PSU), initiating party (user) will receive PreAuth status = “Rejected” and payment cannot be initiated by initiating party (user).

Remark : Pre-Authentication status provided for this scenario is just to guide initiating party (user) for pre-authentication process. Actual pre-authentication status may vary based on scenario from actual ASPSP.

Step – 5 : Payment initiation and Authorisation steps :

• Initiate the payment : Once customer (PSU) authenticated successfully with ASPSP and PreAuthenticationStatus = “Authorised”, Call the POST /payments API with mandatory fields in request header and body. In response of POST /payments, initiating party (user) will receive list of available SCA methods with “SelectAuthenticationMethod” link (if multiple SCA methods available at ASPSP) for the customer (PSU) to choose.
• Authorisation method selection : Once appropriate SCA method chosen to authorise the payment by customer (PSU), initiating party (user) need to call the PUT /payments/authorisation API to inform ASPSP Mock. Based on selected SCA method by customer (PSU), ASPSP will response with Challenge Data for customer (PSU) to authorize the payment.
• Provide challenge data for selected SCA method : Once customer (PSU) respond with answer to Challenge Data, initiating party (user) need to call the PUT /payments/authorisation API to inform ASPSP Mock. ASPSP will verify the details and starts payment settlement process.

If GET /payments/status endpoint has been called before initiating party (user) provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

Step – 6 : Get the payment status :

Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

If payment is authorised, initiating party (user) will receive payment status = “SettlementCompleted” as final payment status.

If during any step in Embedded authorisation process, if customer (PSU) has not provided appropriate response, payment will be marked as “Cancelled” at ASPSP Mock and initiating party (user) will receive payment status = “Cancelled” as final payment status.

Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

Sequence Diagram :

For embedded authorisation approach, ASPSP process the payment authorisation through the PISP – ASPSP interface.

Generally there are three steps involve in embedded payment authorisation process.

• In first step, the PSU needs to authenticate himself / herself with the ASPSP.
• In second step, once the PSU is successfully authenticated by the ASPSP, the ASPSP provides a list of SCA methods. In case the ASPSP supports several SCA methods the PSU needs to choose the appropriate SCA method.
• In third step, based on chosen SCA method by the PSU, the ASPSP provides the challenge to the PSU to authorise the payment. The PSU needs to provide challenge response.

Once all these authorisation steps completed successfully, ASPSP starts payment settlement process.

Take the following steps to complete this scenario.

 

Step – 1 : Get the reach details :

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Payment Embedded” and the ASPSP ID = “20105”, which has to be used to initiate the payment with embedded mode of authorisation and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out.

Step – 2 : Payment initiation and Authorisation steps :

Perform below steps to initiate payment.

• Initiate the payment : Call the POST /payments API with mandatory fields in request header and body. In response of POST /payments, initiating party (user) will receive “PostAuthorisationForEmbedded” API endpoint link customer (PSU) authentication.

• Perform customer (PSU) authentication : Call the POST /payments/authorisation API with customer’s (PSU) credential details. Once ASPSP Mock identifies customer (PSU) successfully, it will response with list of available SCA methods (if multiple SCA methods available at ASPSP) for the customer (PSU) to choose.

• Authorisation method selection : Once appropriate SCA method chosen to authorise the payment by customer (PSU), initiating party (user) need to call the PUT /payments/authorisation API to inform ASPSP Mock.

         Remark : Use currently we have populated request body with default selected "AuthenticationMethodId": "13"  for

         "PhotoOTP" SCA method in Put /authoirsations API.

         Request body:

        {
           "AuthenticationMethodId": "13"
        }

• Provide challenge data for selected SCA method : Based on selected SCA method by customer (PSU), ASPSP will response with Challenge Data for customer (PSU) to authorize the payment. Once customer (PSU) respond with answer to Challenge Data, initiating party (user) need to call the PUT /payments/authorisation API to inform ASPSP Mock. ASPSP will verify the details and starts payment settlement process.

         Remark : Use Put /authorisations API with below request body parameters to provide challenge data to complete

         Embedded authorisation flow.

         Request body:

         {
            "ScaAuthenticationData":"123456"
         }

If GET /payments/status endpoint has been called before initiating party (user) provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

 

Step – 3 : Get the payment status :

Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

If payment is authorised, initiating party (user) will receive payment status = “SettlementCompleted” as final payment status.

If during any step in Embedded authorisation process, if customer (PSU) has not provided appropriate response, payment will be marked as “Cancelled” at ASPSP Mock and initiating party (user) will receive payment status = “Cancelled” as final payment status.

Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Sequence Diagram :

 

The transaction flow in the decoupled authorisation approach is similar to the Redirect authorisation approach. The difference is that the ASPSP is asking the customer (PSU) to authorise the payment e.g. via a dedicated mobile app, or any other application or device which is independent from the online banking frontend.

Since decoupled payment approval / rejection is out of scope, we have only considered happy flow for this scenario assuming user is going to provide his / her approval for initiated payment on decoupled application / device.

Take the following steps to complete this scenario.

Step – 1 : Get the reach details :

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Payment decoupled (polling required)” and the ASPSP ID = “20200”, which has to be used to initiate the decoupled payment with redirect mode of authorisation and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out.

 

Step – 2 : Initiate the payment :

Call the POST /payments API with mandatory fields in request header and body. In response of POST /payments, initiating party (user) will receive POST /payments/identification API endpoint and GET /payments/status API endpoint links to get the status of the payment.

Initiating party (user) need to call POST /payments/identification API endpoint to provide “AspspPsuId”. This is PSU’s ID at ASPSP, which helps ASPSP to uniquely identify the bank’s customer (PSU) and ASPSP can initiate payment authorisation on decoupled application / device which is known to customer (PSU).

In response of POST /payments/identification API, customer (PSU) will be notify to use his / her decoupled application / device provided by ASPSP to authorise the initiated payment.

If GET /payments/status endpoint has been called before customer (PSU) provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

 

Step – 3 : Authorise or Cancel the payment :

Since payment approval / rejection on decoupled application / device is out of scope in this scenario, we have only considered happy flow and considering user is going to provide his / her approval for initiated payment on decoupled application / device.

Remark : During actual payment authorisation on decoupled application / device, PSU can approve / reject the payment based on functionality provided in decoupled application / device.

Step – 4 : Get the payment status :

Initiating party (user) need to do polling by calling GET /payments/status to get the latest payment status from ASPSP Mock.

Since the decoupled approval is out of scope of this scenario we have implemented an timed status change of the payment by the ASPSP mock.

If initiating party (user) call GET/payments/status after 8 seconds, in response initiating party (user) will receive payment status = “Authorised” from ASPSP Mock.

If initiating party (user) call GET/payments/status after 8 seconds, in response initiating party (user) will receive payment status = “SettlementCompleted” from ASPSP Mock as a final payment status.

Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Sequence Diagram :

 

The API for bulk payments allows the initiation of multiple payments within one single request. Process to initiate Bulk payment with redirect authorisation is similar to "Payment with Redirect Authorisation" with multiple payment instructions to pass in request body by the initiating party (user).

Take the following steps to complete this scenario.

 

Step – 1 : Get the reach details :

Reach details provides list of APIs needs to be used for this scenario and mandatory fields needs to be passed for successful API call towards ASPSP mock.

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Bulk Payment Redirect” and the ASPSP ID = “20210”, which has to be used to initiate the bulk payment with redirect mode of authorisation and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out.

 

Step – 2 : Initiate the bulk payment :

Call the POST /bulk-payments API with multiple payment instructions and mandatory fields in request header and body. In response of POST /bulk-payments, initiating party (user) will receive payment ID, ASPSP redirect link to authorise the initiated bulk payment and link to call GET /bulk-payments/status API to get the status of the initiated payment.

If GET /bulk-payments/status endpoint has been called before user provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

 

Step – 3 : Authorise or Cancel the bulk payment at ASPSP Mock :

With ASPSP redirect link received in response of POST /payments, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can provide dummy credential details as this is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

If customer (PSU) “Approve” the bulk payment, payments will get initiated with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).

If customer (PSU) “Deny” the bulk payment, ASPSP Mock will reject the initiated payments and customer (PSU) will redirect back to initiating party (user).

Remark : GUI page of ASPSP Mock to approve or deny the bulk payments is just a demo purpose. Actual ASPSP GUI page to approve or deny the payment may vary based on ASPSP.

 

Step – 4 : Get the bulk payment status :

Call the GET /bulk-payments/status API to get the latest payment status from ASPSP Mock.

If bulk payments is authorised by customer (PSU), initiating party (user) will receive payment status = “Settlement Completed” as final payment status.

If bulk payments is deny by customer (PSU), initiating party (user) will receive payment status = “Cancelled” as final payment status.

Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Sequence Diagram :

 

Process to initiate Scheduled payment with redirect authorisation is similar to "Payment with Redirect Authorisation" with additional mandatory parameter “RequestedExecutionDate” to pass in request body by the initiating party (user).

Take the following steps to complete this scenario.

 

Step – 1 : Get the reach details :

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Scheduled Payment Redirect” and the ASPSP ID = “20111”, which has to be used to initiate the scheduled payment with redirect mode of authorisation and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out.

 

Step – 2 : Initiate the scheduled payment :

Call the POST /scheduled-payments API with mandatory fields in request header and body. In response of POST /scheduled-payments, initiating party (user) will receive payment ID, ASPSP redirect link to authorise the initiated scheduled payment and link to call GET /scheduled-payments/status API to get the status of the initiated payment.

If GET /scheduled-payments/status endpoint has been called before user provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

 

Step – 3 : Authorise or Cancel the scheduled payment at ASPSP Mock :

With ASPSP redirect link received in response of POST /payments, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can provide dummy credential details as this is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

If customer (PSU) “Approve” the scheduled payment, payment will get initiated with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).

If customer (PSU) “Deny” the scheduled payment, ASPSP Mock will reject the initiated payment and customer (PSU) will redirect back to initiating party (user).

Remark : GUI page of ASPSP Mock to approve or deny the payment is just a demo purpose. Actual ASPSP GUI page to approve or deny the payment may vary based on ASPSP.

 

Step – 4 : Get the scheduled payment status :

Call the GET /scheduled-payments/status API to get the latest payment status from ASPSP Mock.

If scheduled payment is authorised by customer (PSU), initiating party (user) will receive payment status = “Authorised” as final payment status.

If scheduled payment is deny by customer (PSU), initiating party (user) will receive payment status = “Cancelled” as final payment status.

Remark : Scheduled payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Sequence Diagram :

 

Process to initiate Periodic payment with redirect authorisation is similar to "Payment with Redirect Authorisation" with additional mandatory object “PeriodRules” to pass in request body. User need to pass below fields values under “PeriodRules” for periodic payment.

PeriodRules*
{
       StartDateTime *     string($date-time)
              ExecutionRule       string
       EndDate             string
       Frequency*          string 
       DayOfExecution      integer
}

Remark : Fields with (*) are mandatory fields to provide in periodic payment request. And refer POST /periodic-payments API for more information.

 

Take the following steps to complete this scenario.

Step – 1 : Get the reach details :

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Periodic Payment Redirect” and the ASPSP ID = “20220”, which has to be used to initiate the scheduled payment with redirect mode of authorisation and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out.

 

Step – 2 : Initiate the periodic payment :

Call the POST /periodic-payments API with mandatory fields in request header and body. In response of POST /periodic-payments, initiating party (user) will receive payment ID, ASPSP redirect link to authorise the initiated periodic payment and link to call GET /periodic-payments/status API to get the status of the initiated payment.

If GET /periodic-payments/status endpoint has been called before user provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

 

Step – 3 : Authorise or Cancel the periodic payment at ASPSP Mock :

With ASPSP redirect link received in response of POST /payments, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can provide dummy credential details as this is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

If customer (PSU) “Approve” the periodic payment, payment will get initiated with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).

If customer (PSU) “Deny” the periodic payment, ASPSP Mock will reject the initiated payment and customer (PSU) will redirect back to initiating party (user).

Remark : GUI page of ASPSP Mock to approve or deny the payment is just a demo purpose. Actual ASPSP GUI page to approve or deny the payment may vary based on ASPSP.

 

Step – 4 : Get the periodic payment status :  

Call the GET /periodic-payments/status API to get the latest payment status from ASPSP Mock.

If periodic payment is authorised by customer (PSU), initiating party (user) will receive payment status = “Authorised” as final payment status.

If periodic payment is deny by customer (PSU), initiating party (user) will receive payment status = “Cancelled” as final payment status.

Remark : Periodic payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Sequence Diagram :

 

Usually the consent or payment data is sent to the ASPSP prior to the authorization. Some banks offer or even demand an authentication before asking for the consent or payment details. For these cases our "Open Banking Service" offers a pre-authentication endpoint. After successful pre-authentication the "Open Banking Service" receives a Pre-Authentication Token from the ASPSP and uses it for later POST consent or POST payment. For the POST consent (or payment) the second factor authorization will be handled via redirect, Decoupled or Embedded Approach as demanded by the response received on the corresponding POST request.

If a POST consent or payment is done without having executed the explicit pre-authentication the "Open Banking Service" offers an implicit pre-authentication as well. In this case it is checked in the database whether a pre-authentication has been done before. If that isn’t the case the consent or payment details are buffered internally and a redirect URL is responded to the Initiating Party for the pre-authentication. When following that redirection the PSU authenticates at the ASPSP and will be redirected to the "Open Banking Service" where the pre-Authentication Token is received and the buffered consent or payment details are posted to the ASPSP. In the response the ASPSP will provide the redirection for the SCA. To that URL the "Open Banking Service" will redirect the PSU’s browser.

Since some ASPSPs require an explicit pre-authentication, whilst others can be run via implicit pre-authentication, a set of ASPSP specific parameters are defined within the "Open Banking Service" to handle the flows appropriately.

For this PreAuth payment, we are offering explicit PreAuth payment scenario in developer portal. So, that initiating party (user) can get to know on how to initiate PreAuth payment with redirect authorisation.

Take the following steps to complete this scenario.

 

Step – 1 : Get the reach details :

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “PreAuth Payment Redirect” and the ASPSP ID = “20115”, which has to be used to initiate the PreAuth payment with redirect mode of authorisation and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out.

 

Below is example of pre-authentication reach details for ASPSP.

{ 
"AspspId": "20115",
"Name": [
        {
          "Label": "Payment pre-authentication",
          "Language": "en"
        }
      ],
      "Country": "XX",
      "CategoryLabel": [
        "Retail"
      ],
"Details": [
          {
             "Api":"POST /payments",
             "Fieldname": "CommonPaymentData.EndToEndId",
             "Type": "MANDATORY",
             "ProtocolVersion": "BG_V_1_3_0",
           },
          {
            "Api": "POST /scheduled-payments",
            "Fieldname": "DebtorAccount",
            "Type": "MANDATORY",
            "ProtocolVersion": "BG_V_1_3_0"
          },
          {
            "Api": "POST /payments",
            "Fieldname": "CommonPaymentData.InitiatingPartyReferenceId",
            "Type": "MANDATORY",
            "ProtocolVersion": "BG_V_1_3_0",
          },
          {
            "Api": "POST /pre-authentication",
            "Type": "SUPPORTED",
            "ProtocolVersion": "BG_V_1_3_0"
          },
          {
            "Api": "POST /payments/{paymentId}/identification",
            "Fieldname": "preferredScaMethod",
            "Type": "SUPPORTED",
            "Value": "REDIRECT",
            "ProtocolVersion": "BG_V_1_3_0"
          }
           ],
"Options": [{
                "Key1": "PREAUTH_MANDATORY",
                "Value": "1",
                "Level": "INFORMATIONAL"
            }
           ],
           "BIC": "XXPIS003"
        }

In above example, POST /pre-authentication API is mentioned without FieldName and Type = “SUPPORTED” means, ASPSP is supporting pre-authentication.

"Api": "POST /pre-authentication",                
"Type": "SUPPORTED",
"ProtocolVersion": "BG_V_1_3_0"    

The Options section is providing information regarding the way of using API endpoints for specific ASPSPs similar to the Details section. In example, the given ASPSP pre-authentication is mandatory because the value of PREAUTH_MANDATORY option is set to 1.

"Key1": "PREAUTH_MANDATORY",
"Value": "1",
"Level": "INFORMATIONAL"

 

Step – 2 : Initiate the Pre-Authentication :

Call the POST /pre-authentication API to initiate to initiate the pre-authentication for the payment. In response of POST /pre-authentication, initiating party (user) will receive PreAuthenticationId, link for AspspRedirectUrl to pre-authorise the payment at ASPSP Mock and link ‘GetPreAuthenticationStatus’ to get the status of the PreAuthentication.

If GET /pre-authentication/status endpoint has been called before customer (PSU) provides his / her approval, initiating party (user) will receive pre-authentication status = “Open” from the ASPSP Mock in response.

 

Step – 3 : Authorise or Cancel the Pre-Authentication at ASPSP Mock :

With ASPSP redirect link received in response of POST /payments, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can provide his / her dummy credential details. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

With ASPSP redirect link received in response of POST /pre-authentication, customer (PSU) will get redirect to ASPSP Mock GUI page with “Approve” & “Deny” buttons for pre-authentication of the payment.

If customer (PSU) “Approve” the pre-authentication, customer (PSU) will redirect back to initiating party (user) and initiating party (user) can initiate the payment.

If customer (PSU) “Deny” the pre-authentication, ASPSP Mock will mark the pre-authentication “Rejected” and initiating party (user) will not be able to initiate the payment.

Remark : GUI page of ASPSP Mock to approve or deny the pre-authentication is just a demo purpose. Actual ASPSP GUI page to approve or deny the pre-authentication may vary based on ASPSP.

 

Step – 4 : Get the pre-authentication status :

Call the GET /pre-authentication/status API to get the pre-authentication status from ASPSP Mock.

If pre-authentication is authorised by customer (PSU), initiating party (user) will receive PreAuth status = “Authorised”.

If pre-authentication is deny by customer (PSU), initiating party (user) will receive PreAuth status = “Rejected” and payment cannot be initiated by initiating party (user).

Remark : Pre-Authentication status provided for this scenario is just to guide initiating party (user) for pre-authentication process. Actual pre-authentication status may vary based on scenario from actual ASPSP.

 

Step – 5 : Initiate the payment :

Once pre-authentication status = “Authorised”, initiating party (user) can call the POST /payments API with mandatory fields in request header and body to initiate the payment. In response of POST /payments, initiating party (user) will receive payment ID, ASPSP redirect link to authorise the initiated payment and link to call GET /payments/status API to get the status of the initiated payment.

If GET /payments/status endpoint has been called before customer (PSU) provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

 

Step – 6 : Authorise or Cancel the payment at ASPSP Mock :

With ASPSP redirect link received in response of POST /payments, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can provide dummy credential details as this is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

If customer (PSU) “Approve” the payment, payment will get initiated with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).

If customer (PSU) “Deny” the payment, ASPSP Mock will reject the initiated payment and customer (PSU) will redirect back to initiating party (user).

Remark : GUI page of ASPSP Mock to approve or deny the payment is just a demo purpose. Actual ASPSP GUI page to approve or deny the payment may vary based on ASPSP.

 

Step – 7 : Get the payment status :

Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

If payment is authorised by customer (PSU), initiating party (user) will receive payment status = “Authorised” as final payment status.

If payment is deny by customer (PSU), initiating party (user) will receive payment status = “Cancelled” as final payment status.

Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Sequence Diagram :

 

Some ASPSP requires payment confirmation from initiating party (user) to start further payment settlement process after payment has been authorised by customer (PSU). Payment initiation and authorisation process are same as described in “Payment with Redirect Authorisation” scenario for payment with confirmation scenario.

Take the following steps to complete this scenario.

 

Step – 1 : Get the reach details :

Note – Details of reach information in developer portal is limited and informational purpose to give user an idea about how reach information looks like.

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Payment Redirect with Confirmation” and the ASPSP ID = “20110”, which has to be used to initiate the payment with redirect mode of authorisation with confirmation and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out.

 

Step – 2 : Initiate the payment :

Call the POST /payments API with mandatory fields in request header and body. In response of POST /payments, initiating party (user) will receive payment ID, ASPSP redirect link to authorise the initiated payment and link to call GET /payments/status API to get the status of the initiated payment.

If GET /payments/status endpoint has been called before user provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

 

Step – 3 : Authorise or Cancel the payment at ASPSP Mock :

With ASPSP redirect link received in response of POST /payments, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can provide dummy credential details as this is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

If customer (PSU) “Approve” the payment, payment will get initiated with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).

If customer (PSU) “Deny” the payment, ASPSP Mock will reject the initiated payment and customer (PSU) will redirect back to initiating party (user).

Remark : GUI page of ASPSP Mock to approve or deny the payment is just a demo purpose. Actual ASPSP GUI page to approve or deny the payment may vary based on ASPSP.

 

Step – 4 : Get the payment status :

Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

If payment is authorised by customer (PSU), initiating party (user) will receive payment status = “Authorised”.

If payment is deny by customer (PSU), initiating party (user) will receive payment status = “Cancelled” as final payment status.

Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Step – 5 : Payment Confirmation :

Call the POST /payments/confirmation API, to confirm the payment with ASPSP Mock. In response, initiating party (user) will receive payment status = “SettlementInProcess”.

 

Step – 6 : Get the payment status after payment confirmation :

Call the GET /payments/status API after payment confirmation. In response, initiating party (user) will receive payment status = “SettlemenCompleted” for initiated payment.

Remark : Payment status provided for this scenario is just to guide the initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

Sequence Diagram :