ob-p-a2a-s8

Payment with Embedded Authorisation

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 :

Post Payment with Embedded Authorisation

 

Enable "on this page" menu on doc section
On

ob-p-a2a-s7

Payment with Decoupled Authorisation

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 :

Post payment with Decoupled Authorisation

 

Enable "on this page" menu on doc section
On

ob-p-a2a-s6

Bulk Payment with Redirect Authorisation

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 :

Bulk Payment with Redirect Authorisation

 

Enable "on this page" menu on doc section
On

ob-p-a2a-s5

Scheduled Payment with Redirect Authorisation

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 :

Scheduled Payment with Redirect Authorisation

 

Enable "on this page" menu on doc section
On

ob-p-a2a-s4

Periodic Payment with Redirect Authorisation

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 :

Periodic Payment with Redirect Authorisation

 

Enable "on this page" menu on doc section
On

ob-p-a2a-s3

PreAuth Payment with Redirect Authorisation

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 :

PreAuth with Redirect Authorisation

 

Enable "on this page" menu on doc section
On

ob-p-a2a-s2

Payment Confirmation with Redirect Authorisation

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 :

Payment Confirmation with Redirect Authorisation

 

Enable "on this page" menu on doc section
On

ob-p-a2a-pis-api

Single Payment

API Reference

Single payment is a standard payment that should be executed by the payer's bank as soon as possible after payment authorisation. 

Single payments are typically used in context of e-commerce or in-store payments but could also be used in context of incoming / outgoing invoice payments.

POST Single Payment API

The base URL is: /xs2a/routingservice/services/ob/pis/v3

Endpoint: POST /payments

You need to provide a few mandatory headers together with a few basic payment details.  The full API reference can be found here.

  • Body parameters that are marked as optional, could still be mandatory for certain ASPSP’s. Details on these optional parameters can be retrieved from the Reach API. For specific APIs parameters might be marked as Forbidden (in this case they must not be set for that ASPSP) or as Mandatory for the specific ASPSP.
  • We support Instant and standard Sepa Credit transfers in addition to local payment schemes (e.g. in Poland).  Please ensure that payer's bank support your preferred PaymentProduct as it was explained in Step 1 - payment preparation.
  • You can specify you preferred payment authorisation flow in PreferredScaMethod parameter but it is not guaranteed that the bank will follow your preference.
  • It is important to provide  a unique (for you) value in the EndToEndId parameter. Often banks will provide this value in payer's or payee's bank statement provided in machine readable format, hence allowing automated reconciliation. In addition, we recommend providing some kind of unique identifier (not UUID) in the RemittanceInformation field as well. NOTE that the RemittanceInformation field is normally visible to the payer / payee and should explain the payment context in a user friendly manner.
  • We support payments with flexible amount, meaning that the end user can update the payment amount within predefined range. You can use Amount Type parameter to control the settings. 
  • You may check the request examples and the datamodel of the request and response below.

To test your payment implementation please use our Sandbox Scenarios.

Examples

Example of a post payments request with a minimal set of fields which will work for most ASPSP's:

{
  "PaymentProduct": [
    "PSD2-SCT"
  ],
  "PsuData": {
    "AspspId": "20100"
  },
  "CommonPaymentData": {
    "EndToEndId": "ID-7853389",
    "InitiatingPartyReferenceId": "Ref-88276166",
    "Amount": {
      "Amount": "1.00",
      "Currency": "EUR"
    },
    "DebtorInformation": {
      "Name": "Juno Smith"
    },
    "RemittanceInformation": "Remittance Information"
  }
}

Example of a payment request which includes additional information about the debtor:


  {
  "PaymentProduct": [
    "PSD2-SCT"
  ],
  "PsuData": {
    "AspspId": "20100"
  },
  "CommonPaymentData": {
    "EndToEndId": "ID-0123456789",
    "InitiatingPartyReferenceId": "Ref-992098126",
    "PreferredScaMethod": [
      "Redirect"
    ],
    "Amount": {
      "Amount": "123.45",
      "Currency": "EUR"
    },
    "DebtorInformation": {
      "Name": "Bob Smith",
      "Agent": "8QB2EN7P",
      "Account": {
        "SchemeName": "IBAN",
        "Identification": "DE89370400440532013000",
        "Currency": "EUR"
      }
    },
    "RemittanceInformation": "Remittance Information"
  }
}

Data model

Below is a representation of the API request and response structure.

Request (click to enlarge)Response (click to enlarge)
Post payments requestPost payments response

 

Enable "on this page" menu on doc section
On

ob-p-a2a-reach

Reach Directory

API Reference

The Reach Directory API allows the Initiating Party to retrieve a list of all reachable ASPSP's via the Open Banking Service. The main information that can be received is the ASPSP name and ID, which has to be used to identify the ASPSP to which the payment should be addressed.

The information returned by the Reach Directory API doesn't change frequently. It will be sufficient to retrieve a new list once a day.

ASPSP's have implemented their APIs based on several standards, sometimes with proprietary deviations. Since the Open Banking Service offers a unified API to reach ASPSP's, additional information is provided to inform the Initiating Party about specific details required to make a successful payment request.

How these specific details are communicated in the Reach Directory response is described in the sections 'Details' and 'Options'

Details

The Details section in the reach directory response consists of the following fields:

  • Api
  • FieldName
  • Type
  • Value
  • ProtocolVersion

Mandatory information in this section is the Api, which is defining for which endpoint the information is applicable. If there is no FieldName given, the Type is describing whether this endpoint is available (SUPPORTED) or not (UNSUPPORTED).

TypeDescription if NOT combined with a FieldName
UNSUPPORTED

The mentioned Api is not supported by the ASPSP, the Open Banking Service will throw an error if it’s used.

This is mentioned for Api’s which are normally supported (for the api’s not mentioned in the row below)

SUPPORTED

The mentioned Api is supported by the ASPSP. This is mentioned for the following Api’s (because they are usually not supported):

- POST /psus/{psuId}/Aspsps/{aspspId}/pre-authentication"

If the Post is supported the corresponding api methods (GET, PUT, DELETE) are also supported, if defined in the swagger.

If the FieldName is given, the Type is describing whether the field is UNSUPPORTED, SUPPORTED, MANDATORY or FORBIDDEN. The table below specifies the rules for the Type-FieldName combination:

TypeDescription if combined with a FieldName
UNSUPPORTEDThe mentioned FieldName is ignored if provided to the Open Banking Service, the Open Banking Service will not throw an error
SUPPORTEDA subset of the values in the mentioned FieldName is supported. The Value field (which is always supplied with the SUPPORTED Type) will indicate which values are supported. If no value is provided by the initiating party the Open Banking Service will use a default value. If an unsupported value is used, the Open Banking Service will throw an error.
MANDATORYThe mentioned FieldName is mandatory and has to be filled. If supplied, the Value field will indicate which values are supported. If the Value field is not supplied no validation on the field is done by the Open Banking Service. If the mentioned FieldName is not filled by the initiating party the Open Banking Service will throw an error. If an unsupported value is used, the Open Banking Service will throw an error.
FORBIDDENThe mentioned FieldName is forbidden. The Open Banking Service will throw an error if the initiating party fills this field and the request will not be sent to the ASPSP.

The FieldName may refer to a header field in the same way. Since the fields in an API endpoint are unique for header and body there is no distinction between header and body in the Details record.

The Value is providing detailed information of that field within the given Api. If the Value contains a list of values, they are separated by ‘|’.

In addition the ProtocolVersion used for the communication between the Open Banking Service and the ASPSP is provided, although this information isn’t crucial for the Initiating Party.

Example for API

An example for Api without the FieldName is the pre-authentication Api. For most ASPSPs a pre-authentication is not supported. For those ASPSPs where a pre-authentication is possible there is a record in the Details:

"Api": "POST /psus/{psuId}/Aspsps/{aspspId}/pre-authentication",
"Type": "SUPPORTED",
"ProtocolVersion": "BG_V_1_3_0"

Examples for Api combined with FieldName

An example of Api combined with a FieldName is the Post /payments Api with the PaymentProduct field. This field is defined as optional in the corresponding swagger file. The swagger also indicates that four values can be given: Normal, Instant, Target2 or Domestic. In the case that only a subset of these values is supported by the ASPSP, the following record is provided in the reach directory response:

"Api": "POST /payments",
"FieldName": "PaymentProduct",
"Type": "SUPPORTED",
"Value": "Normal|Instant",
"ProtocolVersion": "BG_V_1_3_0"

In this example above Type SUPPORTED indicates the PaymentProduct field is still optional but the values to be used are restricted to Normal and Instant.

It would be possible to configure the same for Type MANDATORY. In that case the PaymentProduct has to be specified in the POST payment request.

"Api": "POST /payments",
"FieldName": "DebtorName",
"Type": "MANDATORY",
"ProtocolVersion": "BG_V_1_3_0"

In this example the Type is MANDATORY, the DebtorName has to be provided in the body. No Value is given, so no validation is done for the content.

Options

The Options section is providing information regarding the way of using API endpoints for specific ASPSPs similar to the Details section. But the information given here is not that specifically related a single API’s endpoint. It is more to be seen as a parameter for the ASPSP itself even though a clear separation between API endpoint and ASPSP globally isn’t that clear always.

Since the Options are not defined for a single endpoint there is no Api attribute given for the single options. Instead they have two keys (Key1 and Key2) identifying the use of the single Option. An example for this is:

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

In this case for the given ASPSP pre-authentication is mandatory because the value is set to 1. The setting of 1 is reflecting that the option is set. A list of possible option keys is given below. The Key2 is currently not used. It is foreseen to allow definition of grouped options having the same main key Key1 and a different sub-key key2. An example for options provided in the Reach API is shown below:

Key1Key2ValueLevelDescription
PREAUTH_MANDATORY 1, 0INFORMATIONALThe pre-authentication (regardless whether being done implicitly or explicitly) is mandatory. Default 0
PREAUTH_EXPLICIT_REQUIRED 1, 0CRITICALPre-authentication has to be done explicitly by the POST pre-authentication endpoint

GET ASPSPs

The base URL for the Reach Directory is: /xs2a/routingservice/services/directory/v3 

Endpoint: GET /aspsps

This endpoint is used to retrieve the reach directory.

Data model

RequestResponse (click to enlarge)
Get reach requestGet reach response

Example: Reach PIS

Request

GET https://xs2a.awltest.de/xs2a/routingservice/services/directory/v2/aspsps?allDetails=true
 
Authorization: Bearer 4248ce19f27a7df671b29a1816a0ff1f
Accept: application/json
Host: xs2a.ewl.de

Response

HTTP/1.1 200 OK
Cache-Control: no-cache,no-store
MessageCreateDateTime: 2021-03-22T13:51:34.431Z
X-Request-ID: 4aa13498-b3eb-4dbf-b373-a9878b29214d
Pragma: no-cache
Date: Mon, 22 Mar 2021 13:51:34 GMT
Content-Type: application/json;charset=UTF-8
Connection: close
Strict-Transport-Security: max-age=16070400; includeSubDomains
Transfer-Encoding: chunked
{
    "Service": "PIS",
    "ASPSP": [
        {
            "AspspId": "1401",
            "Name": [    {
                "Label": "French example bank",
                "Language": "en"
            }],
            "CountryCode": "FR",
            "CategoryLabel": [],
            "Details": [
                {
                    "Api": "POST /payments",
                    "Fieldname": "PaymentProduct",
                    "Type": "SUPPORTED",
                    "Value": "Normal",
                    "ProtocolVersion": "STET_V_1_4_2_1_7"
                },
                {
                    "Api": "POST /payments",
                    "Fieldname": "RemittanceInformation",
                    "Type": "MANDATORY",
                    "ProtocolVersion": "STET_V_1_4_2_1_7"
                },
                {
                    "Api": "POST /payments/{paymentId}/identification",
                    "Fieldname": "preferredScaMethod",
                    "Type": "SUPPORTED",
                    "Value": "REDIRECT",
                    "ProtocolVersion": "STET_V_1_4_2_1_7"
                }
            ],
            "BIC": "FREBFRPP"
        }
    ]
}
Enable "on this page" menu on doc section
On

ob-obp-common-elements

Common API Elements

The following common elements apply to all Open Banking APIs, so please keep it in mind while implementing any of the endpoints.

Timezones and Time Formats

The ISODateTime standard is used in the Open Banking v3 API.

  • Datetime fields sent towards the Open Banking Service should have a timezone (for example: YYYY-MM-DDThh:mm:ssZ or YYYY-MM-DDThh:mm:ss+02)

  • Date fields sent towards the Open Banking Service are always interpreted as being in UTC.

API Compatibility Policy

All APIs follow the robustness principle: "be conservative in what you do, be liberal in what you accept from others". This means the following cases MUST NOT cause an error on client or server side:

  • unrecognized query parameters

  • unrecognized headers

  • unrecognized fields in body

Links Section

In the responses to API calls, usually a section called Links is included. This section contains endpoints that might be or even have to be called by the Initiating Party for the next steps. As described in section Authorization Flow, the ASPSP decides on the authorization approach. The next steps for authorization of a consent or payment depend on this decision. Additionally some ASPSPs have implemented a standard protocol with some deviations which may result in slightly different flows as well.

In order to inform the Initiating Party on the next request required for an authorization the links section provides the corresponding links. If a redirection of the PSU is required for example, the corresponding URL for that redirection is given in the link called RedirectUrl. In case of Decoupled Approach the PSU needs to be identified to the ASPSP for enabling him to send out a Push Notification to a mobile device for example. In this case the PostIdentificationForDecoupled is given in the response.

In the description of the response to the different API requests all possible links that may appear in the links section for that API are listed. Depending on the actual situation one or more links might be included in the response.

The URLs given in the links section are provided as complete ones including the domain name and query parameters if required. An example for links with query parameters are paginated responses where the query parameter allows to address the first, next, previous or last page.

Error Response

If a request cannot be executed successfully an error response is given. The structure of error responses is the same for all APIs. Additional to the standard HTTP Status a body is provided giving more detailed information on the error. The link is provided in the error response for future use and is currently not filled for any error response.

Mult.

Name

Comments

Type

[1..1]

Code

The Error code

String

[1..1]

Message

The description of the error. In a human readable form.

String

[0..1]

Details

Details of the error which could be useful for a developer

String

[0..1]

Link

 

Group

[1..1]

+ Href

URL

String

 

Retries

  • Transaction initiation: In case of receipt of a non-deterministic failure (timeout or 5xx), parties SHOULD retry the POST /payments API once.

    • When after this retry a second non-deterministic failure (timeout or 5xx) is received, this SHOULD be considered and communicated as a deterministic failure.

  • Transaction callback: The Open Banking Service will attempt to perform incremental retries of a callback up to 24 hours if it does not receive a response within 8 seconds and/or receives a different response code than 200 OK, 202 ACCEPTED or 204 NO CONTENT to the initial callback. The retries follow a fixed schedule that are defined in the API specifications.

Enable "on this page" menu on doc section
On