1. Version Control

2.  Overview

The Payment Initiation API Profile describes the flows and common functionalities for the Payment Initiation API, which allows a Payment Initiation Service Provider ('PISP') to:

• 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 payment-order resource

2.1 Chapter Overview

This chapter (Payment Initiation Services) consists of the following parts:

Overview: Provides an overview of the profile

Basics: Identifies the flows, restrictions, etc.

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

Data Model: Mappings and enumerations that apply to all the end-points

Alternative Flows: Rules for alternative flows

2.2 Resources

Each of the Payment Initiation API resources are documented in the Resources and Data Models / PISP area of the specification. Each resource is documented with:

• Endpoints

  • The API endpoints available for the resource

• Data Model

  • Resource definition

  • UML diagram

  • Data dictionary - which defines fields, re-usable classes, mandatory (1..1) or conditional (0..1)

• Usage Examples

2.3  Design Principles

2.3.1 Status Codes

The API uses three status codes that serve three different purposes:

• The HTTP status code reflects the outcome of the API call (the HTTP operation on the resource)

• The status field for the payment-order consent reflects the status of the user/customer consent authorisation

• The status field for the payment-order resource reflects the status of the payment-order initiation or execution

3.  Basics

3.1  Overview

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:

• Single Domestic Payment

• Single Future Dated Domestic Payment

• Single International Payment

• Bulk/Batch Payment 

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.

Open

3.1.1 Steps

Step 1: Agree Payment-Order Initiation

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

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

Step 2: Setup Payment-Order Consent

• The PISP connects to the ASPSP that services the user’s/customer's payment account and creates a new payment-order consent resource. This informs the ASPSP that one of its users/customers intends to make a 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 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

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

• Once the user/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

Step 5: Create Payment-Order

• 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 returns the identifier for the payment-order resource to the PISP

Step 6: Get Consent/Payment-Order/Payment-Details Status

• The PISP can check the status of the payment-order consent (with the ConsentId) or payment-order resource (with the payment-order resource identifier) or payment-details (with the payment-order resource identifier)

• This is carried out by making a GET request to the payment-order consent or payment-order or payment-details resource

3.1.2 Sequence Diagram

Open

• CIBA- Client Initiated Backchannel Authentication

3.2  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 maximum future date on a Future 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 reject the payment-order consent if the ASPSP is unable to handle the request.

3.2.1 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 that 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

3.2.1.1  Reject the Payment-Order

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

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

• An ASPSP must reject an authorisation 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 user/customer 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 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.

3.2.1.2  Accept the Payment-Order

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 must accept the payment-order consent if the CutOffDateTime for a specific payment-order type has elapsed

• An ASPSP must accept an authorisation 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 

3.3  Release Management

This section coverss 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.

3.3.1 Payment-Order Consents

3.3.1.1  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

3.3.1.2  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

3.3.2 Payment-Order Consents (Confirm Funds)

3.3.2.1  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

3.3.3 Payment-Order Resource

3.3.3.1  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

3.3.3.2  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., a domestic-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 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)

4.  Security & Access Control

4.1 Scopes

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

Payments: Generic payment scope

4.2 Grants Types

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

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 endpoints. This token may also be used to confirm funds on a payment-order consent resource. In the specification, this grant type is referred to as "Authorisation Code".

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

4.3 Consents Authorisation

OAuth 2.0 scopes are coarse-grained and the set of available scopes are defined at the point of client registration. There is no standard method for specifying and enforcing fine-grained scopes e.g., a scope to enforce payments of a specified amount on a specified date.

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

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 has not yet verified this claim with the user/customer.

The ASPSP 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 authenticates the user/customer

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

• The ASPSP 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) 

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

4.3.1 Error Condition

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

4.3.2 Consents Revocation

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

4.3.3 Changes to Selected Account

For a payment-order consent, the selected debtor account cannot be changed once the consent has been authorised.

4.3.4 Consents Re-Authentication

Payment consents are short-lived and cannot be re-authenticated by the user/customer.

4.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:

• FAPI HTTP headers (Please refer Security Standards and Guidelines for further information)

• Additional fields identified by the industry as business logic security concerns which will be passed in the Risk section of the payload in the JSON object

These are the set of additional fields in the risk section of the payload which will be specified by the PISP:

• PaymentContextCode

• MerchantCategoryCode

• MerchantCustomerIdentification

• DeliveryAddress

The PaymentContextCode describes the payment context and can have these values:

• BillPayment

• EcommerceGoods

• EcommerceServices

• Other

• PartyToParty

Payments for EcommerceGoods and EcommerceServices will be expected to have a MerchantCategoryCode and MerchantCustomerIdentification populated. Payments for EcommerceGoods will also have the DeliveryAddress populated.

5.  Data Model

5.1  Reused Classes

5.1.1 OBRisk

This section describes the OBRisk class which is reused in the payment-order consent and payment-order resources.

5.1.1.1  UML Diagram

Open

5.1.1.2  Data Dictionary

5.1.2 OBCharge

This section describes the OBCharge class - which is reused in the response payloads in the payment-order consent and payment-order resources.

5.1.2.1  UML Diagram

Open

5.1.2.2  Data Dictionary