Explicit PreAuth (in Embedded) Payment with Embedded Authorisation

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

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

{ 
"AspspId": "<ASPSP ID>",
"Name": [<ASPSP Name],
"CountryCode": "XX",
"CategoryLabel": [Retail],
"Details": [{ 
                "Api": "POST /pre-authentication",                
                "Type": "SUPPORTED",
                "ProtocolVersion": "XX_V_1_1"           
            },
            {
                "Api": "POST /payments",                
                "FieldName": "UsePreAuthentication",
                "Type": "MANDATORY",
                "Value": "true",
                "ProtocolVersion": "XX_V_1_1"                  
            },
            {
                :
                :
            },
           ],
"Options": [{
                "Key1": "PREAUTH_MANDATORY",
                "Value": "1",
                "Level": "INFORMATIONAL"
            },
            { 
                "Key1": "PREAUTH_EXPLICIT_REQUIRED",
                "Value": "1",
                "Level": "CRITICAL"
            },
            {
                "Key1": "REACH_ASPSP_FOR_PRE_AUTH",
                "Value": "1",
                "Level": "CRITICAL"
            }
           ],
"BIC": "XXPIS001"
}

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": "XX_V_1_1"    

In POST /payments request, “UsePreAuthentication” flag value send to be “true” to reuse the pre-authentication token for further payment related requests.

"Api": "POST /payments",                
"FieldName": "UsePreAuthentication",
"Type": "MANDATORY",
"Value": "true",
"ProtocolVersion": "XX_V_1_1"        

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"

In example, the given ASPSP, Pre-authentication has to be done explicitly by the POST /pre-authentication endpoint because the value of PREAUTH_EXPLICIT_REQUIRED option is set to 1.

"Key1": "PREAUTH_EXPLICIT_REQUIRED",
"Value": "1",
"Level": "CRITICAL"

In example, REACH_ASPSP_FOR_PRE_AUTH flag indicate that an explicit preAuth request must be sent to the ASPSP in the TPP preAuth API. Otherwise, the TPP preAuth API handles this request only internally.

"Key1": "REACH_ASPSP_FOR_PRE_AUTH",
"Value": "1",
"Level": "CRITICAL"

 

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 :

---