...
Multiexcerpt | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Step 1 - Sign up as a TPPA Third-Party Provider(TPP), is an authorized third-party that allows merchants to accept a wide variety of payments through a single channel/third-party application, and manage the entire payment flow from start to finish. For more information on the role, see The TPP needs to register its Payment Initiation Service Provider (PISP) application in WSO2 API store in order to access the data.
Step 2 - Approve the TPPNow 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.
Now the TPP can sign in to the API store. Step 3 - Sign in to the API store as the TPPUsers can sign in to the API store and proceed with the steps mentioned below.
The homepage of the API store is now displayed along with the APIs. Step 4 - Create an applicationThe TPP with a P
An application can be used to subscribe to multiple APIs. See for the instructions. Step 5 - Subscribe to APIThe TPP user needs to subscribe to the
Now that you have subscribed to the API, generate access tokens and invoke the API. Step 6 - Create and upload certificatesThe TPP user needs to create certificates to validate whether the TPP is registered in a governing governing entity. Click here to see how it is done...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 a TPP. Make sure to update the following placeholders: <alias> A preferred alias for the keystore file. | <filename> A preferred name for the keystore file. | During the command execution, the TPP user requires to; It is verified in the TPP Onboarding process. For example, in Dynamic Client Registration, the TPP is dynamically registered with ASPSPs when the client sends a registration request with its metadata. Therefore, the ASPSP is required to upload the root and issuer certificates obtained from Open Banking Implementation Entity. For more information, see You can also create a self-signed certificate the following instructions given below and try out the API flow: When you are using self-signed certificates, make sure to disable the certificate revocation validation:
In order to use self-signed certificates as mentioned in the below steps, disable the
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. | During the command execution, the TPP user requires to; Set a password to import the .pem file.
Once you create a self-signed certificate, upload it to the client trust stores of WSO2 OB APIM and WSO2 OB KM.
Step 7 - Generate keys The TPP user requires a Client ID(Consumer Key) and a Client Secret(Consumer Secret) to access the subscribed APIs.
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 appli 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.
Step 9 - Generate application access tokenWhen invoking APIs in the payment flow, application access tokens must be generated using the client credential grant type. The generated application access token is used to invoke the PaymentInitiationAPI - v3.1 API. You can skip the above steps and use
|
...
Expand | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
POST /domestic-payment-consentsThis endpoint allows the PISP to ask an ASPSP to create a new domestic-payment-consent resource. The ASPSP creates the domestic-payment-consent resource and responds with a unique
GET /domestic-payment-consents/{ConsentId}A PISP is able to retrieve a payment consent resource that they have created to check its status. The PISP must have an access token issued by the ASPSP using a client credentials grant.
|
...
Expand | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
POST /domestic-paymentsThe PISP must ensure that the The response contains
|
...
Expand | |||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||
GET /domestic-payment-consents/{ConsentId}/funds-confirmationThe API endpoint allows the PISP to ask an ASPSP to confirm funds on a domestic-payment-consent resource. An ASPSP can only respond to a funds confirmation request if the domestic-payment-consent resource has an Authorised status. The confirmation of funds requests do not affect the status of the domestic-payment-consent resource.
|
Expand | |||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||
GET /domestic-payments/{DomesticPaymentId}The PISP retrieves the domestic-payment resource to check its status.
|