Payment Initiation API

The figure below provides a general outline of a payment flow for all payment-order types using the Payment APIs. The payment-order types covered in this profile include:

• Domestic payments.
• Domestic scheduled payments.
• Domestic standing orders.
• International payments.
• International scheduled payments.

The payment-order consent and payment-order resource in the following flow generalises for the different payment-order types. e.g. for a domestic payment, the payment-order consent resource is domestic-payment-consents; and the payment-order resource is domestic-payments.

Payment Restrictions

The standard does not provide a uniform set of restrictions for payment-order types that can be supported through this API.

For example, but not limited to:

• The maximum InstructedAmount allowable.
• The domestic-standing-order Frequency patterns supported.
• The maximum future date on a scheduled-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 reject the payment-order consent if the ASPSP is unable to handle the request.

#CutOffDateTime Behaviour

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

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

Two strategies for handling behaviour are:

• Reject the payment-order (and steps associated with the creation of payment-order) if received after the applicable CutOffDateTime
• Accept the payment-order (and steps associated with the creation of payment-order) if received after the applicable CutOffDateTime

#Reject the Payment-Order

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

• An ASPSP must reject the payment-order consent if the CutOffDateTime for a specific payment-order type has elapsed.
• An ASPSP must reject an authorization request when the underlying intent object is associated with a CutoffDateTime that has elapsed. The ASPSP must not issue an access token in such a situation. The ASPSP must set the status of the payment-order consent resource to “Rejected”.
• An ASPSP 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 PSU consent authorisation is completed and the payment-order resource is created before the CutOffDateTime elapses.

For a payment-order consent or a payment-order resource that has been rejected due to the elapsed CutoffDateTime, the PISP may decide to create a corresponding schedule payment endpoint to create a new payment-order consent. E.g. if a PISP attempts to make a BACS payment after 16:00, it would be rejected. The PISP may use the /domestic-scheduled-payment-consents endpoint to create a consent for the same payment for the next working day.

#Accept the Payment-Order

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

• An ASPSP must accept the payment-order consent if the CutOffDateTime for a specific payment-order type has elapsed.
• An ASPSP must accept an authorization request when the underlying intent object is associated with a CutoffDateTime that has elapsed.
• An ASPSP must accept the payment-order resource if the CutOffDateTime for a specific payment-order type, has been established and has elapsed.
• An ASPSP 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.

#Release Management

This section overviews the release management and versioning strategy for the Payment Initiation API. It applies to all Payment Order Consent and Payment Order resources, specified in the Endpoints section.

#Payment-Order Consent

#POST

• 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

#GET

• 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 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

#Payment-Order Consent (Confirm Funds)

#GET

• A 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.

#Payment-Order Resource

#POST

• 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 in a newer version, and vice versa

#GET

• A 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 access the payment-order resource types introduced in a newer version, on an older version endpoint:
  • E.g., an international-payment created in v3, that 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 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 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).

#Security & Access Control

#Scopes

The access tokens required for accessing the Payment APIs must have at least the following scope:

payments: Generic payment scope