OBIE Read/Write API Standards
Search

Payment Initiation API Profile - v3.1.3

  1. Overview
    1. Document Overview
    2. Resources
    3. Design Principles
      1. Scheme Agnostic
      2. Status Codes
  2. Basics
    1. Overview
      1. Steps
      2. Sequence Diagram
    2. Payment Restrictions
      1. CutOffDateTime Behaviour
        1. Reject the Payment-Order
        2. Accept the Payment-Order
    3. Release Management
      1. Payment-Order Consent
        1. POST
        2. GET
      2. Payment-Order Consent (Confirm Funds)
        1. GET
      3. Payment-Order Resource
        1. POST
        2. GET
  3. Security & Access Control
    1. Scopes
    2. Grants Types
    3. Consent Authorisation
      1. Multiple Authorisation
      2. Error Condition
      3. Consent Revocation
      4. Changes to Selected Account
      5. Consent Re-authentication
    4. Risk Scoring Information
  4. Data Model
    1. Reused Classes
      1. OBRisk1
        1. UML Diagram
        2. Data Dictionary
      2. OBCharge2
        1. UML Diagram
        2. Data Dictionary
      3. OBAuthorisation1
        1. UML Diagram
        2. Data Dictionary
      4. OBMultiAuthorisation1
        1. UML Diagram
        2. Data Dictionary
      5. OBWritePaymentDetails1
        1. UML Diagram
        2. Data Dictionary
      6. OBSCASupportData1
        1. UML Diagram
        2. Data Dictionary
    2. Identifier Fields
      1. Merchant Flow
      2. Party to Party Flow
    3. Enumerations
      1. Static Enumerations
      2. ISO Enumerations
      3. Namespaced Enumerations
  5. Alternative and Error Flows
    1. Idempotent Payment Order Consent
    2. Idempotent Payment Order
    3. Multi-Auth Payment Order Consent
    4. Reject the Payment Order Consent Creation After CutOffDateTime
    5. Reject the Payment Order Creation After CutOffDateTime

Overview

The Payment Initiation API Profile describes the flows and common functionality 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
    • Domestic immediate, international immediate and international scheduled (immediate debit) payments only.
  • Subsequently submit the payment-order for processing.
  • Optionally retrieve the status of a payment-order consent or payment-order resource.

This profile should be read in conjunction with a compatible Read/Write Data API Profile which provides a description of the elements that are common across all the Read/Write Data APIs, and compatible individual resources.

Document Overview

This document consists of the following parts:

Overview: Provides an overview of the profile.

Basics: Identifies the flows, restrictions and release management.

Security & Access Control: Specifies the means for PISPs and PSUs to authenticate themselves and provide consent.

Data Model: Documents mappings and enumerations that apply to all the end-points.

Alternative Flows: Documents rules for alternative flows.

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.
    • Permissions as they relate to accessing the resource.
    • Data dictionary - which defines fields, re-usable classes, mandatory (1..1) or conditional (0..1) as defined in the Design Principles section, and enumerations.
  • Usage Examples

Design Principles

Scheme Agnostic

The API has been be designed so that it is agnostic to the underlying payment scheme that is responsible for carrying out the payment.

In doing so, this means we will not design field lengths and payloads to only match the Faster Payments message, and will instead rely on the field lengths and definitions in ISO 20022. Due diligence has been carried out to ensure that the API has the necessary fields to function with Bacs payments as per the agreed scope.

Further mapping guidance has been provided to ensure that differences are understood between the Open Banking Payment API standard, and other message formats in the Domestic Payment Message Formats sub-page.

Status Codes

The API uses two status codes that serve two 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 PSU consent authorisation.
  • The Status field for the payment-order resource reflects the status of the payment-order initiation or execution.

Basics

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:

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

Payments Flow

Steps

Step 1: Agree Payment-Order Initiation

  • This flow begins with a PSU consenting to a payment being made. The consent is between the PSU 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 PSU’s payment account and creates a new payment-order consent resource. This informs the ASPSP that one of its PSUs 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 PSU 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 PSU 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 PSU.
      • The PSU 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 PSU is redirected back to the PISP.
    • In a decoupled flow, the ASPSP requests the PSU to authorise consent on an authentication device that is separate from the consumption device on which the PSU 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 PSU paired with the consent to be authorised.
      • The ASPSP authenticates the PSU
      • The PSU 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 Single Immediate Payments Only)

  • Once the PSU is authenticated and 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.

Sequence Diagram

Diagram source ``` participant PSU participant PISP participant ASPSP Authorisation Server participant ASPSP Resource Server note over PSU, ASPSP Resource Server Step 1: Agree Payment-Order Initiation end note PSU -> PISP: Agree payment-order initiation request note over PSU, ASPSP Resource Server Setup Payment-Order Consent end note PISP <-> ASPSP Authorisation Server: Establish TLS 1.2 MA PISP -> ASPSP Authorisation Server: Initiate Client Credentials Grant ASPSP Authorisation Server -> PISP: access-token PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA PISP -> ASPSP Resource Server: POST /payment-order-consents state over ASPSP Resource Server: Consent Status: AwaitingAuthorisation ASPSP Resource Server -> PISP: HTTP 201 (Created), ConsentId note over PSU, ASPSP Resource Server Step 3: Authorize Consent end note alt Redirection (Using authorization code grant) PISP -> PSU: HTTP 302 (Found), Redirect (ConsentId) PSU -> ASPSP Authorisation Server: Follow redirect (ConsentId) PSU <-> ASPSP Authorisation Server: authenticate PSU <-> ASPSP Authorisation Server: SCA if required PSU <-> ASPSP Authorisation Server: Select debtor account if required state over ASPSP Resource Server: Consent Status: Authorised ASPSP Authorisation Server -> PSU: HTTP 302 (Found), Redirect (authorization-code) PSU -> PISP: Follow redirect (authorization-code) PISP <-> ASPSP Authorisation Server: Establish TLS 1.2 MA PISP -> ASPSP Authorisation Server: Exchange authorization-code for access token ASPSP Authorisation Server -> PISP: access-token else Decoupled (Using CIBA) PISP -> ASPSP Authorisation Server: POST /bc-authorize (login_hint_token) ASPSP Authorisation Server -> PISP: OK PSU -> ASPSP Authorisation Server: Authorise (Consent Id) PSU <-> ASPSP Authorisation Server: authenticate PSU <-> ASPSP Authorisation Server: SCA if required PSU <-> ASPSP Authorisation Server: select accounts state over ASPSP Resource Server: Consent Status: Authorised alt Using callback ASPSP Authorisation Server -> PISP: Callback (authorization-code) PISP <-> ASPSP Authorisation Server: Establish TLS 1.2 MA PISP -> ASPSP Authorisation Server: Exchange authorization-code for access token ASPSP Authorisation Server -> PISP: access-token else Using polling PISP <-> ASPSP Authorisation Server: Establish TLS 1.2 MA PISP -> ASPSP Authorisation Server: Poll at /token using auth-req-id ASPSP Authorisation Server -> PISP: access-token end alt end alt note over PSU, ASPSP Resource Server Step 4: Confirm Funds (Domestic and International Single Immediate Payments Only) end note opt PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA PISP -> ASPSP Resource Server: GET /payment-order-consents/{ConsentId}/funds-confirmation ASPSP Resource Server -> PISP: HTTP 200 (OK) funds-confirmation resource end opt note over PSU, ASPSP Resource Server Step 5: Create Payment-Order end note PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA PISP -> ASPSP Resource Server: POST /payment-orders state over ASPSP Resource Server: Consent Status: Consumed alt Immediate Payment state over ASPSP Resource Server: Payment Status: Pending state over ASPSP Resource Server: Payment Status: AcceptedSettlementInProcess state over ASPSP Resource Server: Payment Status: AcceptedSettlementComplete else Standing Order or Future Dated Payment state over ASPSP Resource Server: Payment Status: InitiationPending state over ASPSP Resource Server: Payment Status: InitiationCompleted end alt ASPSP Resource Server -> PISP: HTTP 201 (Created), Payment-Order Id note over PSU, ASPSP Resource Server Step 6: Get Payment-Order-Consent/Payment-Order/Payment-details Status end note opt payment-order-consent PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA PISP -> ASPSP Resource Server: GET /payment-order-consents/{ConsentId} ASPSP Resource Server -> PISP: HTTP 200 (OK) payment-order-consent resource end opt opt payment-order PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA PISP -> ASPSP Resource Server: GET /payment-orders/{Payment-Order Id} ASPSP Resource Server -> PISP: HTTP 200 (OK) payment-order resource end opt opt payment-details PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA PISP -> ASPSP Resource Server: GET /payment-orders/{Payment-Order Id}/payment-details ASPSP Resource Server -> PISP: HTTP 200 (OK) payment-details resource end opt option footer=bar ```

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.

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

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 authorization 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 “Authorization Code”.

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

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 PSU 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 PSU. At this stage, the consent is not yet authorised as the ASPSP has not yet verified this claim with the PSU.

The ASPSP responds with a ConsentId. This is the intent-id that is used when initiating the authorization code grant (as described in the Trust Framework).

As part of the authorization code grant:

  • The ASPSP authenticates the PSU.
  • The ASPSP plays back the consent (registered by the PISP) back to the PSU to get consent authorisation. The PSU may accept or reject the consent in its entirety (but not selectively).
  • If the consent did not indicate a debtor account the ASPSP presents the PSU with a list of accounts from which the PSU may select one.

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

Multiple Authorisation

In a multiple authorisation context, the same consent authorisation steps are followed for the first PSU to authorise or stage the payment-order consent.

In the payment-order consent:

  • A PISP may request an AuthorisationType for the payment-order (i.e., Single or Any). If a value is not provided, an ASPSP will interpret the AuthorisationType as ‘Any’.
  • A PISP may request a CompletionDateTime for the payment-order authorisation to be complete. If a value is not provided, an ASPSP will interpret the CompletionDateTime as unbounded.
  • An ASPSP must reject the payment-order consent if the AuthorisationType requested by the PISP does not match the DebtorAccount in the request.
  • An ASPSP must set the status of the payment-order consent to Rejected, if the AuthorisationType requested by the PISP cannot be satisfied, after PSU Authentication:
    • The ASPSP must respond back with an OAuth error response fields error specified as invalid_request and error_description containing an appropriate message.
  • An ASPSP must restrict the selection of DebtorAccount (in the ASPSP online channel) to accounts that match the AuthorisationType requested by the PISP.

In the payment-order resource:

  • An ASPSP must respond with the MultiAuthorisation object if the payment-order requires multiple authorisations. The MultiAuthorisation object indicates to the PISP that the payment-order requires multiple authorisations.
  • The ASPSP must populate the MultiAuthorisation object with the Status of the multiple authorisaitons.
  • The ASPSP may populate the MultiAuthorisation object with additional details of the multiple authorisation journey including:
    • The number of required authorisations (total required at the start of the multi authorisation journey).
    • The number of authorisations complete.
    • The date and time of the last authorisation update.
    • The date and time that the authorisation flow must be completed.

Once the final authorisation is received by the ASPSP, the ASPSP may notify the PISP that the payment-order resource has been fully Authorised using an Event Notification (as described in the Event Notification API Profile and Resources).

Error Condition

If the PSU does not complete a successful consent authorisation (e.g., if the PSU has not authenticated successfully), the authorization code grant ends with a redirection to the TPP with an error response as described in RFC 6749 Section 4.1.2.1. The PSU is redirected to the TPP with an error parameter indicating the error that occurred.

A PSU cannot revoke a payment-order consent once it has been authorized.

This is required to comply with Article 80 of PSD2.

Changes to Selected Account

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

Payment consents are short-lived and cannot be re-authenticated by the PSU.

Risk Scoring Information

During the design workshops, ASPSPs articulated a need to perform risk scoring on the payments initiated via the Payment API.

Information for risk scoring and assessment will come via:

  • FAPI HTTP headers. These are defined in Section 6.3 of the FAPI specification and in the Headers section above.
  • 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 for v1.0 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.

These fields are documented further in the Data Payload section.

Data Model

Reused Classes

OBRisk1

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

UML Diagram

Data Dictionary
NameOccurrenceXPathEnhancedDefinitionClassCodesPattern
OBRisk1 OBRisk1The Risk section is sent by the initiating party to the ASPSP. It is used to specify additional details for risk scoring for Payments.OBRisk1  
PaymentContextCode0..1OBRisk1/PaymentContextCodeSpecifies the payment contextOBExternalPaymentContext1CodeBillPayment
EcommerceGoods
EcommerceServices
Other PartyToParty		 
MerchantCategoryCode0..1OBRisk1/MerchantCategoryCodeCategory code conform to ISO 18245, related to the type of services or goods the merchant provides for the transaction.Min3Max4Text  
MerchantCustomerIdentification0..1OBRisk1/MerchantCustomerIdentificationThe unique customer identifier of the PSU with the merchant.Max70Text  
DeliveryAddress0..1OBRisk1/DeliveryAddressInformation that locates and identifies a specific address, as defined by postal services or in free format text.PostalAddress18  
AddressLine0..2OBRisk1/DeliveryAddress/AddressLineInformation that locates and identifies a specific address, as defined by postal services, that is presented in free format text.Max70Text  
StreetName0..1OBRisk1/DeliveryAddress/StreetNameName of a street or thoroughfare.Max70Text  
BuildingNumber0..1OBRisk1/DeliveryAddress/BuildingNumberNumber that identifies the position of a building on a street.Max16Text  
PostCode0..1OBRisk1/DeliveryAddress/PostCodeIdentifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.Max16Text  
TownName1..1OBRisk1/DeliveryAddress/TownNameName of a built-up area, with defined boundaries, and a local government.Max35Text  
CountrySubDivision0..2OBRisk1/DeliveryAddress/CountrySubDivisionIdentifies a subdivision of a country, for instance state, region, county.Max35Text  
Country1..1OBRisk1/DeliveryAddress/CountryNation with its own government, occupying a particular territory.CountryCode^[A-Z]{2,2}$ 

OBCharge2

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

UML Diagram

Data Dictionary
NameOccurrenceXPathEnhancedDefinitionClassCodesPattern
OBCharge2 OBCharge2Set of elements used to provide details of a charge for the payment initiation.OBCharge2  
ChargeBearer1..1OBCharge2/ChargeBearerSpecifies which party/parties will bear the charges associated with the processing of the payment transaction.OBChargeBearerType1CodeBorneByCreditor
BorneByDebtor
FollowingServiceLevel
Shared		 
Type1..1OBCharge2/TypeCharge type, in a coded form.OBExternalPaymentChargeType1Code  
Amount1..1OBCharge2/AmountAmount of money associated with the charge type.OBActiveOrHistoricCurrencyAndAmount  
Amount1..1OBCharge2/Amount/AmountA number of monetary units specified in an active currency where the unit of currency is explicit and compliant with ISO 4217.OBActiveCurrencyAndAmount_SimpleType ^\d{1,13}.\d{1,5}$
Currency1..1OBCharge2/Amount/CurrencyA code allocated to a currency by a Maintenance Agency under an international identification scheme, as described in the latest edition of the international standard ISO 4217 “Codes for the representation of currencies and funds”.ActiveOrHistoricCurrencyCode ^[A-Z]{3,3}$

OBAuthorisation1

This section describes the OBAuthorisation1 class which is used in the payment-order consent request and payment-order consent response payloads.

UML Diagram

Data Dictionary
NameOccurrenceXPathEnhancedDefinitionClassCodesPattern
OBAuthorisation1 OBAuthorisation1The authorisation type request from the TPP.OBAuthorisation1  
AuthorisationType1..1OBAuthorisation1/AuthorisationTypeType of authorisation flow requested.OBExternalAuthorisation1CodeAny
Single		 
CompletionDateTime0..1OBAuthorisation1/CompletionDateTimeDate and time at which the requested authorisation flow must be completed.ISODateTime  

OBMultiAuthorisation1

This section describes the OBMultiAuthorisation1 class which used in the response payloads of payment-order resources.

UML Diagram

Data Dictionary
NameOccurrenceXPathEnhancedDefinitionClassCodesPattern
OBMultiAuthorisation1 OBMultiAuthorisation1The multiple authorisation flow response from the ASPSP.OBMultiAuthorisation1  
Status1..1OBMultiAuthorisation1/StatusSpecifies the status of the authorisation flow in code form.OBExternalStatus2CodeAuthorised
AwaitingFurtherAuthorisation
Rejected		 
NumberRequired0..1OBMultiAuthorisation1/NumberRequiredNumber of authorisations required for payment order (total required at the start of the multi authorisation journey).Number  
NumberReceived0..1OBMultiAuthorisation1/NumberReceivedNumber of authorisations received.Number  
LastUpdateDateTime0..1OBMultiAuthorisation1/LastUpdateDateTimeLast date and time at the authorisation flow was updated.ISODateTime  
ExpirationDateTime0..1OBMultiAuthorisation1/ExpirationDateTimeDate and time at which the requested authorisation flow must be completed.ISODateTime  

OBWritePaymentDetails1

This section describes the OBWritePaymentDetails1 class which used in the response payloads of payment-detail sub resources.

UML Diagram

Data Dictionary
NameOccurrenceXPathEnhancedDefinitionClassCodesPattern
OBWritePaymentDetails11..1OBWritePaymentDetails1Payment status details.OBWritePaymentDetails1  
PaymentTransactionId1..1OBWritePaymentDetails1/PaymentTransactionIdUnique identifier for the transaction within an servicing institution. This identifier is both unique and immutable.Max210Text  
Status1..1OBWritePaymentDetails1/StatusStatus of a transfer, as assigned by the transaction administrator.OBTransactionIndividualExtendedISOStatus1CodeAccepted
AcceptedCancellationRequest
AcceptedCreditSettlementCompleted
AcceptedCustomerProfile
AcceptedFundsChecked
AcceptedSettlementCompleted
AcceptedSettlementInProcess
AcceptedTechnicalValidation
AcceptedWithChange
AcceptedWithoutPosting
Cancelled
NoCancellationProcess
PartiallyAcceptedCancellationRequest
PartiallyAcceptedTechnicalCorrect
PaymentCancelled
Pending
PendingCancellationRequest
Received
Rejected
RejectedCancellationRequest		 
StatusUpdateDateTime1..1OBWritePaymentDetails1/StatusUpdateDateTimeDate and time at which the status was assigned to the transfer.ISODateTime  
StatusDetail0..1OBWritePaymentDetails1/StatusDetailPayment status details as per underlying Payment Rail.OBPaymentStatusDetail1  
LocalInstrument0..1OBWritePaymentDetails1/StatusDetail/LocalInstrumentUser community specific instrument.

Usage: This element is used to specify a local instrument, local clearing option and/or further qualify the service or service level.		OBExternalLocalInstrument1Code  
Status1..1OBWritePaymentDetails1/StatusDetail/StatusStatus of a transfer, as assigned by the transaction administrator.Max128Text  
StatusReason0..1OBWritePaymentDetails1/StatusDetail/StatusReasonReason Code provided for the status of a transfer.OBTransactionIndividualStatusReason1CodeCancelled
PendingFailingSettlement
PendingSettlement
Proprietary
ProprietaryRejection
Suspended
Unmatched		 
StatusReasonDescription0..1OBWritePaymentDetails1/StatusDetail/StatusReasonDescriptionReason provided for the status of a transfer.Max256Text  

OBSCASupportData1

This section describes the OBSCASupportData1 class, which is used across all payment order consent request resources, enabling PISPs to provide Supporting Data when requesting ASPSP for SCA Exemption.

UML Diagram

Data Dictionary
NameOccurrenceXPathEnhancedDefinitionClassCodesPattern
OBSCASupportData1 SCASupportDataSupporting Data provided by TPP, when requesting SCA Exemption.OBSCASupportData1  
RequestedSCAExemptionType0..1SCASupportData/RequestedSCAExemptionTypeThis field allows a PISP to request specific SCA Exemption for a Payment InitiationOBExternalSCAExemptionType1CodeBillPayment
ContactlessTravel
EcommerceGoods
EcommerceServices
Kiosk
Parking
PartyToParty		 
AppliedAuthenticationApproach0..1SCASupportData/AppliedAuthenticationApproachSpecifies a character string with a maximum length of 40 characters.

Usage: This field indicates whether the PSU was subject to SCA performed by the TPP		OBExternalAppliedAuthenticationApproach1CodeCA
SCA		 
ReferencePaymentOrderId0..1SCASupportData/ReferencePaymentOrderIdSpecifies a character string with a maximum length of 140 characters.

Usage: If the payment is recurring, then the transaction identifier of the previous payment occurrence so that the ASPSP can verify that the PISP, amount and the payee are the same as the previous occurrence.		Max128Text  

Identifier Fields

This section describes the identifiers used through the Payment API flows, the direction of flow through the system, and how they are used.

The standard definitions for the elements in the API payloads are described in the Data Payload section. However, this table gives further detail on the business meaning, and how they are used.

GeneratedIdentifierBusiness Description
Merchant/PISP Sent in API PayloadEndToEndIdentificationThe 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 PayloadInstructionIdentificationThe PISP generates the InstructionIdentification which is a unique transaction Id and passes it to the ASPSP (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 PayloadRemittanceInformationThe RemittanceInformation is the reference information that the creditor (or beneficiary) will need to reconcile (e.g. Invoice 123).
ASPSP / API SystemConsentIdA unique identification as assigned by the ASPSP to uniquely identify the payment-order consent resource.
ASPSP / API SystemPayment Order IdAnique identification as assigned by the ASPSP to uniquely identify the payment-order resource.

<li>DomesticPaymentId</li><li>DomesticScheduledPaymentId</li><li>DomesticStandingOrderId</li><li>InternationalPaymentId</li><li>InternationalScheduledPaymentId</li>
ASPSP / Payment SchemeScheme Payment IDThis is generated by the ASPSP to uniquely identify a payment through a processing scheme. In the case of FPS, this is the FPID.

The tables below identify the actor that initially creates each of the message identifiers and their transmission and visibility to other actors.

These flows are indicative and will be dependent on what payment schemes or agencies are able to support.

Key:

  • O indicates the actor that creates the identifier.
  • => downstream direction of flow
  • <= upstream direction of flow

Merchant Flow

IdentifierPSUMerchantPISPASPSP Originating BankPayment SchemeBeneficiary
EndToEndIdentification O=>=>=>=>
RemittanceInformation O=>=>=>=>
InstructionIdentification  O=>  
ConsentId  <=O  
Payment Order Id  <=O  
Scheme Payment ID (e.g., FPID)   O=>=>

Party to Party Flow

IdentifierPSUMerchantPISPASPSP Originating BankPayment SchemeBeneficiary
EndToEndIdentification  O=>=>=>
RemittanceInformationO =>=>=>=>
InstructionIdentification  O=>  
ConsentId  <=O  
Payment Order Id  <=O  
Scheme Payment ID (e.g., FPID)   O=>=>

Enumerations

Static Enumerations

This section gives the definitions for enumerations used in the Payment APIs.

Code ClassNameDefinition
OBExternalPaymentContext1CodeBillPaymentThe context of the payment initiation is a bill payment.
OBExternalPaymentContext1CodeEcommerceGoodsThe context of the payment initiation is for goods via an ecommerce channel.
OBExternalPaymentContext1CodeEcommerceServicesThe context of the payment initiation is for services via an ecommerce channel.
OBExternalPaymentContext1CodePartyToPartyThe context of the payment initiation is a party to party payment.
OBExternalPaymentContext1CodeOtherThe context of the payment initiation is of an other type.
OBTransactionIndividualStatus1CodeAcceptedSettlementCompletedSettlement on the debtor’s account has been completed.

Usage : this can be used by the first agent to report to the debtor that the transaction has been completed. Warning : this status is provided for transaction status reasons, not for financial information. It can only be used after bilateral agreement.

PISPs must not use this status as confirmation that settlement is complete on the creditor’s account.
OBTransactionIndividualStatus1CodeAcceptedSettlementInProcessAll preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution.
OBTransactionIndividualStatus1CodePendingPayment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed.
OBTransactionIndividualStatus1CodeRejectedPayment initiation or individual transaction included in the payment initiation has been rejected.
OBTransactionIndividualStatus1CodeAcceptedWithoutPostingPayment instruction included in the credit transfer is accepted without being posted to the creditor customer’s account.
OBTransactionIndividualStatus1CodeAcceptedCreditSettlementCompletedSettlement on the creditor’s account has been completed.
OBExternalConsentStatus1CodeAwaitingAuthorisationThe consent resource is awaiting PSU authorisation.
OBExternalConsentStatus1CodeRejectedThe consent resource has been rejected.
OBExternalConsentStatus1CodeAuthorisedThe consent resource has been successfully authorised.
OBExternalConsentStatus1CodeConsumedThe consented action has been successfully completed. This does not reflect the status of the consented action.
OBChargeBearerType1CodeBorneByCreditorAll transaction charges are to be borne by the creditor.
OBChargeBearerType1CodeBorneByDebtorAll transaction charges are to be borne by the debtor.
OBChargeBearerType1CodeFollowingServiceLevelCharges are to be applied following the rules agreed in the service level and/or scheme.
OBChargeBearerType1CodeSharedIn a credit transfer context, means that transaction charges on the sender side are to be borne by the debtor, transaction charges on the receiver side are to be borne by the creditor. In a direct debit context, means that transaction charges on the sender side are to be borne by the creditor, transaction charges on the receiver side are to be borne by the debtor.
OBExternalAuthorisation1CodeAnyAny authorisation type is requested.
OBExternalAuthorisation1CodeMultipleMultiple authorisation type is requested.
OBExternalAuthorisation1CodeSingleSingle authorisation type is requested.
OBExternalStatus1CodeInitiationCompletedThe payment-order initiation has been completed.
OBExternalStatus1CodeInitiationFailedThe payment-order initiation has failed.
OBExternalStatus1CodeInitiationPendingThe payment-order initiation is pending.
OBExternalStatus2CodeAuthorisedThe multiple authorisation flow has been fully authorised.
OBExternalStatus2CodeAwaitingFurtherAuthorisationThe multiple authorisation flow is awaiting further authorisation.
OBExternalStatus2CodeRejectedThe multiple authorisation flow has been rejected.
OBExternalStatus3CodeInitiationCompletedThe payment-order initiation has been completed.
OBExternalStatus3CodeInitiationFailedThe payment-order initiation has failed.
OBExternalStatus3CodeInitiationPendingThe payment-order initiation is pending.
OBExternalStatus3CodeCancelledPayment initiation has been successfully cancelled after having received a request for cancellation.
OBExchangeRateType2CodeActualExchange rate is the actual rate.
OBExchangeRateType2CodeAgreedExchange rate is the agreed rate between the parties.
OBExchangeRateType2CodeIndicativeExchange rate is the indicative rate.
OBPriority2CodeNormalPriority is normal.
OBPriority2CodeUrgentPriority is urgent.
OBAddressTypeCodeBusinessAddress is the business address.
OBAddressTypeCodeCorrespondenceAddress is the address where correspondence is sent.
OBAddressTypeCodeDeliveryToAddress is the address to which delivery is to take place.
OBAddressTypeCodeMailToAddress is the address to which mail is sent.
OBAddressTypeCodePOBoxAddress is a postal office (PO) box.
OBAddressTypeCodePostalAddress is the complete postal address.
OBAddressTypeCodeResidentialAddress is the home address.
OBAddressTypeCodeStatementAddress is the address where statements are sent.
OBTransactionIndividualExtendedISOStatus1CodeAcceptedRequest is accepted.
OBTransactionIndividualExtendedISOStatus1CodeAcceptedCancellationRequestCancellation is accepted.
OBTransactionIndividualExtendedISOStatus1CodeAcceptedCreditSettlementCompletedSettlement on the creditor’s account has been completed.
OBTransactionIndividualExtendedISOStatus1CodeAcceptedCustomerProfilePreceding check of technical validation was successful. Customer profile check was also successful.
OBTransactionIndividualExtendedISOStatus1CodeAcceptedFundsCheckedPreceding check of technical validation and customer profile was successful and an automatic funds check was positive.
OBTransactionIndividualExtendedISOStatus1CodeAcceptedSettlementCompletedSettlement on the debtor’s account has been completed.

Usage : this can be used by the first agent to report to the debtor that the transaction has been completed.

Warning : this status is provided for transaction status reasons, not for financial information. It can only be used after bilateral agreement
OBTransactionIndividualExtendedISOStatus1CodeAcceptedSettlementInProcessAll preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution.
OBTransactionIndividualExtendedISOStatus1CodeAcceptedTechnicalValidationAuthentication and syntactical and semantical validation are successful
OBTransactionIndividualExtendedISOStatus1CodeAcceptedWithChangeInstruction is accepted but a change will be made, such as date or remittance not sent.
OBTransactionIndividualExtendedISOStatus1CodeAcceptedWithoutPostingPayment instruction included in the credit transfer is accepted without being posted to the creditor customer’s account.
OBTransactionIndividualExtendedISOStatus1CodeCancelledRequest is cancelled.
OBTransactionIndividualExtendedISOStatus1CodeNoCancellationProcessNo cancellation process.
OBTransactionIndividualExtendedISOStatus1CodePartiallyAcceptedCancellationRequestCancellation is partially accepted.
OBTransactionIndividualExtendedISOStatus1CodePartiallyAcceptedTechnicalCorrectAuthentication and syntactical and semantical validation are successful.
OBTransactionIndividualExtendedISOStatus1CodePaymentCancelledTransaction has been cancelled.
OBTransactionIndividualExtendedISOStatus1CodePendingPayment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed.
OBTransactionIndividualExtendedISOStatus1CodePendingCancellationRequestCancellation request is pending.
OBTransactionIndividualExtendedISOStatus1CodeReceivedPayment initiation has been received by the receiving agent.
OBTransactionIndividualExtendedISOStatus1CodeRejectedPayment initiation or individual transaction included in the payment initiation has been rejected.
OBTransactionIndividualExtendedISOStatus1CodeRejectedCancellationRequestCancellation request is rejected
OBTransactionIndividualStatusReason1CodeCancelledReason why the payment status is cancelled
OBTransactionIndividualStatusReason1CodePendingFailingSettlementReason why the payment status is pending (failing settlement).
OBTransactionIndividualStatusReason1CodePendingSettlementReason why the payment status is pending (settlement).
OBTransactionIndividualStatusReason1CodeProprietaryDefines a free text proprietary reason.
OBTransactionIndividualStatusReason1CodeProprietaryRejectionDefines the reason that has been used by the Local Instrument system to reject the transaction
OBTransactionIndividualStatusReason1CodeSuspendedReason why the payment status is suspended.
OBTransactionIndividualStatusReason1CodeUnmatchedReason why the payment status is unmatched.
OBExternalSCAExemptionType1CodeBillPaymentBill Payment
OBExternalSCAExemptionType1CodeContactlessTravelContactless Travel
OBExternalSCAExemptionType1CodeEcommerceGoodsEcommerce Goods
OBExternalSCAExemptionType1CodeEcommerceServicesEcommerce Services
OBExternalSCAExemptionType1CodeKioskKisok
OBExternalSCAExemptionType1CodeParkingParking
OBExternalSCAExemptionType1CodePartyToPartyParty To Party
OBExternalAppliedAuthenticationApproach1CodeCASingle Factor Strong Customer Authentication
OBExternalAppliedAuthenticationApproach1CodeSCAMulti Factor Strong Customer Authentication

ISO Enumerations

These following ISO Enumerations are used in the Payment APIs.

ISO Data TypeFieldsISO Enumeration Values URL
Min3Max4TextMerchantCategoryCodehttps://www.iso.org/standard/33365.html
ActiveOrHistoricCurrencyCodeCurrencyhttps://www.iso20022.org/external_code_list.page
CountryCodeCountryhttps://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Officially_assigned_code_elements

Namespaced Enumerations

The enumerated values specified by Open Banking are documented in Swagger specification and Namespaced Enumerations page.

Alternative and Error Flows

Note: this flow has been generalised for all payment-order types.

Diagram source ``` participant PSU participant PISP participant ASPSP Authorisation Server participant ASPSP Resource Server note over PSU, ASPSP Resource Server Step 2: Setup Payment Order Consent (generalised for all payment orders) end note PISP <-> ASPSP Authorisation Server: Establish TLS 1.2 MA PISP -> ASPSP Authorisation Server: Initiate Client Credentials Grant ASPSP Authorisation Server -> PISP: token PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA PISP -> ASPSP Resource Server: POST /payment-order-consents (x-idempotency-key={pisp-guid-1}) ASPSP Resource Server -> ASPSP Resource Server: Create new resource (ConsentId=1001) alt unexpected failure PISP -> ASPSP Resource Server: POST /payment-order-consents (x-idempotency-key={pisp-guid-1}) note right of ASPSP Resource Server The resource server recognizes that this is the same request as earlier. A new resource is not created. The ConsentId remains the same (e.g. 1001) as above. The status of the resource may be different if it has changed. This operation can be retried multiple times if required. end note end alt ASPSP Resource Server -> PISP: HTTP 201(Created), ConsentId=1001 PISP -> PSU: Redirect (ConsentId) option footer=bar ```

Idempotent Payment Order

Note: this flow has been generalised for all payment-order types.

Diagram source ``` participant PSU participant PISP participant ASPSP Authorisation Server participant ASPSP Resource Server note over PSU, ASPSP Resource Server Step 4: Create payment-order (generalised for all payment orders) end note PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA PISP -> ASPSP Resource Server: POST /payment-orders ConsentId = 1001, x-idempotency-key={pisp-guid-2} alt PISP attempts to POST to /payment-orders with same ConsentId PISP -> ASPSP Resource Server: POST /payment-orders ConsentId = 1001, x-idempotency-key={pisp-guid-2} ASPSP Resource Server -> PISP: HTTP 201 (Created), PaymentOrderId note right of ASPSP Resource Server The resource server recognizes that this is the same request as earlier. A new resource is not created. The PaymentOrderId remains the same as above. The status of the resource may be different if it has changed. The operation can be retried multiple times if required. end note end alt option footer=bar ```

Diagram source ``` autonumber participant PSU Initial Authoriser participant PSU Final Authoriser participant PISP participant ASPSP Authorisation Server participant ASPSP Resource Server note over PSU Initial Authoriser, ASPSP Resource Server Step 1: Agree domestic payment Initiation end note PSU Initial Authoriser -> PISP: Agree domestic payment initiation request note over PSU Initial Authoriser, ASPSP Resource Server Step 2: Setup Payment-Order Consent end note PISP <-> ASPSP Authorisation Server: Establish TLS 1.2 MA PISP -> ASPSP Authorisation Server: Initiate Client Credential Grant ASPSP Authorisation Server -> PISP: access-token PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA PISP -> ASPSP Resource Server: POST /domestic-payment-consents state over ASPSP Resource Server: Consent Status: AwaitingAuthorisation ASPSP Resource Server -> PISP: HTTP 201 (Created),ConsentId PISP -> PSU Initial Authoriser: HTTP 302 (Found),Redirect (ConsentId) note over PSU Initial Authoriser, ASPSP Resource Server Step 3: Authorize Consent - Initial Authoriser end note PSU Initial Authoriser -> ASPSP Authorisation Server: Follow redirect (ConsentId) PSU Initial Authoriser <-> ASPSP Authorisation Server: Authenticate (SCA if required) and Authorise consent state over ASPSP Resource Server: Consent Status: Authorised ASPSP Authorisation Server -> PSU Initial Authoriser: HTTP 302 (Found), Redirect (authorization-code) PSU Initial Authoriser -> PISP: Follow redirect (authorization-code) PISP <-> ASPSP Authorisation Server: Establish TLS 1.2 MA PISP -> ASPSP Authorisation Server: Exchange authorization-code for access token ASPSP Authorisation Server -> PISP: access-token note over PSU Initial Authoriser, ASPSP Resource Server Step 4: Create Payment-Order end note PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA PISP -> ASPSP Resource Server: POST /domestic-payments ASPSP Resource Server -> PISP: HTTP 201 (Created) DomesticPaymentId state over ASPSP Resource Server: Consent Status: Consumed state over ASPSP Resource Server: Payment Status: Pending state over ASPSP Resource Server: MultiAuthorisation Status: AwaitingFurtherAuthorisation note over PSU Initial Authoriser, ASPSP Resource Server Step 5: Authorize Consent - Final Authoriser end note PSU Final Authoriser -> ASPSP Authorisation Server: Authenticate (SCA if required) and Authorise consent state over ASPSP Resource Server: MultiAuthorisation Status: Authorised state over ASPSP Resource Server: Payment Status: AcceptedSettlementInProcess state over ASPSP Resource Server: Payment Status: AcceptedSettlementComplete alt If PISP has registered a URL for event notification ASPSP Resource Server -> PISP: POST /event-notifications PISP -> ASPSP Resource Server: HTTP 200 (OK) PISP -> ASPSP Resource Server: GET /domestic-payments/{DomesticPaymentId} ASPSP Resource Server -> PISP: HTTP 200 (OK) domestic-payment resource else PISP may poll payment order status loop PISP -> ASPSP Resource Server: GET /domestic-payments/{DomesticPaymentId} ASPSP Resource Server -> PISP: HTTP 200 (OK) domestic-payment resource end end option footer=bar ```

This example illustrates a scenario where an ASPSP choses to Reject the Payment-Order consent/resource request, after the CutoffTime. We have a CHAPS payment-order consent created after the CutOffDateTime, and ASPSP rejects the Consent, and the PISP chooses to place a Scheduled Payment-Order consent.

Diagram source ``` autonumber participant PSU participant PISP participant ASPSP Authorisation Server participant ASPSP Resource Server note over PSU, ASPSP Resource Server Step 1: Agree Domestic Payment-Order initiation end note PSU <-> PISP: Initiate a funds transfer PSU -> PISP: Select debtor and creditor accounts note over PSU, ASPSP Resource Server Step 2: Setup Domestic Payment Consent end note PISP <-> ASPSP Authorisation Server: Establish TLS 1.2 MA PISP -> ASPSP Authorisation Server: Initiate Client Credentials Grant ASPSP Authorisation Server -> PISP: access-token PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA PISP -> ASPSP Resource Server: POST /domestic-payment-consents note over PISP, ASPSP Resource Server CHAPS Payment cutoff time expired, so consent initiation is rejected end note ASPSP Resource Server -> PISP: HTTP 400 (BAD_REQUEST) PISP -> PSU: Try setting up a Scheduled Payment note over PSU, ASPSP Resource Server Step 3: Setup Domestic Scheduled Payment Consent end note note over PSU, ASPSP Resource Server Step 4: Authorize consent end note note over PSU, ASPSP Resource Server Step 5: Create Domestic Scheduled Payment-Order end note note over PSU, ASPSP Resource Server Step 6: Get Domestic Scheduled Payment-Order status end note option footer=bar ```

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 CHAPS 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.

Diagram source ``` autonumber participant PSU participant PISP participant ASPSP Authorisation Server participant ASPSP Resource Server note over PSU, ASPSP Resource Server Step 1: Agree Domestic Payment-Order initiation end note PSU <-> PISP: Initiate a funds transfer PSU -> PISP: Select debtor and creditor accounts note over PSU, ASPSP Resource Server Step 2: Setup Domestic Payment-Order Consent end note PISP <-> ASPSP Authorisation Server: Establish TLS 1.2 MA PISP -> ASPSP Authorisation Server: Initiate Client Credentials Grant ASPSP Authorisation Server -> PISP: access-token PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA PISP -> ASPSP Resource Server: POST /domestic-payment-consents ASPSP Resource Server -> PISP: HTTP 201 (Created), ConsentId PISP -> PSU: HTTP 302 (Found), Redirect (ConsentId) note over PSU, ASPSP Resource Server Step 3: Authorize consent end note PSU -> ASPSP Authorisation Server: Follow redirect (ConsentId) PSU <-> ASPSP Authorisation Server: authenticate PSU <-> ASPSP Authorisation Server: SCA if required ASPSP Authorisation Server -> PSU: HTTP 302 (Found), Redirect (authorization-code) PSU -> PISP: Follow redirect (authorization-code) PISP <-> ASPSP Authorisation Server: Establish TLS 1.2 MA PISP -> ASPSP Authorisation Server: Exchange authorization-code for access token ASPSP Authorisation Server -> PISP: access-token note over PSU, ASPSP Resource Server Step 4: Create Domestic Payment-Order end note PISP <-> ASPSP Resource Server: Establish TLS 1.2 MA note over PISP, ASPSP Authorisation Server Delay in Redirection or User spent too long to Authorise or PISP took too long to submit Payment Order, leading to Expiry of CHAPS Cutoff Time end note PISP -> ASPSP Resource Server: POST /domestic-payments ASPSP Resource Server -> PISP: HTTP 400 (BAD_REQUEST) PISP -> PSU: Try setting up a Scheduled Payment note over PSU, ASPSP Resource Server Step 5: Setup Domestic Scheduled Payment Consent end note option footer=bar ```