The API endpoint allows the PISP to ask an ASPSP to create a new domestic-standing-order-consent resource.

• The POST action indicates to the ASPSP that a domestic standing order consent has been staged. At this point, the PSU may not have been identified by the ASPSP, and the request payload may not contain any information of the account that should be debited.

• The endpoint allows the PISP to send a copy of the consent (between PSU and PISP) to the ASPSP for the PSU to authorise.

• The ASPSP creates the domestic-standing-order-consent resource and responds with a unique ConsentId to refer to the resource.

The default Status is "AwaitingAuthorisation" immediately after the domestic-standing-order-consent has been created.

A PISP can optionally retrieve a payment consent resource that they have created to check its status. 

Once the PSU authorises the payment-consent resource , the Status of the payment-consent resource will be updated with "Authorised".

If the PSU rejects the consent or the domestic-standing-order-consent has failed some other ASPSP validation, the Status will be set to "Rejected".

Once a domestic-standing-order has been successfully created using the domestic-standing-order-consent, the Status of the domestic-standing-order-consent will be set to "Consumed".

The available Status codes for the domestic-standing-order-consent resource are:

Once the domestic-standing-order-consent has been authorised by the PSU, the PISP can proceed to submitting the domestic-standing-order for processing:

• This is done by making a POST request to the domestic-standing-orders endpoint.

• This request is an instruction to the ASPSP to begin the domestic standing order journey. The PISP must submit the domestic standing order immediately, however, there are some scenarios where the ASPSP may not warehouse the domestic standing order immediately (e.g. busy periods at the ASPSP).

• The PISP must ensure that the Initiation and Risk sections of the domestic-standing-order match the corresponding Initiation and Risk sections of the domestic-standing-order-consent resource. If the two do not match, the ASPSP must not process the request and must respond with a 400 (Bad Request).

• Any operations on the domestic-standing-order resource will not result in a Status change for the domestic-standing-order resource.

A domestic-standing-order can only be created if its corresponding domestic-standing-order-consent resource has the status of "Authorised". 

The domestic-standing-order resource that is created successfully must have one of the following Status codes:

A PISP can retrieve the domestic-standing-order to check its status.

The domestic-standing-order resource must have one of the following Status codes:

A PISP can retrieve the Details of the underlying payment transaction via this endpoint. This resource allows ASPSPs to return richer list of Payment Statuses, and if available payment scheme related statuses.

The domestic-standing-orders - payment-details must have one of the following PaymentStatusCode code-set enumerations:

The state model for the domestic-standing-order-consent resource follows the generic consent state model. However, does not use the "Revoked" status, as the consent for a domestic-standing-order is not a long-lived consent.

Open

The definitions for the Status:

The state model for the domestic-standing-order resource describes the initiation status only. I.e., not the subsequent execution of the domestic-standing-order.

Open

The definitions for the Status:

If the payment-order requires multiple authorisations, the Status of the multiple authorisations will be updated in the MultiAuthorisation object.

Open

The definitions for the Status:

The Data Dictionary section gives the detail on the payload content for the Domestic Standing Order API flows.

This section describes the OBDomesticStandingOrder3 class, which is reused as the Initiation object in the domestic-standing-order-consent and domestic-standing-order resources.

Open

For the OBDomesticStandingOrder3 Initiation object: 

• All elements in the Initiation payload that are specified by the PISP must not be changed via the ASPSP, as this is part of formal consent from the PSU.

• If the ASPSP is able to establish a problem with payload or any contextual error during the API call, the ASPSP must reject the domestic-standing-order-consent request immediately.

• If the ASPSP establishes a problem with the domestic-standing-order-consent after the API call, the ASPSP can set the Status of the domestic-standing-order-consent resource to Rejected

• DebtorAccount is optional as the PISP may not know the account identification details for the PSU.

• If the DebtorAccount is specified by the PISP and is invalid for the PSU, then the domestic-standing-order-consent will be set to Rejected after PSU authentication.

• Account Identification field usage:

  • Where "UK.OBIE.SortCodeAccountNumber" is specified as the SchemeName in the Account identification section (either DebtorAccount or CreditorAccount), the Identification field must be populated with the 6 digit Sort Code and 8 digit Account Number (a 14 digit field).

  • Where the "UK.OBIE.IBAN" is specified as the SchemeName in the Account identification section (either DebtorAccount or CreditorAccount), the Identification field must be populated with the full IBAN.

• The Permission field is restricted to "Create", however, may be extended to "Update" and "Delete" in a future iteration of the specification.

• Either the NumberOfPayments or FinalPaymentDateTime must be specified (not both) if the domestic standing order is not open ended.

• The structure allows a PISP to specify a domestic standing order with a different payment amount and date combinations: for the first payment, the recurring payment, and the final payment. The recurring payment (and date) must only be populated if different from the first payment (and date).

• If the PISP requests a Frequency that is not supported by the ASPSP the ASPSP must respond with a 400 HTTP status code.