1 Version Control
2 Basics
- 2.1 Overview
  - 2.1.1 Steps
  - 2.1.2 Sequence Diagram
3 Endpoints
- 3.1 POST /file-payment-consents
  - 3.1.1 Status
- 3.2 POST /file-payment-consents/{ConsentId}/file
  - 3.2.1 Status
- 3.3 GET /file-payment-consents/{ConsentId}
  - 3.3.1 Status
- 3.4 GET /file-payment-consents/{ConsentId}/file
- 3.5 POST /file-payments
- 3.6 GET /file-payments/{FilePaymentId}
  - 3.6.1 Status
- 3.7 GET /file-payments/{FilePaymentId}/report-file
- 3.8 GET /file-payments/{FilePaymentId}/payment-details
  - 3.8.1 Status
- 3.9 State Model
  - 3.9.1 Payment Order Consent
  - 3.9.2 Payment Order
    - 3.9.2.1 Multiple Authorisation
4 Data Model
- 4.1 Reused Classes
  - 4.1.1 OBFile2
    - 4.1.1.1 UML Diagram
    - 4.1.1.2 Notes
    - 4.1.1.3 Data Dictionary
- 4.2 File Payment Consent - Request
  - 4.2.1 UML Diagram
  - 4.2.2 Notes
  - 4.2.3 Data Dictionary
- 4.3 File Payment Consent - Response
  - 4.3.1 UML Diagram
  - 4.3.2 Notes
  - 4.3.3 Data Dictionary
- 4.4 File Payment - Request
  - 4.4.1 UML Diagram
  - 4.4.2 Notes
  - 4.4.3 Data Dictionary
- 4.5 File Payment - Response
  - 4.5.1 UML Diagram
  - 4.5.2 Notes
  - 4.5.3 Data Dictionary
- 4.6 Domestic Payment Order - Payment Details - Response
  - 4.6.1 UML Diagram
  - 4.6.2 Data Dictionary
- 4.7 Setup File Payment Consent
  - 4.7.1 Request Payload
  - 4.7.2 Response Payload
- 4.8 Upload File to for the File Payment Consent
  - 4.8.1 Request Payload
  - 4.8.2 Response Payload
- 4.9 Submit the File Payment after Authorisation
  - 4.9.1 Request Payload
  - 4.9.2 Response Payload
- 4.10 Upload File in the UK.OBIE.PaymentInitiation.4.0 format to the File Payment Consent
  - 4.10.1 Request Payload
  - 4.10.2 Response Payload

Version Control

Version	Date	Author	Comments

Version	Date	Author	Comments
3.1	Dec 3, 2018	OB R/W API Team	This is the baseline version.
v4.0-draft1	Dec 13, 2018	OB R/W API Team	Errata: Reference to "international-scheduled-payment" resource corrected to "file-payment".
v4.0-draft6	Feb 25, 2019	OB R/W API Team	v4.0-draft6 changes: Corrected consent request and response payloads Updated Account Name definition.
4.0-draft7	Mar 8, 2019	OB R/W API Team	v4.0-draft7 changes: Added Payment Status details endpoint, Data Model, and underlying Status enumerations Added SCASupportData element to File Payment Consent, to enable PISPs to provide Supporting Data, when requesting SCA Exemption Changes for alignment with FAPI Implementer's Draft 2 Replace references of `x-fapi-customer-last-logged-time` to `x-fapi-auth-date` Remove references of x-fapi-financial-id

Basics

Overview

File Payments allow a file of payments to be uploaded to an ASPSP for payment initiation.

The high-level flow for file-payments follow the flow for all other payment-order types (as described in the Basic > Overview Section of Payment Initiation API Specification) however, with an additional step to upload the file. The step for staging the payment-order consent is broken into two steps:

POST metadata of the file-payment for payment initiation.
POST the file of the file-payment for payment initiation.

Steps

Step 1: Agree File Payment-Order Initiation.

Step 2a: Setup File Payment-Order Consent (Metadata):

The PISP connects to the ASPSP that services the PSU's payment account and creates a new file-payment-consent resource. This JSON message contains the Metadata of the file payments file. The ASPSP responds with a ConsentId.
This step is carried out by making a POST request to the file-payment-consent resource.

Step 2b: Setup File Payment-Order Consent (Upload File):

The PISP uploads the payment file to the file-payment-consent endpoint with ConsentId obtained in Step 2a.
ASPSP verifies the payment file against the hash of payment file received in the file-payment-consent Metadata in Step 2a.
ASPSP responds with 200 OK.
This step completes the file-payment-consent creation.

Step 3: Authorise Consent.

Step 4: Create Payment-Order.

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

A PISP may optionally request the Status of the file-payment-consent.
A PISP may optionally request File uploaded to file-payment-consent, for verification.
A PISP may optionally request the Status of the file-payment.
A PISP may optionally request a report in a file format, on the status of the individual payments in file-payments, if the ASPSP makes this available.
A PISP may optionally request the detail status of the individual payments in file-payments, if the ASPSP makes this available.

Sequence Diagram

participant PSU
participant PISP
participant ASPSP Authorisation Server
participant ASPSP Resource Server

note over PSU, ASPSP Resource Server
Step 1: Agree File Payment-Order Initiation
end note

note over PSU, ASPSP Resource Server
Step 2: Setup Agree File Payment-Order Consent
end note
PISP -> ASPSP Authorisation Server: Initiate Client Credentials Grant
ASPSP Authorisation Server -> PISP: access-token
note right of PISP
   Step 2a: Setup File Payment-Order Consent (Metadata, including Hash)
end note
PISP -> ASPSP Resource Server: POST /file-payment-consents
state over ASPSP Resource Server: Consent Status: AwaitingUpload
ASPSP Resource Server -> PISP: HTTP 201 (Created),  ConsentId
note right of PISP
   Step 2b: Upload File using Consent Id
end note
PISP -> ASPSP Resource Server: POST /file-payment-consents/{ConsentId}/file
state over ASPSP Resource Server: Consent Status: AwaitingAuthorisation
ASPSP Resource Server -> PISP: HTTP 200 (OK)
PISP -> PSU: HTTP 302 (Found), Redirect (ConsentId)

note over PSU, ASPSP Resource Server
Step 3: Authorize File Payment-Order Consent
end note
note over PSU, ASPSP Resource Server
Step 4: Create File Payment-Order
end note

note over PSU, ASPSP Resource Server
Step 5: Get File Payment Consent Status/ Payment File/ File Payment Status/ Payment Report File/ File Payment-Payment Details Status
end note

opt File Payment consent
PISP -> ASPSP Resource Server: GET /file-payment-consents/{ConsentId}
ASPSP Resource Server -> PISP: HTTP 200 (OK) file-payment-consent resource
end opt

opt File uloaded with File Payment consent
PISP -> ASPSP Resource Server: GET file-payment-consents/{ConsentId}/file
ASPSP Resource Server -> PISP: HTTP 200 (OK) file resource
end opt

opt File Payment status
PISP -> ASPSP Resource Server: GET /file-payments/{FilePaymentId}
ASPSP Resource Server -> PISP: HTTP 200 (OK) file-payment resource
end opt

opt File Payment report file
PISP -> ASPSP Resource Server: GET /file-payments/{FilePaymentId}/report-file
ASPSP Resource Server -> PISP: HTTP 200 (OK) file resource
end opt

opt Payment Status File Payment
PISP -> ASPSP Resource Server: GET /file-payments/{FilePaymentId}/payment-details
ASPSP Resource Server -> PISP: HTTP 200 (OK) file resource
end opt

option footer=bar

Endpoints

Resource	HTTP Operation	Endpoint	Mandatory ?	Scope	Grant Type	Message Signing	Idempotency Key	Request Object	Response Object

Resource	HTTP Operation	Endpoint	Mandatory ?	Scope	Grant Type	Message Signing	Idempotency Key	Request Object	Response Object
file-payment-consents	POST	POST /file-payment-consents	Conditional	payments	Client Credentials	Signed Request Signed Response	Yes	OBWriteFileConsent3	OBWriteFileConsentResponse3
file-payment-consents	POST	POST /file-payment-consents/{ConsentId}/file	Conditional	payments	Client Credentials	Signed Request Signed Response	Yes	File	NA
file-payment-consents	GET	GET /file-payment-consents/{ConsentId}	Mandatory (if resource POST implemented)	payments	Client Credentials	Signed Response	No	NA	OBWriteFileConsentResponse3
file-payment-consents	GET	GET /file-payment-consents/{ConsentId}/file	Conditional	payments	Client Credentials	Signed Response	No	NA	File
file-payments	POST	POST /file-payments	Conditional	payments	Authorization Code	Signed Request Signed Response	Yes	OBWriteFile2	OBWriteFileResponse2
file-payments	GET	GET /file-payments/{FilePaymentId}	Mandatory (if resource POST implemented)	payments	Client Credentials	Signed Response	No	NA	OBWriteFileResponse2
file-payments	GET	GET /file-payments/{FilePaymentId}/report-file	Conditional	payments	Client Credentials	Signed Response	No	NA	File
payment-details	GET	GET /file-payments/{FilePaymentId}/payment-details	Optional	payments	Client Credentials	Signed Response	No	NA	OBWritePaymentDetailsResponse1

POST /file-payment-consents

POST /file-payment-consents

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

The POST action indicates to the ASPSP that a file 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(s) that should be debited.
The endpoint allows the PISP to send metadata of the consent (between PSU and PISP) to the ASPSP.
The metadata of the consent must include the FileType of the request.
The metadata of the consent must include the FileHash, which is a base64 encoding of a SHA256 hash of the file to be uploaded.
The ASPSP creates the file-payment-consent resource and responds with a unique ConsentId to refer to the resource.

Status

The default Status is "AwaitingUpload" immediately after the file-payment-consent has been created.

Status

Status
AwaitingUpload

POST /file-payment-consents/{ConsentId}/file

POST /file-payment-consents/{ConsentId}/file

The API endpoint allows the PISP to upload a file to an ASPSP, against a file-payment-consent resource.

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 PISP must upload the file against the ConsentId before redirecting the PSU to authorise the consent.
The file structure must match the FileType in the file-payment-consent request.
An ASPSP must confirm the hash of the file matches with the FileHash provided in the file-payment-consent Metadata.
The metadata for the file-payment-consent must match the contents of the uploaded file:
- If the content of the metadata does not match the content of the file, the ASPSP must reject the file-payment-consent.
The file is sent in the HTTP request body.
HTTP headers (e.g. Content-Type) are used to describe the file.

Status

The default Status is "AwaitingAuthorisation" immediately after the file has been uploaded.

Status

Status
AwaitingAuthorisation

GET /file-payment-consents/{ConsentId}

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

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

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

Status

Status
AwaitingUpload
AwaitingAuthorisation
Rejected
Authorised
Consumed

GET /file-payment-consents/{ConsentId}/file

GET /file-payment-consents/{ConsentId}/file

The API endpoint allows the PISP to download a file (that had been uploaded against a file-payment-consent resource) from an ASPSP.

The file is sent in the HTTP response body.
HTTP headers (e.g. Content-Type) are used to describe the file.

POST /file-payments

POST /file-payments

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

This is done by making a POST request to the file-payments endpoint.
This request is an instruction to the ASPSP to begin the file payment journey. The PISP must submit the file payment immediately, however, there are some scenarios where the ASPSP may not stage the file payment immediately (e.g. busy periods at the ASPSP).
The PISP must ensure that the Initiation section of the file-payment match the corresponding Initiation section of the file-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 file-payment resource will not result in a Status change for the file-payment resource.

The file-payments resource that is created successfully, must have one of the following Status codes:

Status

Status
InitiationPending
InitiationFailed
InitiationCompleted

GET /file-payments/{FilePaymentId}

GET /file-payments/{FilePaymentId}

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

Status

The file-payments resource must have one of the following Status codes:

Status

Status
InitiationPending
InitiationFailed
InitiationCompleted

GET /file-payments/{FilePaymentId}/report-file

GET /file-payments/{FilePaymentId}/report-file

The API endpoint allows the PISP to download a payment report file from an ASPSP.

This endpoint enables ASPSP to return a report on the processing results of Payments in the file
The file is sent in the HTTP response body.
The file structure may match a payment execution report for the corresponding FileType in the file-payment-consent request.
HTTP headers (e.g. Content-Type) are used to describe the file.

GET /file-payments/{FilePaymentId}/payment-details

GET /file-payments/{FilePaymentId}/payment-details

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

Status

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

Status

Status
Accepted
AcceptedCancellationRequest
AcceptedTechnicalValidation
AcceptedCustomerProfile
AcceptedFundsChecked
AcceptedWithChange
Pending
Rejected
AcceptedSettlementInProcess
AcceptedSettlementCompleted
AcceptedWithoutPosting
AcceptedCreditSettlementCompleted
Cancelled
NoCancellationProcess
PartiallyAcceptedCancellationRequest
PartiallyAcceptedTechnicalCorrect
PaymentCancelled
PendingCancellationRequest
Received
RejectedCancellationRequest

State Model

Payment Order Consent

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

The definitions for the Status:

	Status	Status Description

	Status	Status Description
1	AwaitingUpload	The file for the consent resource is awaiting upload.
2	AwaitingAuthorisation	The consent resource is awaiting PSU authorisation.
3	Rejected	The consent resource has been rejected.
4	Authorised	The consent resource has been successfully authorised.
5	Consumed	The consented action has been successfully completed. This does not reflect the status of the consented action.

Payment Order

The state model for the file-payments resource describes the initiation status only. I.e., not the subsequent execution of the file-payments.

The definitions for the Status:

	Status	Payment Status Description

	Status	Payment Status Description
1	InitiationPending