This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Payment Initiation Service Provider Flow v1.3

Owned by Former user (Deleted)
Last updated: Oct 15, 2020 by Former user (Deleted)
17 min read

This document explains the flow of events related to the Payment Information Service (PIS) that a Payment Initiation Service Provider (PISP) tries. For the Berlin specific solution, the PIS is exposed as an API resource in NextGenPSD2XS2AFramework - 1.3.3 of WSO2 Open Banking. In the Payment Information Service;

  1. PISP initiates a payment submission on behalf of Payment Service Users (PSUs).
  2. PSU authorises the payment-initiation and payment-cancellation.

Before you begin,

You need to deploy the  Payments  API in the <WSO2_OB_APIM_HOME>/repository/resources/finance/apis/berlin-group.org/PSD2API_1.3.3/psd2-api_1.3.3_20190412.yaml file Click here to see how to deploy APIs for WSO2 Open Banking Berlin.

Users can test the PISP flow in WSO2 Open Banking using the following steps that are described below.

Step 1 - Sign up as a TPP

In this step, the TPP registers its TPP application in WSO2 API store.

 Click here to see how it is done...

  1. Navigate to the API Store at https://<WSO2_OB_APIM_HOST>:9443/store.

  2. Select Sign-up that is on the top left corner of the homepage.

  3. Provide the requested details on the Sign Up page.

     Click here for more information..

    a. Generic details:

    Field

    Description

    Username/Email

    The username/email that the TPP uses to sign in to the API Store.

    Password

    The password that the TPP uses to sign in to the API Store.

    Retype Password

    This is to prevent the TPP from accidentally setting an incorrect password.

    Last Name

    This is the last name of the TPP.

    First Name

    This is the first name of the TPP.


    b. Company details:

    Field

    Description

    Legal Entity Name

    The official name of the TPP.

    Country of Registration

    The country in which the TPP is registered.

    Legal Identifier Number (LEI)

    This identifies the TPP.

    Company Register

    The organization that registered the TPP.

    Company Registration Number

    Identifier issued at the TPP registration.

    Address Line 1

    Address of the TPP.

    Address Line 2

    Address of the TPP.

    City

    City in which the TPP is located.

    Postal Code

    Postal code of the geographical location of the TPP.

    Country

    The country in which the TPP is located.


    c. Competent authority registration details:

    Field

    Description

    Competent Authority

    The regulatory body that authorises and supervises the open banking services delivered by the TPP.

    Competent Authority Country

    Country of the competent authority that authorised the TPP to provide open banking services.

    Competent Authority Registration Number

    The registration number issued by the Competent Authority to the TPP.

    URL of the Competent Authority Register Page

    URL of the page that has the list of organizations authorised by the competent authority.

    Open Banking Roles

    Captures the open banking roles the TPP is willing to take up:

    • Account Information Service Provider: An Account Information Service Provider (AISP) provides an aggregated view of all the accounts and past transactions that a customer has with different banks. To provide this view to the customer, the AISP should have authorisation from the customer to view the corresponding transaction and balance information of all the accounts. The AISPs can also provide the facility to analyze the customer's spending patterns, expenses, and financial needs. Unlike a PISP, an AISP cannot transfer funds from a account.

    • Initiation Service Provider: A Initiation Service Provider (PISP) initiates credit transfers on behalf of a bank's customer.

    After selecting the TPP, indicate whether the TPP is authorised by a competent authority to provide the services of the selected roles.

    If the TPP is not yet registered to provide the services of the selected roles, indicate whether the TPP has applied for registration or not.

  4. Read terms and conditions. Click the checkbox to agree to the terms and conditions.

  5. Click Sign Up. A request to approve the TPP sign up is now sent to the Approver users.


Step 2 - Approve the TPP

Now that you have signed up as a TPP, an admin who overlooks all TPP sign-up forms must approve it. 


It is not mandatory to include the approval step for approving the TPP. In order to add this step, you need to configure workflows in the WSO2 Open Banking solution. For more information on configuring workflows, see /wiki/spaces/OB150/pages/27919307.  

 Click here to see how it is done...

  1. Sign in to the WSO2 Open Banking API Manager Admin portal as an Approver at https://<WSO2_OB_APIM_HOST>:9443/admin.

  2. Locate the approval request and click Assign To Me.

  3. Click Start to start the approval process.
  4. Select Approve then Complete.

Now the TPP can sign in to the API store. 

Step 3 - Sign in to the API store as the TPP

Users can sign in to the API store and proceed with the steps mentioned below.

 Click here to see how it is done...

  1. Sign in to the API Store as the TPP at https://<WSO2_OB_APIM_HOST>:9443/store.

  2. Click Sign In and navigate to the Sign In page.

  3. Enter the username and the password you entered when signing up as a TPP.

  4. Click Sign In . 

The homepage of the API store is now displayed along with the APIs.

Step 4 - Create an application

The TPP needs to create an application in WSO2 API store that represents its TPP application. The application created via WSO2 API store allows to observe statistics of APIs, subscribe to APIs, and generate keys for the subscribed APIs.

 Click here to see how it is done...

  1. In the API store, click Applications.

  2. Click Add Application .

  3. Enter application details.

    Field

    Description

    Name

    Application name.

    Per Token Quota

    Determines the maximum number of API requests accepted within a given duration.

    Description

    This describes the purpose of the application.

  4. Click Add. 

An application can be used to subscribe to multiple APIs. See Accounts Information Service Provider Flow v1.3#Subscribe to an API for the instructions.

Step 5 - Subscribe to API

The TPP user needs to subscribe to the NextGenPSD2XS2AFramework - 1.3.3 API in order to access API resources. Once subscribed to the NextGenPSD2XS2AFramework - 1.3.3 API, the users are subscribing to all the supported services of Accounts, Payments and Confirmation of Funds API resources. 


 Click here to see how it is done...

  1. In the API store, Click APIs.

  2. Select the NextGenPSD2XS2AFramework-1.3.3 API.

  3. In the right top corner, select the application you created from the dropdown list under Applications.

  4. Set the Tiers to Unlimited.

  5. Click Subscribe .

Now that you have subscribed to the API, you can generate keys and invoke the API.

Step 6 - Create and upload certificates

The TPP user needs to obtain an eIDAS certificate from a Qualified Trust Service Provider (QTSP) that validates whether the TPP is registered in a governing entity. It is verified in the TPP Onboarding process. 

For testing purposes, WSO2 Open Banking provides a sample eIDAS certificate. To download the sample eIDAS certificate, click here. 

Upload the downloaded sample eIDAS certificate to the client trust stores of WSO2 OB APIM and WSO2 OB KM.

    • Locate the client trust stores in WSO2 OB APIM and WSO2 OB KM in the following directory paths:

      • <WSO2_OB_APIM>/repository/resources/security/client-truststore.jks
      • <WSO2_OB_KM>/repository/resources/security/client-truststore.jks

  • Use the following command to upload the certificate:

    keytool -import -trustcacerts -alias <<alias>> -file <<path_to_sample_eIDAS_cert>> -keystore <<path_to_truststore>> -storepass wso2carbon -noprompt

Step 7 - Generate keys

The TPP user requests client ID and client secret to access the subscribed APIs.

 Click here to see how it is done...

  1. Sign in to the API store as the TPP user and click either of the following on the Applications tab.

    1. Production Keys: Generates access tokens in the production environment.

    2. Sandbox Keys : Generates access tokens in the sandbox environment.

  2. Provide the requested information as defined below:  

    Field

    Description

    Grant Types

    These determine the credentials that are used to generate the access token.

    • Refresh Token: This is to renew an expired access token.

    • Client Credential: This relates to the client credentials grant type and is applicable when consuming the API as an application.

    • Code: This relates to the authorisation code grant type and is applicable when consuming the API as a user.

    Client ID

    OrganizationIdentifier as provided in the EIDAS certificate. The organizationIdentifier attribute contains information using the following structure in the presented order:

    • PSD as the 3-character legal person identity type reference;

    • 2-character ISO 3166 country code representing the NCA country;

    • hyphen-minus (-)

    • 2-8 character NCA identifier (A-Z upper case only, no separator)

    • hyphen-minus (-)

    • PSP (Payment Service Provider) identifier (authorisation number as specified by NCA)

    Callback URL

    This is the URL used by the Account Information Service Provider (AISP) / Payment Initiation Service Provider (PISP) to receive the authorisation code sent from the Account Servicing Payment Service Provider (ASPSP), e.g: bank. The authorisation code can be used later to generate an OAuth2 access token.

    Application Certificate

    According to the Berlin specification, the TPPs require to upload eIDAS (electronic identification and trust services) certificate when generating the keys. If you do not have an eIDAS certificate, you can create an X.509 certificate to generate the keys.

     Click here to see how it is done...

    1. A keystore file is used to store the trusted certificates of the TPP in the WSO2 Open Banking solution. Use the commands given below in a command-line interface in order to create a keystore file as the TPP.

      Make sure to update the following placeholders:

      <alias>A preferred alias for the keystore file.
      <filename>A preferred name for the keystore file.
      keytool -genkey -alias <alias> -keyalg RSA -keystore <filename>.jks

      During the command execution, the TPP user requires to;


      1. Set a password for the keystore.
      2. Provide information, acquired when registering with a governing entity.
      3. Set a password for user-defined alias (<alias>).

    2. Convert the keystore from the .jks format to .PKCS12.  Make sure to update the following placeholders:

      <keyStoreName>This is the name of the <filename>, given above.
      <PKCS12FileName>This is the name of the keystore in the .PKCS12 format.
      keytool -importkeystore -srckeystore <keystoreStoreName>.jks -destkeystore <PKCS12FileName>.p12 -deststoretype PKCS12

      During the command execution, the TPP user requires to;

      1. Set a password for the destination keystore.
      2. Enter the source keystore password, as defined in the above step.

    3. Create the application certificate (.pem) file in the PKCS12 format using the keystore. e.g: tpp.p12.

      Make sure to update the following placeholders:

      <PKCS12FileName>This is the name of the keystore in the PKCS12 format, as mentioned above for the <PKCS12FileName>.
      <PEMFileName>This is the name of the application certificate that is created in the .pem format. 
      openssl pkcs12 -in <PKCS12FileName>.p12 -nokeys -out <PEMFileName>.pem

      During the command execution, the TPP user requires to;

      1. Set a password to import the .pem file.

    You can now upload the eIDAS certificate or X.509 certificate by clicking Choose Files.

    Make sure to add only the content between BEGIN CERTIFICATE and END CERTIFICATE strings from the certificate file.

  3. Click Request Access if you are generating production keys. If workflows are configured in the solution, it sends a request to Approver user to approve the token generation. Otherwise, it generates consumer key and consumer secret.

  4. Click Generate Keys if you are generating sandbox keys. It generates consumer key and consumer secret.

  5. Now, you have generated the consumer key and consumer secret successfully. Navigate to the first point of Authorization code that appears after the keys on the same page.

    This is the URL that the TPP must send to the PSU. This URL points to a web interface with permissions that the TPP is seeking from the PSU. A sample web interface looks as follows:


Step 8 - Approve Production Key generation

This step includes instructions to an Approver user to review and approve a request to generate production keys for an application.

It is not mandatory to include the approval step for the Production Key generation. In order to add this step, you need to configure workflows in the WSO2 Open Banking solution. For more information on configuring workflows, see /wiki/spaces/OB150/pages/27919307.

 Click here to see how it is done...

  1. Sign in to the WSO2 Open Banking API Manager Admin portal as an Approver at https://<WSO2_OB_APIM_HOST>:9443/admin.

  2. Click Tasks and then the Application Registration .

  3. Locate the approval request and click Assign To Me .

  4. Click Start to start the approval process.
  5. Select Approve and then click Complete.
  6. Navigate back to the API Store and click Applications.
  7. On the Applications tab, Click View of the application that you created.
  8. Click Production Keys tab to find the generated keys.

  9. It includes the consumer key and consumer secret as follows:

    Note that consumer key is used as client ID in the below steps.


Step 9 - Generate application access token

When invoking APIs, application access tokens must be generated using the client credential grant type. The generated application access token is used to invoke the NextGenPSD2XS2AFramework-1.3.3 API.

 Click here to see how it is done...

  1. Generate the client assertion by signing the following JSON payload using the supported algorithms. The supported algorithms are RS256 and PS256.

    The value of the aud claim should contain the same value as the Identity Provider Entity ID.

     Click here to view the Identity Provider Entity ID:
    1. Sign in to the Identity and Access Management console at  https://localhost:9446/carbon . 
    2. In the Main menu, go to Home > Identity > Identity Providers > Resident.
    3. View the value in Resident Identity Provider > Inbound Authentication Configuration > OAuth2/OpenID Connect Configuration > Identity Provider Entity ID. By default this value is set to  https://localhost:8243/token .

  2. Run the following cURL command in a command prompt to generate the access token. Update the placeholders with the relevant values.

    curl -v POST \
 https://<WSO2_OB_APIM_HOST>:8243/token \
 --cert <PUBLIC_KEY_FILE_PATH> --key <PRIVATE_KEY_FILE_PATH> \
 -H "Content-Type: application/x-www-form-urlencoded;charset=ISO-8859-1" \
 -d "client_id=<CLIENT_ID>&grant_type=client_credentials&scope=payments+openid&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=<CLIENT_ASSERTION_JWT>&redirect_uri=<APPLICATION_CALLBACK_URL>" 

    The access token is now generated.

    You can use the same cURL command to regenerate the access token.

Step 10 - Initiate a payment

In this step, the TPP creates a request to get the consent of the PSU before a transaction is executed.

 Click here to see how it is done...

POST /{payment-service}/{payment-product} - Initiate payment request

The TPP initiates a payment request to the ASPSP. The request body can be sent as a JSON body or pain.001 XML. The type of the request body is determined by the payment-service type and payment-product type.

 Click here to see how it is done...
  1. Below mentioned are the available values for payment-service and payment-product types:

    Payment service type:

      1. Single payment
      2. Bulk payment
      3. Periodic payment

    Payment product type:

      1. sepa-credit-transfers
      2. instant-sepa-credit-transfers
      3. target-2-payments
      4. cross-border-credit-transfers

    To support a custom payment product

    By default, the solution supports the standard payment products as given in the Berlin swagger file. To support a custom payment product, the ASPSP needs to update the swagger file and republish the API as follows:

    1. Sign in to the API Publisher at https://<WSO2_OB_APIM_HOST>:9443/publisher using the credentials of a user, whose role is an API Publisher.

    2. Select the NextGenPSD2XS2AFramework - 1.3.3 API and click Edit API.

    3. Click the Edit Source button.
    4. Edit the swagger file as given below:

      1. Search for the /{payment-service}/{payment-product} path.
        Under the name: payment-product tag, add the name of the custom payment product to the enum list.

        - name: payment-product
          in: path
          description: "description"
          required: true
          schema:
            type: string
            enum:
              - sepa-credit-transfers
              - instant-sepa-credit-transfers
              - target-2-payments
              - cross-border-credit-transfers
              - new-payment-product-name
              - pain.001-sepa-credit-transfers
              - pain.001-instant-sepa-credit-transfers
              - pain.001-target-2-payments
              - pain.001-cross-border-credit-transfers

      2. Search the swagger file for paymentProduct, under the parameters section. Add the name of the payment product as shown in the step above.

        To remove support for a certain payment product that is supported by the solution by default, remove the name of the particular payment products from the enum values under the sections discussed in step i and ii.

    5. Click Apply Changes to save the changes and go back to the Design phase. 
    6. Scroll down and click Save.

    7. Click Next: Implement > Next: Manage and Save and Publish.

  2. According to the payment-service and payment-product chose, the request body changes as follows:

    • Use the following sample cURL command to execute the request:

      curl POST \
 https://<WSO2_OB_APIM>:8243/xs2a/1.3.3/payments/instant-sepa-credit-transfers \ 
 -H 'X-Request-ID=d010ca2d-961e-4dbb-9bad-3b8d0cfd8ae1' \
 -H 'PSU-IP-Address=192.168.1.100' \
 -H 'accept=application/json' \
 -H 'Authorization=Bearer <APPLICATION_ACCESS_TOKEN>' \
 -H 'PSU-ID=admin@wso2.com@carbon.super' \
 -H 'PSU-ID-Type=email' \  
 -H 'Digest=SHA-256=AIJd+//KvIBFGRrzvSHFoJeWDnAnUKoHrmK5C+08bSbS' \
 -H 'Signature=keyId='SN=98825469188382671148567247746131044682,CA=2.5.4.97=#130e4e545244452d4852423734333436,CN=D-TRUST Test CA 2-1 2018,O=D-Trust GmbH,C=DE',algorithm='rsa-sha256', headers='digest x-request-id date psu-id',signature=DquAr...tQrZRfg==' \
 -H 'TPP-Signature-Certificate=MIIIRj...E7JVAJU6BO+hH7q+GXJg==' \
 -H 'Content-Type=application/json; charset=UTF-8' \
 -d '
 {
    "instructedAmount":{
       "currency":"EUR",
       "amount":"123.50"
    },
    "debtorAccount":{
       "iban":"DE12345678901234567890"
    },
    "creditorName":"Merchant123",
    "creditorAccount":{
       "iban":"DE98765432109876543210"
    },
    "remittanceInformationUnstructured":"Ref Number Merchant"
 }'

      The header parameter, TPP-Explicit-Authorisation-Preferred returns a boolean value.

      falseIf "TPP-Explicit-Authorisation-Preferred: false", the authorisation flow is implicit. When the authorisation is implicit, The TPP generates the authorisation URL to authorise a particular payment. The TPP uses the well-known URL in the response of the payment initiation.
      trueIf "TPP-Explicit-Authorisation-Preferred: true" , the authorisation flow is explicit. When the authorisation is explicit, the TPP generates the authorisation URL to authorise a particular payment. The TPP uses the well-known URL upon initiating an authorisation for payment when invoking POST /{payment-service}/{payment-product}/{paymentId}/authorisations API resource.

      For more information on authorisation, see Authorise the payment.

  3. The TPP implicitly generates the authorisation URL using the well-known URL under scaOAuth link in the response. See Step 11 - Authorise the payment for more information on the authorisation URL.

    Sample response for the payment-initiation request differs according to the chosen payment-service as follows:

Users can call the following API resources once the PSU initiates the payment.

 Click here to find the consent related API calls that can be invoked after the paymen-initiation...

GET /{payment-service}/{payment-product}/{paymentId} - Get payment information

The TPP invokes this API resource to get the content of a payment object. A sample request and response are given below:

GET /{payment-service}/{payment-product}/{paymentId}/status - Payment Initiation status request

The TPP checks the status of a particular payment-initiation request using the sample request given below:



Step 11 - Authorise the payment

WSO2 Open Banking v1.4.0 for Berlin Implementation supports both implicit and explicit authorization flows for transaction authorization. In both cases, TPP generates the authorization URL using the well-known configuration that is received from the ASPSP as scaOAuth link in the response.

Implicit authorisation

In this approach, ASPSP creates authorization sub resources for a particular transaction after the payment consent is received and replies with the well-known configuration of the Key Manager (WSO2_OB_KM) in the links section of the response, generated for the payment-initiation request. Then the TPP generates the authorization URL using the well-known URL. The PSU goes through the authorisation flow with that authorisation URL.

Explicit authorisation

In this approach, the TPP initiates the authorization flow by invoking POST /{payment-service}/{payment-product}/{paymentId}/authorisations API resource. At this point, the ASPSP creates authorization sub resources for the transaction and reply back with the well-known configuration of the Key Manager ( WSO2_OB_KM ) in the links section of the response. Then the TPP has to generate the authorization URL using which later the PSU uses to go through the authorization flow.

 Click here to see how it is done...
  1. The TPP invokes POST /{payment-service}/{payment-product}/{paymentId}/authorisations API resource to authorise a particular payment.
  2. The TPP generates the authorisation URL using the well-known URL under scaOAuth link in the response.

POST /{payment-service}/{payment-product}/{paymentId}/authorisations - Initiate an authorisation for a payment

The TPP can authorise the particular payment using the sample request given below. In this case, the TPP is creating an authorisation subresource, that the PSU can use to authorise.

Users can call the following API resources once the PSU authorises the payment.

 Click here to find the consent related API calls that can be invoked after the paymen-initiation...

GET /{payment-service}/{payment-product}/{paymentId}/authorisations - Get payment authorisation subresource's request

The TPP can invoke this API resource to get all the authorisation sub-resources that have been created. Sample request and response looks as follows:

GET /{payment-service}/{payment-product}/{paymentId}/authorisations/{authorisationId} - Read the SCA status of the authorisation request

TPP can check the SCA status of a particular subresource that was created when authorising a payment. Sample request and response look as follows:

  • Authorisation URL

The TPP uses the well-known URL regardless of the authorisation followed (Implicit/Explicit) to authorise payments as below:

 Click here to see how it is done...

  • The open banking solution sends the authorisation URL that was generated under scaOAuth link of the response. The response the TPP uses differs according to the authorisation as follows:

    Implicit authorisationThe response the TPP gets when initiating a payment.
    Explicit authorisationThe response the TPP gets when invoking POST /{payment-service}/{payment-product}/{paymentId}/authorisations API resource.

    A sample well-known URL under scaOAuth parameter looks as below:

    {
	"scaOAuth":
		{
		"href":"https://<WSO2_OB_APIM_HOST>:8243/.well-known/openid-configuration"
		}
	}

  • Paste the authorisation URL in the browser. The format for the authorisation URL looks as follows:

    Sample URL Format
    https://<WSO2_OB_APIM_HOST>:8243/authorize/?scope=<YOUR_SCOPES>&response_type=code&redirect_uri=<REDIRECT_URI>&state=<DYNAMICALLY_SET_VALUE>&code_challenge_method=<YOUR_CODE_CHALLENGE_METHOD>&client_id=<ORGANIZATION_ID>&code_challenge=<YOUR_CODE_CHALLENGE>

    Use the following table to find the descriptions for the parameters:

    ParameterDescription

    scope

    		This is the reference to the consent resource for account access. It is in the form of pis:<consentId>
    response_typecode is recommended.
    redirect_uriThe TPP's URI that the OAuth2 server redirects the PSU's user agent after the authorisation.
    statePrevents XSRF attacks by TPP setting a dynamic value.

    code_challenge_method

    		Code verifier transformation method. It is recommended in the Berlin specification to use S256.
    client_idAs provided in the eIDAS certificate, the organization_Identifier must contain the following information in it: - "PSD" as 3 character legal person identity type reference - 2 character ISO 3166 country code representing the NCA country - hyphen-minus "-" and - 2-8 character NCA identifier (A-Z uppercase only, no separator - hyphen-minus "-" - PSP identifier (authorization number as specified by NCA)

    code_challenge

    		This is used to avoid code injection attacks using the PKCE challenge in the cryptographic RFC 7636. Go to https://tools.ietf.org/html/rfc7636 for more information on the cryptographic RFC 7636.

    The authorisation URL points to a web interface as follows:

  • Upon the user approving or denying the payment consent, the user can invoke consent/authorization API resource of the authentication endpoint. By invoking this API resource, the user retrieves the consent approval/denial, that is displayed on the consent web-app.

Step 12 - Cancel a payment

The cancellation of payment can happen in the following ways:

  • TPP directly cancels a payment.
  • TPP sends a payment cancellation request and based on the ASPSP requirements the PSU then authorizes the cancellation.

To define the cancellation method, configure the AuthorizeCancellation property in <WSO2_OB_KM_HOME>/repository/conf/finance/open-banking.xml.

  • If the value is set to true, to cancel the payment, PSU authorization is required.

  • If set to false, the TPP is able to cancel the payment directly.

    <Berlin>
	<AuthorizeCancellation>false</AuthorizeCancellation>
</Berlin>
The TPP initiates the cancellation of the payment request as follows:


 Click here to see how it is done...

DELETE /{payment-service}/{payment-product}/{paymentId} - Payment cancellation

The sample request and response looks as follows for the payment cancellation:

Authorise a cancellation of payment

The TPP can authorise a cancellation for an already cancelled payment.

 Click here to see how it is done...

POST /{payment-service}/{payment-product}/{paymentId}/cancellation-authorisations - Start the authorisation process for the cancellation of the addressed payment

Creates an authorisation subresource and start the authorisation process of the cancellation of the addressed payment. Sample request and response are as follows:

If the PSU authorisation is required, the TPP calls the following API resources once the PSU authorises the cancellation of a payment.

 Click here to see how it is done...

GET /{payment-service}/{payment-product}/{paymentId}/cancellation-authorisations - Retrieves a list of authorised cancellation subresources

The TPP invokes this API resource to retrieve a list authorised cancellation subresources.

GET /{payment-service}/{payment-product}/{paymentId}/cancellation-authorisations/{cancellationId} - Reads the SCA status of the payment cancellation's authorisation resource

The TPP invokes this API resource to check the SCA status of a payment cancellation's authorisation subresource.