-
AISP
-
Forwarding the PSU consent (AISP)
-
Retrieval of an account balances report (AISP)
-
Retrieval of an account transaction set (AISP)
-
Retrieval of the PSU accounts (AISP)
-
Retrieval of the identity of the end-user (AISP)
-
Retrieval of the trusted beneficiaries list (AISP)
-
Forwarding the PSU consent (AISP)
-
Bank Accounts (Dynamic Endpoint)
-
CBPII
-
Dynamic Resource Doc
-
PISP
-
Confirmation of a payment request or a modification request (PISP)
-
Modification of a Payment/Transfer Request (PISP)
-
Payment request initiation (PISP)
-
Retrieval of a payment request (PISP)
-
Confirmation of a payment request or a modification request (PISP)
-
_Covid APIDays
-
Create new Covid APIDays
-
Delete Covid APIDays by id
-
Get Covid APIDays List
-
Get Covid APIDays by id
-
Update Covid APIDays
-
Create new Covid APIDays
-
_Customer Cars
-
Create new Customer Cars
-
Delete Customer Cars by id
-
Get Customer Cars List
-
Get Customer Cars by id
-
Update Customer Cars
-
Create new Customer Cars
-
_D Entity1(gh.29.uk)
-
_Fish Port
-
_Foo Bar
-
_Insurance Policy(gh.29.uk)
-
Create new Insurance Policy
-
Delete Insurance Policy by id
-
Get Insurance Policy List
-
Get Insurance Policy by id
-
Update Insurance Policy
-
Create new Insurance Policy
-
_Insurance Premium(gh.29.uk)
-
Create new Insurance Premium
-
Delete Insurance Premium by id
-
Get Insurance Premium List
-
Get Insurance Premium by id
-
Update Insurance Premium
-
Create new Insurance Premium
-
_March Hare(gh.29.uk)
-
Create new March Hare
-
Delete March Hare by id
-
Get March Hare List
-
Get March Hare by id
-
Update March Hare
-
Create new March Hare
-
_Obp Activity(obp.testing.01)
-
Create new Obp Activity
-
Delete Obp Activity by id
-
Get Obp Activity List
-
Get Obp Activity by id
-
Update Obp Activity
-
Create new Obp Activity
-
_Odometer(gh.29.uk)
-
_Simon Covid
-
Create new Simon Covid
-
Delete Simon Covid by id
-
Get Simon Covid List
-
Get Simon Covid by id
-
Update Simon Covid
-
Create new Simon Covid
-
_Sustrans
-
_Test Daniel707
-
Create new My Test Daniel707
-
Create new Test Daniel707
-
Delete My Test Daniel707 by id
-
Delete Test Daniel707 by id
-
Get My Test Daniel707 List
-
Get My Test Daniel707 by id
-
Get Test Daniel707 List
-
Get Test Daniel707 by id
-
Update My Test Daniel707
-
Update Test Daniel707
-
Create new My Test Daniel707
-
_Test1
v1.4 (89 APIs)
Confirmation of a payment request or a modification request (PISP)
NOTE: This endpoint currently only returns example data.
### Description
The PISP confirms one of the following requests
- payment request on behalf of a merchant
- transfer request on behalf of the account's owner
- standing-order request on behalf of the account's owner
The ASPSP answers with a status of the relevant request and the subsequent Credit Transfer.
Prerequisites
- The TPP has been registered by the Registration Authority for the PISP role
- The TPP was provided with an OAUTH2 "Client Credential" access token by the ASPSP (cf. § 3.4.3).
- The TPP has previously posted a Request which has been saved by the ASPSP (cf. § 4.5.3)
- The TPP and the ASPSP have successfully processed a mutual check and authentication
- The TPP has presented its "OAUTH2 Client Credential" access token
Business flow
Once the PSU has been authenticated, it is the due to the PISP to confirm the Request to the ASPSP in order to complete the process flow.
In REDIRECT and DECOUPLED approach, this confirmation is not a prerequisite to the execution of the Credit Transfer.
User Authentication is Required. The User must be logged in. The Application must also be authenticated.
URL Parameters:
PAYMENTREQUESTRESOURCEID: PAYMENTREQUESTRESOURCEID
JSON request body fields:
JSON response body fields:
- Required JSON Validation: No
- Allowed Authentication Types: Not set
- OBP-20001: User not logged in. Authentication is required!
- OBP-50000: Unknown Error.
Modification of a Payment/Transfer Request (PISP)
NOTE: This endpoint currently only returns example data.
### Description
The PISP sent a Payment/Transfer Request through a POST command.
The ASPSP registered the Payment/Transfer Request, updated if necessary the relevant identifiers in order to avoid duplicates and returned the location of the updated Request.
The PISP got the Payment/Transfer Request that has been updated with the resource identifiers, and eventually the status of the Payment/Transfer Request and the status of the subsequent credit transfer.
The PISP request for the payment cancellation (global cancellation) or for some payment instructions cancellation (partial cancellation)
No other modification of the Payment/Transfer Request is allowed.
Prerequisites
- The TPP was registered by the Registration Authority for the PISP role
- The TPP was provided with an OAUTH2 "Client Credential" access token by the ASPSP (cf. § 3.4.3).
- The TPP previously posted a Payment/Transfer Request which was saved by the ASPSP (cf. § 4.5.3)
- The TPP and the ASPSP successfully processed a mutual check and authentication
- The TPP presented its "OAUTH2 Client Credential" access token.
- The TPP presented the payment/transfer request.
- The PSU was successfully authenticated.
Business flow
the following cases can be applied:
- Case of a payment with multiple instructions or a standing order, the PISP asks to cancel the whole Payment/Transfer or Standing Order Request including all non-executed payment instructions by setting the [paymentInformationStatus] to "RJCT" and the relevant [statusReasonInformation] to "DS02" at payment level.
- Case of a payment with multiple instructions, the PISP asks to cancel one or several payment instructions by setting the [transactionStatus] to "RJCT" and the relevant [statusReasonInformation] to "DS02" at each relevant instruction level.
Since the modification request needs a PSU authentication before committing, the modification request includes:
- The specification of the authentication approaches that are supported by the PISP (any combination of "REDIRECT", "EMBEDDED" and "DECOUPLED" values).
- In case of possible REDIRECT or DECOUPLED authentication approach, one or two call-back URLs to be used by the ASPSP at the finalisation of the authentication and consent process :
- In case of possible "EMBEDDED" or "DECOUPLED" approaches, a PSU identifier that can be processed by the ASPSP for PSU recognition.
-
The ASPSP saves the updated Payment/Transfer Request and answers to the PISP. The answer embeds
User Authentication is Required. The User must be logged in. The Application must also be authenticated.
URL Parameters:
PAYMENTREQUESTRESOURCEID: PAYMENTREQUESTRESOURCEID
JSON response body fields:
{
"appliedAuthenticationApproach":{
"appliedAuthenticationApproach":"REDIRECT"
},
"_links":{
"consentApproval":{
"href":"https://psd2.aspsp/consent-approval"
}
}
}
- Required JSON Validation: No
- Allowed Authentication Types: Not set
- OBP-20001: User not logged in. Authentication is required!
- OBP-50000: Unknown Error.
Payment request initiation (PISP)
NOTE: This endpoint currently only returns example data.
### Description
The following use cases can be applied:
- payment request on behalf of a merchant
- transfer request on behalf of the account's owner
- standing-order request on behalf of the account's owner
Data content
A payment request or a transfer request might embed several payment instructions having
- one single execution date or multiple execution dates
- one single beneficiary or multiple beneficiaries
Having at the same time multiple beneficiaries and multiple execution date might not be a relevant business case, although it is technically allowed.
Each implementation will have to specify which business use cases are actually supported.
A standing order request must embed one single payment instruction and must address one single beneficiary.
- The beneficiary must be set at the payment level
- The standing order specific characteristics (start date, periodicity...) must be set at the instruction level
Payment request can rely for execution on different payment instruments: - SEPA Credit Transfer (SCT) - Domestic Credit Transfer in a non Euro-currency - International payment The following table indicates how to use the different fields, depending on the payment instrument:
Structure | SEPA payments | Domestic payments in non-euro currency | International payments |
PaymentTypeInformation/ InstructionPriority (payment level) | "HIGH" for high-priority SCT "NORM" for other SCT Ignored for SCTInst | "HIGH" for high-priority CT "NORM" or ignored for other CT | "HIGH" for high-priority payments "NORM" or ignored for other payments |
PaymentTypeInformation/ ServiceLevel (payment level) | "SEPA" for SCT and SCTInst | ignored | ignored |
PaymentTypeInformation/ CategoryPurpose (payment level) | "CASH" for transfer request "DVPM" for payment request on behalf of a merchant | "CORT" for generic international payments "INTC" for transfers between two branches within the same company "TREA" for treasury transfers | |
PaymentTypeInformation/ LocalInstrument (payment level) | "INST" pour les SCTInst Otherwise ignored | ignored or valued with ISO20022 external code list values | |
RequestedExecutionDate (either at payment or transaction level) | Mandatory (indicates the date on debit on the ordering party account) | ||
InstructedAmount (at each transaction level) | Mandatory | ||
ChargeBearer (at each transaction level) | "SLEV" for SCT and SCTInst | "SLEV" or "SHAR" | "CRED", "DEBT" or "SHAR" |
Purpose (at payment level) | Optional | ||
RegulatoryReportingCode (at each transaction level) | Not used | Mandatory (possibly multiple values) | |
RemittanceInformation | Optional Unstructured | ||
Debtor (at payment level) | Mandatory 2 address lines only | Mandatory 4 address lines only | |
DebtorAccount (at payment level) | Optional | Optional Account currency may be specified | |
DebtorAgent (at payment level) | Optional | ||
Creditor (either at payment or transaction level) | Mandatory 2 address lines only | ||
CreditorAccount (either at payment or transaction level) | Mandatory | Mandatory Account currency may be specified | |
CreditorAgent (either at payment or transaction level) | Optional | ||
UltimateCreditor (either at payment or transaction level) | Optional | ||
ClearingSystemId et ClearingSystemMemberId (either at payment or transaction level) | Not used | Optional |
Prerequisites for all use cases
- The TPP has been registered by the Registration Authority for the PISP role
- The TPP was provided with an OAUTH2 "Client Credential" access token by the ASPSP (cf. § 3.4.3).
- The TPP and the ASPSP have successfully processed a mutual check and authentication
- The TPP has presented its "OAUTH2 Client Credential" access token
Business flow
Payment Request use case
The PISP forwards a payment request on behalf of a merchant.
The PSU buys some goods or services on an e-commerce website held by a merchant. Among other payment method, the merchant suggests the use of a PISP service. As there is obviously a contract between the merchant and the PISP, there is no need of such a contract between the PSU and this PISP to initiate the process.
Case of the PSU that chooses to use the PISP service:
- The merchant forwards the requested payment characteristics to the PISP and redirects the PSU to the PISP portal.
- The PISP requests from the PSU which ASPSP will be used.
- The PISP prepares the Payment Request and sends this request to the ASPSP.
- The Request can embed several payment instructions having different requested execution date.
- The beneficiary, as being the merchant, is set at the payment level.
Transfer Request use case
The PISP forwards a transfer request on behalf of the owner of the account.
- The PSU provides the PISP with all information needed for the transfer.
- The PISP prepares the Transfer Request and sends this request to the relevant ASPSP that holds the debtor account.
- The Request can embed several payment instructions having different beneficiaries.
- The requested execution date, as being the same for all instructions, is set at the payment level.
Standing Order Request use case
The PISP forwards a Standing Order request on behalf of the owner of the account.
- The PSU provides the PISP with all information needed for the Standing Order.
- The PISP prepares the Standing Order Request and sends this request to the relevant ASPSP that holds the debtor account.
- The Request embeds one single payment instruction with
Authentication flows for all use cases
As the request posted by the PISP to the ASPSP needs a PSU authentication before execution, this request will include:
- The specification of the authentication approaches that are supported by the PISP (any combination of "REDIRECT", "EMBEDDED" and "DECOUPLED" values).
- In case of possible REDIRECT or DECOUPLED authentication approach, one or two call-back URLs to be used by the ASPSP at the finalisation of the authentication and consent process :
- In case of possible "EMBEDDED" or "DECOUPLED" approaches, the PSU identifier that can be processed by the ASPSP for PSU recognition must have been set within the request body [debtor] structure.
The ASPSP saves the request and answers to the PISP. The answer embeds:
- A location link of the saved Request that will be further used to retrieve the Request and its status information.
- The specification of the chosen authentication approach taking into account both the PISP and the PSU capabilities.
- In case of chosen REDIRECT authentication approach, the URL to be used by the PISP for redirecting the PSU in order to perform a authentication.
Case of the PSU neither gives nor denies his/her consent, the Request shall expire and is then rejected to the PISP. The expiration delay is specified by each ASPSP.
Redirect authentication approach
When the chosen authentication approach within the ASPSP answers is set to "REDIRECT":
- The PISP redirects the PSU to the ASPSP which authenticates the PSU
- The ASPSP asks the PSU to give (or deny) his/her consent to the Payment Request
- The PSU chooses or confirms which of his/her accounts shall be used by the ASPSP for the future Credit Transfer.
- The ASPSP is then able to initiate the subsequent Credit Transfer
- The ASPSP redirects the PSU to the PISP using one of the call-back URLs provided within the posted Payment Request
Decoupled authentication approach
When the chosen authentication approach is "DECOUPLED":
- Based on the PSU identifier provided within the Payment Request by the PISP, the ASPSP gives the PSU with the Payment Request details and challenges the PSU for a Strong Customer Authentication on a decoupled device or application.
- The PSU chooses or confirms which of his/her accounts shall be used by the ASPSP for the future Credit Transfer.
- The ASPSP is then able to initiate the subsequent Credit Transfer
- The ASPSP notifies the PISP about the finalisation of the authentication and consent process by using one of the call-back URLs provided within the posted Payment Request
Embedded authentication approach
When the chosen authentication approach within the ASPSP answers is set to "EMBEDDED":
- The TPP informs the PSU that a challenge is needed for completing the Payment Request processing. This challenge will be one of the following:
- The PSU unlock the device or application through a "knowledge factor" and/or an "inherence factor" (biometric), retrieves the Payment Request details and processes the data sent by the ASPSP;
- The PSU might choose or confirm which of his/her accounts shall be used by the ASPSP for the future Credit Transfer when the device or application allows it.
- When agreeing the Payment Request, the PSU enters the resulting authentication factor through the PISP interface which will forward it to the ASPSP through a confirmation request (cf. § 4.7)
User Authentication is Required. The User must be logged in. The Application must also be authenticated.
JSON request body fields:
JSON response body fields:
- Required JSON Validation: No
- Allowed Authentication Types: Not set
- OBP-20001: User not logged in. Authentication is required!
- OBP-50000: Unknown Error.
Retrieval of a payment request (PISP)
NOTE: This endpoint currently only returns example data.
### Description
The following use cases can be applied:
- retrieval of a payment request on behalf of a merchant
- retrieval of a transfer request on behalf of the account's owner
- retrieval of a standing-order request on behalf of the account's owner
The PISP has sent a Request through a POST command.
The ASPSP has registered the Request, updated if necessary the relevant identifiers in order to avoid duplicates and returned the location of the updated Request.
The PISP gets the Request that has been updated with the resource identifiers, and eventually the status of the Payment/Transfer Request and the status of the subsequent credit transfer.
Prerequisites
- The TPP has been registered by the Registration Authority for the PISP role
- The TPP was provided with an OAUTH2 "Client Credential" access token by the ASPSP (cf. § 3.4.3).
- The TPP has previously posted a Request which has been saved by the ASPSP (cf. § 4.5.3)
- The TPP and the ASPSP have successfully processed a mutual check and authentication
- The TPP has presented its "OAUTH2 Client Credential" access token
Business flow
The PISP asks to retrieve the Payment/Transfer Request that has been saved by the ASPSP. The PISP uses the location link provided by the ASPSP in response of the posting of this request.
The ASPSP returns the previously posted Payment/Transfer Request which is enriched with:
- The resource identifiers given by the ASPSP
- The status information of the Payment Request and of the subsequent credit transfer
The status information must be available during at least 30 calendar days after the posting of the Payment Request. However, the ASPSP may increase this availability duration, based on its own rules.
User Authentication is Required. The User must be logged in. The Application must also be authenticated.
URL Parameters:
PAYMENTREQUESTRESOURCEID: PAYMENTREQUESTRESOURCEID
JSON response body fields:
- Required JSON Validation: No
- Allowed Authentication Types: Not set
- OBP-20001: User not logged in. Authentication is required!
- OBP-50000: Unknown Error.