Version Control

Endpoints

POST /international-scheduled-payment-consents

The API endpoint allows the PISP to ask an ASPSP to create a new international-scheduled-payment-consent resource.

• The POST action indicates to the ASPSP that an international scheduled payment 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 international-scheduled-payment-consent resource and responds with a unique ConsentId to refer to the resource.

Status

The default Status is "AwaitingAuthorisation" immediately after the international-scheduled-payment-consent has been created.

GET /international-scheduled-payment-consents/{ConsentId}

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

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 international-scheduled-payment-consent has failed some other ASPSP validation, the Status will be set to "Rejected".

Once an international-scheduled-payment has been successfully created using the international-scheduled-payment-consent, the Status of the international-scheduled-payment-consent will be set to "Consumed".

The available Status codes for the international-scheduled-payment-consent resource are:

GET /international-scheduled-payment-consents/{ConsentId}/funds-confirmation

The API endpoint allows the PISP to ask an ASPSP to confirm funds on an international-scheduled-payment-consent resource, where the payment is for immediate debit.

• An ASPSP can only respond to a funds confirmation request if the international-scheduled-payment-consent resource has an Authorised status. If the status is not Authorised, an ASPSP must respond with a 400 (Bad Request) and a UK.OBIE.Resource.InvalidConsentStatus error code.

• Confirmation of funds requests do not affect the status of the international-scheduled-payment-consent resource.

POST /international-scheduled-payments

Once the international-scheduled-payment-consent has been authorised by the PSU, the PISP can proceed to submit the international-scheduled-payment for processing:

• This is done by making a POST request to the international-scheduled-payments endpoint.

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

• The PISP must ensure that the Initiation and Risk sections of the international-scheduled-payment match the corresponding Initiation and Risk sections of the international-scheduled-payment-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 international-scheduled-payment resource will not result in a Status change for the international-scheduled-payment resource.

Status

An international-scheduled-payment can only be created if its corresponding international-scheduled-payment-consent resource has the status of "Authorised". 

The international-scheduled-payment resource that is created successfully must have one of the following Status codes:

GET /international-scheduled-payments/{InternationalScheduledPaymentId}

A PISP can retrieve the international-scheduled-payment to check its status.

Status

The international-scheduled-payment resource must have one of the following Status codes:

GET /international-scheduled-payments/{InternationalScheduledPaymentId}/payment-details

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.

Status

The international-scheduled-payments - payment-details must have one of the following PaymentStatusCode code-set enumerations:

State Model

Payment Order Consent

The state model for the international-scheduled-payment-consent resource follows the generic consent state model. However, does not use the "Revoked" status, as the consent for an international-scheduled-payment is not a long-lived consent.

Open

The definitions for the Status:

Payment Order

The state model for the international-scheduled-payment resource describes the initiation status only. I.e., not the subsequent execution of the international-scheduled-payment.

Open

The definitions for the Status:

Multiple Authorisation

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:

Data Model

The data dictionary section gives the detail on the payload content for the International Scheduled Payment API flows.

Reused Classes

OBInternationalScheduled2

This section describes the OBInternationalScheduled2 class which is reused as the Initiation object in the international-scheduled-payment-consent and international-scheduled-payment resources.

UML Diagram

Open

Notes

For the OBInternationalScheduled2 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 international-scheduled-payment-consent consent request immediately.

• If the ASPSP establishes a problem with the international-scheduled-payment-consent after the API call, the ASPSP must set the Status of the international-scheduled-payment-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 international-scheduled-payment-consent will be set to Rejected after PSU authentication.

• CreditorAgent must at least have either of the pairs provided: SchemeName and Identification, or Name and PostalAddress.

• Account Identification field usage:

  • SchemeName is a free-text field which will be populated with identification schemes an ASPSP accepts.

  • Identification is a field which is populated with the Identification of the account, using the valid identification scheme provided.

• Valid UK Account Identification SchemeName values include, but are not restricted to:

  • "UK.OBIE.SortCodeAccountNumber" - Identification field must be populated with the 6 digit Sort Code and 8 digit Account Number (a 14 digit field).

  • "UK.OBIE.IBAN" - The Identification field must be populated with the full IBAN.

  • "UK.OBIE.PAN" - The Identification field must be populated with the full PAN. A PAN may be an instrument (e.g., a debit card) linked to a payment account, and may not be the only PAN linked to the payment account.

  • "UK.OBIE.Paym" - The Identification field must be populated with the Paym proxy value.

• LocalInstrument is the requested payment scheme for execution. This is a free-text field.

• InstructionPrioirty may be used by the ASPSP to determine the payment scheme for execution. 

• The InstructedAmount object must be populated with the desired Amount and Currency of transfer, regardless of the currency of the DebtorAccount. I.e., a PSU may wish to transfer 100EUR from a GBP DebtorAccount (the InstructedAmount will be 100EUR), or 100GBP in EUR (the InstructedAmount will be 100GBP).

• The CurrencyOfTransfer must be used to specify the currency the funds will be transferred. I.e., a PSU may wish to transfer 100USD from a GBP DebtorAccount to a Rupee INR CreditorAccount in India.

• The ChargeBearer field is used by the PISP to indicate the bearer of charges. An ASPSP must Reject the Initiation request if the requested charge allocation cannot be fulfilled.

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

• RequestedExecutionDateTime allows a PISP to specify the date for an ASPSP to execute the international scheduled payment.

The ExchangeRateInformation object must conform to these behaviours:

• A PISP must specify the DebtorAccount currency in the UnitCurrency field if the PISP is requesting a specific RateType so the ASPSP can respond with an exchange rate quote prior to PSU authorisation.

• A PISP may indicate an exchange rate request using the RateType with these enumerations:

  • Actual.

  • Agreed.

  • Indicative.

• A PISP must specify ExchangeRate and ContractIdentification when requesting an Agreed RateType. If an invalid ContractIdentification and ExchangeRate are requested together, an ASPSP must reject the request.

  • For an "Agreed" RateType - a requested exchange rate is populated in the ExchangeRate field, against the UnitCurrency. I.e, if the UnitCurrency is GBP and CurrencyOfTransfer is USD, then ExchangeRate will be 1.34 (USD to 1 GBP).

  • For an "Agreed" RateType - the exchange rate contract identifier is populated in the ContractIdentification field.

• A PISP must not specify ExchangeRate and/or ContractIdentification when requesting an Actual RateType.

• A PISP must not specify ExchangeRate and/or ContractIdentification when requesting an Indicative RateType.

Data Dictionary