Page Comparison

...

• Register an intent to stage a payment-order consent

• Optionally confirm available funds for a payment-order for Domestic payments and international immediate payments only

• Subsequently submit the payment-order for processing

• Retrieve the status of a payment-order consent or order consent or payment-order resourceorder resource

1.1 Document Overview

This document consists of the following parts:

...

Security & Access Control: Specifies the means for PISPs and Userusers/Customers customers to authenticate themselves and provide consent

...

Step 1: Agree Payment-Order Initiation

• This flow begins with a Useruser/Customer customer consenting to a payment being made. The consent is between the Useruser/Customer customer and the PISP

• The debtor account details can optionally be specified at this stage

...

• The PISP connects to the ASPSP that services the Useruser’s/Customercustomer's payment account and creates a new paymentnew payment-order consent resourceconsent resource. This informs the ASPSP that one of its Userusers/Customers customers intends to make a paymenta payment-order. The ASPSP responds with an identifier for the payment-order consent resource (the ConsentId, which is the intent identifier)

• This step is carried out by making a POST request to the payment-order consent resource

Step 3: Authorise Consent

• The PISP requests the Useruser/Customer 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 Useruser/Customer 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 Useruser/Customercustomer

    • The Useruser/Customer 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 Useruser/Customer customer is redirected back to the PISP

  • In a decoupled flow, the ASPSP requests the Useruser/Customer customer to authorise consent on an authentication device that is separate from the consumption device on which the Useruser/Customer 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 Useruser/Customer customer paired with the consent to be authorised

    • The ASPSP authenticates the Useruser/Customercustomer

    • The Useruser/Customer 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

Step 4: Confirm Funds (Domestic and international immediate Payments Only)

• Once the Useruser/Customer customer is authenticated and has authorised the payment-order-consent, the PISP can check whether funds are available to make the payment

• This is carried out by making a GET request, calling the funds-confirmation operator on the payment-order-consent resource

...

• The maximum InstructedAmount allowable

• The maximum future date on a future dated payment

Each ASPSP must determine 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 reject ASPSP must reject the payment-order consent if order consent if the ASPSP is unable to handle the request.

2.2.1 CutOffDateTime Behaviour

An ASPSP may return ASPSP may return the specific CutOffDateTime when responding to a payment-order consent request.

An ASPSP must document ASPSP must document the behaviour for a payment receipt before and after the CutOffDateTime for a payment-order has elapsed.

...

In this scenario, the behaviour of payment-order execution is explicit to the PISP and Useruser/Customercustomer.

• An ASPSP must reject ASPSP must reject the payment-order consent if order consent if the CutOffDateTime for a specific payment-order type has elapsed

• An ASPSP must reject ASPSP must reject an authorisation request when the underlying intent object is associated with a CutoffDateTime that has elapsed. The ASPSP must not issue ASPSP must not issue an access token in such a situation. The ASPSP must set ASPSP must set the status of the payment-order consent resource to “Rejected”

• An ASPSP must reject ASPSP must reject the payment-order resource if order resource if the CutOffDateTime for a specific payment-order type, has been established and has elapsed

• A PISP must ensure PISP must ensure that the Useruser/Customer customer consent authorisation is completed and the payment-order resource is created before the CutOffDateTime elapses

For a payment-order consent or order consent or a payment-order resource that order resource that has been rejected due to the elapsed CutoffDateTime, the PISP may decide PISP may decide to create a corresponding future dated payment endpoint to create a new payment-order consent. The PISP may use the /domestic-future-dated-payment-consents endpoint to create a consent for the same payment for the next working day.

...

In this scenario, the behaviour of the payment-order execution is not explicit to the PISP and Useruser/Customercustomer, and the payment-order will be executed on the next available working day.

• An ASPSP must accept ASPSP must accept the payment-order consent if order consent if the CutOffDateTime for a specific payment-order type has elapsed

• An ASPSP must accept ASPSP must accept an authorisation request when the underlying intent object is associated with a CutoffDateTime that has elapsed

• An ASPSP must accept ASPSP must accept the payment-order resource if order resource if the CutOffDateTime for a specific payment-order type, has been established and has elapsed

• An ASPSP may update ASPSP may update the payment-order consent or payment-order resource with order resource with the CutOffDateTime, ExpectedExecutionDateTime and ExpectedSettlementDateTime, to communicate expected execution behaviour if the CutOffDateTime has elapsed 

...

2.3.1 Payment-Order Consents

2.3.1.1  POST

• A PISP must not create 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 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

2.3.1.2  GET

• A PISP must not access PISP must not access a payment-order ConsentId created in a newer version, via a previous version endpoint

  • E.g., A ConsentId created in v3 accessed via a v1 PaymentId

• An ASPSP may choose ASPSP may choose to make ConsentIds accessible across versions

  • E.g., for a PaymentId created in v1, an ASPSP may or may not make it available via v3, as this is a short-lived consent

2.3.2 Payment-Order Consents (Confirm Funds)

2.3.2.1  GET

• A PISP must not confirm PISP must not confirm funds using a payment-order-consent ConsentId created in a different version

  • E.g. a ConsentId created in v3, must not be used to confirm funds on a v1 endpoint

2.3.3 Payment-Order Resource

2.3.3.1  POST

• A PISP must use 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 order consent can only be used to create a payment-order resource in order resource in v3

• An ASPSP must not allow ASPSP must not allow a PISP to use a ConsentId from a previous version to create a Payment Order in a newer version, and vice versa

2.3.3.2  GET

• A PISP must refer PISP must refer to the ASPSP's online Developer Portal for guidelines on accessibility of a payment-order resource in a newer version

• A PISP must not PISP must not access the payment-order resource types introduced in a newer version, on an older version endpoint:

  • E.g., an domestic-payment created in v3, which is accessed via the v1 payment-submissions endpoint

• A PISP must not PISP must not access the payment-order resource created in a newer version on an older version endpoint:

  • E.g., for a domestic-payment resource created in v3, access via the v1 payment-submissions endpoint is not permitted

• An ASPSP must document ASPSP must document the behaviour on the accessibility of a payment-order resource in a newer version on the ASPSP's online Developer Portal

• An ASPSP must allow ASPSP must allow access to the payment-order resource created in a previous version on a newer version endpoint (depending on an ASPSP's legal requirement for data retention):

  • E.g., a payment-submission created in v1, must be accessible as a v3 domestic-payment, with sensible defaults for additional fields introduced in v3 (e.g., if an ASPSP must make payment resources available for 7 years)

• In the case where a payment-order type is the same, but the structure has changed in a newer version, sensible defaults may be used, with the ASPSP's Developer Portal clearly specifying the behaviour

  • E.g., a new field StatusUpdateDateTime was introduced in v3, an ASPSPs must populate this with the last status update time (as the StatusUpdateDateTime is a mandatory field)

...

Payments: Generic payment scope

3.2 Grants Types

PISPs must use PISPs must use a client credentials grant to obtain a token to make POST requests to the payment-order consent endpointsorder consent endpoints. In the specification, this grant type is referred to as "Client Credentials".

PISPs must use PISPs must use an authorisation code grant using a redirect or decoupled flow to obtain a token to make POST requests to the payment-order resource endpointsorder resource endpoints. This token may also be used to confirm funds on a payment-order consent resourceorder consent resource. In the specification, this grant type is referred to as "Authorisation Code".

PISPs must use PISPs must use a client credentials grant to obtain a token to make GET requests (excluding confirming funds).

...

A consent authorisation is used to define the fine-grained scope that is granted by the Useruser/Customer customer to the PISP.

The PISP must begin PISP must begin a payment-order request by creating a paymenta payment-order consent resource through a POST operationconsent resource through a POST operation. These resources indicate the consent that the PISP claims it has been given by the Useruser/Customercustomer. At this stage, the consent is not yet authorised as the ASPSP has not yet verified this claim with the Useruser/Customercustomer.

The ASPSP responds with a ConsentId. This is the intent-id that is used when initiating the authorisation code grant.

...

• The ASPSP authenticates the Useruser/Customercustomer

• If the consent did not indicate a debtor account the ASPSP presents the Useruser/Customer customer with a list of accounts from which the Useruser/Customer customer may select one

• The ASPSP plays back the consent (registered by the PISP) back to the Useruser/Customer customer to get consent authorisation. The Useruser/Customer customer may accept or reject the consent in its entirety (but not selectively) 

Once these steps are complete, the consent is considered to have been authorised by the Useruser/Customercustomer.

3.3.1 Error Condition

If the Useruser/Customer customer does not complete a successful consent authorisation (e.g., if the Useruser/Customer customer has not authenticated successfully), the authorisation code grant ends with a redirection to the PISP with an error response. The Useruser/Customer customer is redirected to the PISP with an error parameter indicating the error that occurred.

3.3.2 Consents Revocation

A Useruser/Customer customer cannot revoke a payment-order consent once it has been authorised.

...

Payment consents are short-lived and cannot be re-authenticated by the Useruser/Customer.

3.4 Risk Scoring Information 

Note: This section currently considers indicative data fields required for banks to do Transactional risk analysis where needed.

Information for risk scoring and assessment will come via:

...

...

...

...