...
The Payment Initiation API Profile describes the flows and common functionality functionalities for the Payment Initiation API, which allows a Payment Initiation Service Provider ('PISP') to:
...
The API uses three status codes that serve three different purposes:
The HTTP Status Code status code reflects the outcome of the API call (the HTTP operation on the resource)
The Status status field for the payment-order consent reflects the status of the Useruser/Customer customer consent authorisation
The Status status field for the payment-order resource reflects the status of the payment-order initiation or execution
...
The figure below provides a general outline of a payment flow for all payment-order types using the Payment payment APIs. The payment-order types covered in this profile include:
...
The PISP requests the user/customer to authorise the consent. The ASPSP may carry this out by using a redirection flow or a decoupled flow
In a redirection flow, the PISP redirects the user/customer to the ASPSP
The redirect includes the ConsentId generated in the previous step
This allows the ASPSP to correlate the payment-order consent that was setup
The ASPSP authenticates the user/customer
The user/customer selects the debtor account at this stage (if it has not been previously specified in Step 1)
The ASPSP updates the state of the payment-order consent resource internally to indicate that the consent has been authorised
Once the consent has been authorised, the user/customer is redirected back to the PISP
In a decoupled flow, the ASPSP requests the user/customer to authorise consent on an authentication device that is separate from the consumption device on which the user/customer is interacting with the PISP
The decoupled flow is initiated by the PISP calling a back-channel authorisation request
The request contains a 'hint' that identifies the user/customer paired with the consent to be authorised
The ASPSP authenticates the user/customer
The user/customer selects the debtor account at this stage (if it has not been previously specified in Step 1)
The ASPSP updates the state of the payment-order consent resource internally to indicate that the consent has been authorised
Once the consent has been authorised, the ASPSP can make a callback to the PISP to provide an access token
...
The maximum InstructedAmount allowable
The maximum future date on a future dated paymentFuture Dated Payment
Each ASPSP must determine appropriate restrictions that they support based on their individual practices, standards and limitations. These restrictions should be documented on ASPSP developer portals.
...
An ASPSP must document the behaviour for a payment receipt before and after the CutOffDateTime for a payment-order that has elapsed.
Two strategies for handling behaviour are:
...
3.3 Release Management
This section overviews coverss the release management and versioning strategy for the Payment Initiation API. It applies to all Payment Order payment-order Consent and Payment Order payment-order resources, specified in the Endpoints section.
...
A PISP must not create a payment-order-consent ConsentId on a newer version and use it to create a payment-order resource in a previous version
E.g., A ConsentId created in v3, must not be used to create a v1 PaymentSubmissionId
A PISP must not create a payment-order consent ConsentId on a previous version and use it to create a payment-order resource in a newer version
E.g., A PaymentId created in v1, must not be used to create a v3 DomesticPaymentId
...
A PISP must use a payment-order consent ConsentId within the same version to create the payment-order resource (in that version)
E.g., a v3 payment-order consent can only be used to create a payment-order resource in v3
An ASPSP must not allow a PISP to use a ConsentId from a previous version to create a Payment Order payment-order in a newer version, and vice versa
...
The access tokens required for accessing the Payment APIs must have at least the following scope:
Payments: Generic payment scope
...
Payment consents are short-lived and cannot be re-authenticated by the user/Customercustomer.
4.4 Risk Scoring Information
Note: This section currently considers indicative data fields required for banks to do Transactional transactional risk analysis where needed.
...
This section describes the OBSCASupportData class, which is used across all payment-order consent request resources, enabling PISPs to provide Supporting Data when requesting ASPSP for SCA Exemption
...
6. Alternative and Error Flows
6.1 Idempotent Payment-Order Consents
Note: This flow has been generalised for all payment-order types.
...
6.2 Idempotent Payment-Order
Note: This flow has been generalised for all payment-order types.
...
6.3 Reject the Payment-Order Consents Creation after CutOffDateTime
This example illustrates a scenario where an ASPSP choses to Reject the Payment-Order consent/resource request, after the CutoffTime. We have a payment-order consent created after the CutOffDateTime, and ASPSP rejects the Consent, and the PISP chooses to place a Future Dated Payment-Order consent.
...
6.4 Reject the Payment-Order Creation after CutOffDateTime
This example illustrates a scenario where an ASPSP choses to Reject the Payment-Order consent/resource request, after the CutoffTime. We have a payment-order Consent created and the Authorisation completed before the CutOffDateTime, but the Payment-Order submission happened after the CutOffDateTime, so the ASPSP has rejected it.
...