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. User can get the ASPSP ID for appropriate scenario from "Scenario Guideline" page or from the list of "Payment Initiation Scenarios" page.
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 :
