ob-p-a2a-s3
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 :
