...
The PISP connects to the ASPSP (Bank) that services the user’s/customer’s payment account and creates a new payment-order consent resource. This informs the ASPSP (Bank) that one of its users/customers intends to make a payment-order. The ASPSP (Bank) 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.
...
The PISP requests the user/customer to authorise the consent. The ASPSP (Bank) 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 (Bank) .
The redirect includes the ConsentId generated in the previous step.
This allows the ASPSP (Bank) to correlate the payment order consent that was setup.
The ASPSP (Bank) 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 (Bank) 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 (Bank) 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 (Bank) 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 (Bank) 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 (Bank) can make a callback to the PISP to provide an access token.
...
The PISP creates a payment-order resource to indicate that the payment created in the steps above should be submitted for processing.
This is carried out by making a POST request to the appropriate payment-order resource.
The ASPSP (Bank) returns the identifier for the payment-order resource to the PISP.
...
The maximum InstructedAmount allowable.
The domestic-standing-order Frequency patterns supported.
The maximum future date on a future dated payment.
Each ASPSP (Bank) must determine appropriate restrictions that they support based on their individual practices, standards and limitations. These restrictions should be documented on ASPSP (Bank) developer portals.
An ASPSP (Bank) must reject the payment-order consent if the ASPSP (Bank) is unable to handle the request.
2.2.1 CutOffDateTime Behaviour
An ASPSP (Bank) may return the specific CutOffDateTime when responding to a payment-order consent request.
An ASPSP (Bank) 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 user/customer.
An ASPSP (Bank) must reject the payment-order consent if the CutOffDateTime for a specific payment-order type has elapsed.
An ASPSP (Bank) must reject an authorisation request when the underlying intent object is associated with a CutoffDateTime that has elapsed. The ASPSP (Bank) must not issue an access token in such a situation. The ASPSP (Bank) must set the status of the payment-order consent resource to “Rejected”.
An ASPSP (Bank) must reject the payment-order resource if the CutOffDateTime for a specific payment-order type, has been established and has elapsed.
A PISP must ensure that the user/customer consent authorisation is completed and the payment-order resource is created before the CutOffDateTime elapses.
...
In this scenario, the behaviour of the payment-order execution is not explicit to the PISP and user/customer, and the payment-order will be executed on the next available working day.
An ASPSP (Bank) must accept the payment-order consent if the CutOffDateTime for a specific payment-order type has elapsed.
An ASPSP (Bank) must accept an authorisation request when the underlying intent object is associated with a CutoffDateTime that has elapsed.
An ASPSP (Bank) must accept the payment-order resource if the CutOffDateTime for a specific payment-order type, has been established and has elapsed.
An ASPSP (Bank) may update the payment-order consent or payment-order resource with the CutOffDateTime, ExpectedExecutionDateTime and ExpectedSettlementDateTime, to communicate expected execution behaviour if the CutOffDateTime has elapsed
...
A 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 (Bank) may choose to make ConsentIds accessible across versions
E.g., for a PaymentId created in v1, an ASPSP (Bank) may or may not make it available via v3, as this is a short-lived consent
...
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 (Bank) 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
...
A PISP must refer to the ASPSP's (Bank’s) online Developer Portal for guidelines on accessibility of a payment-order resource in a newer version
A PISP must not access the payment-order resource types introduced in a newer version, on an older version endpoint:
E.g., an international-payment created in v3, which is accessed via the v1 payment-submissions endpoint.
A 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 (Bank) must document the behaviour on the accessibility of a payment-order resource in a newer version on the ASPSP's (Bank’s) online Developer Portal.
An ASPSP (Bank) must allow access to the payment-order resource created in a previous version on a newer version endpoint (depending on an ASPSP's (Bank’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 (Bank) 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 (Bank’s) Developer Portal clearly specifying the behaviour.
E.g., a new field StatusUpdateDateTime was introduced in v3, an ASPSP (Bank) must populate this with the last status update time (as the StatusUpdateDateTime is a mandatory field).
...
The PISP must begin a payment-order request by creating a payment-order consent resource through a POST operation. These resources indicate the consent that the PISP claims it has been given by the user/customer. At this stage, the consent is not yet authorised as the ASPSP (Bank) has not yet verified this claim with the user/customer.
The ASPSP (Bank) responds with a ConsentId. This is the intent-id that is used when initiating the authorisation code grant.
As part of the authorisation code grant:
The ASPSP (Bank) authenticates the user/customer.
The ASPSP (Bank) plays back the consent (registered by the PISP) back to the user/customer to get consent authorisation. The user/customer may accept or reject the consent in its entirety (but not selectively).
If the consent did not indicate a debtor account the ASPSP (Bank) presents the user/customer with a list of accounts from which the user/customer may select one.
...
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 (Bank) for SCA Exemption.
4.1.7.1 UML Diagram
...
Generated | Identifier | Business Description |
Merchant/PISP Sent in API Payload | EndToEndIdentification | The EndToEndIdentification reference is a reference that can be populated by the debtor (or merchant in the ecommerce space). This reference is important to the debtor (could be an internal reference Id against the transaction), it Is NOT the reference information that will be primarily populated on the statement of the creditor (beneficiary). |
Merchant/PISP Sent in API Payload | InstructionIdentification | The PISP generates the InstructionIdentification which is a unique transaction Id and passes it to the ASPSP (Bank) (this is mandatory), but this does not have to go any further in the payment flow. The flow of this identifier needs to align with payment scheme rules. The expectation is that this is unique indefinitely across all time periods. The PISP can ensure this is indefinitely unique by including a date or date time element to the field, or by inserting a unique Id. |
Merchant/PISP Sent in API Payload | RemittanceInformation | The RemittanceInformation is the reference information that the creditor (or beneficiary) will need to reconcile (e.g. Invoice 123). |
ASPSP / API System | ConsentId | A unique identification as assigned by the ASPSP (Bank) to uniquely identify the payment-order consent resource. |
ASPSP / API System | Payment Order Id | A unique identification as assigned by the ASPSP (Bank) to uniquely identify the payment-order resource.
|
ASPSP / Payment Scheme | Scheme Payment ID | This is generated by the ASPSP (Bank) to uniquely identify a payment through a processing scheme. |
...
This example illustrates a scenario where an ASPSP (Bank) choses to Reject the Payment-Order consent/resource request, after the CutoffTime. We have a payment-order consent created after the CutOffDateTime, and ASPSP (Bank) rejects the Consent, and the PISP chooses to place a Future Dated Payment-Order consent.
...
This example illustrates a scenario where an ASPSP (Bank) 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 (Bank) has rejected it.
...
6. Swagger Code
...