File Payment Consents - v3.1.2

  1. Overview
  2. Endpoints
    1. POST /file-payment-consents
      1. Status
    2. POST /file-payment-consents/{ConsentId}/file
      1. Status
    3. GET /file-payment-consents/{ConsentId}
      1. Status
    4. GET /file-payment-consents/{ConsentId}/file
    5. State Model
      1. Payment Order Consent
  3. Data Model
    1. Reused Classes
      1. OBFile2
        1. UML Diagram
        2. Notes
        3. Data Dictionary
    2. File Payment Consent - Request
      1. UML Diagram
      2. Notes
      3. Data Dictionary
    3. File Payment Consent - Response
      1. UML Diagram
      2. Notes
      3. Data Dictionary
  4. Usage Examples
    1. POST /file-payment-consents
      1. Request
      2. Response
    2. POST /file-payment-consents/{ConsentId}/file
      1. Request
      2. Response

Overview

The File Payment Consent resource is used by a PISP to register an intent to initiate a File Payment.

This resource description should be read in conjunction with a compatible Payment Initiation API Profile.

Endpoints

ResourceHTTP OperationEndpointMandatory ?ScopeGrant TypeMessage SigningIdempotency KeyRequest ObjectResponse Object
file-payment-consentsPOSTPOST /file-payment-consentsConditionalpaymentsClient CredentialsSigned Request Signed ResponseYesOBWriteFileConsent3OBWriteFileConsentResponse3
file-payment-consentsPOSTPOST /file-payment-consents/{ConsentId}/fileConditionalpaymentsClient CredentialsSigned Request Signed ResponseYesFileNA
file-payment-consentsGETGET /file-payment-consents/{ConsentId}Mandatory (if resource POST implemented)paymentsClient CredentialsSigned ResponseNoNAOBWriteFileConsentResponse3
file-payment-consentsGETGET /file-payment-consents/{ConsentId}/fileConditionalpaymentsClient CredentialsSigned ResponseNoNAFile

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
AwaitingUpload

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
AwaitingAuthorisation

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
AwaitingUpload
AwaitingAuthorisation
Rejected
Authorised
Consumed

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.

State Model

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.

 image2018-7-5_15-37-22.png

The definitions for the Status:

 StatusStatus Description
1AwaitingUploadThe file for the consent resource is awaiting upload.
2AwaitingAuthorisationThe consent resource is awaiting PSU authorisation.
3RejectedThe consent resource has been rejected.
4AuthorisedThe consent resource has been successfully authorised.
5ConsumedThe consented action has been successfully completed. This does not reflect the status of the consented action.

Data Model

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

Reused Classes

OBFile2

This section describes the OBFile2 class, which is reused as the Initiation object in the file-payment-consent resource.

UML Diagram

OBFile2

Notes

For the OBFile2 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 file-payment-consent request immediately.
  • If the ASPSP establishes a problem with the file-payment-consent after the API call, the ASPSP must set the Status of the file-payment-consent resource to Rejected.
  • The 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 file-payment-consent will be set to Rejected after PSU authentication.
  • An ASPSP may choose which fields must be populated to process a specified FileType, and may reject the request if the fields are not populated. These ASPSP specific requirements must be documented.
  • An ASPSP may choose which fields must not be populated to process a specified FileType, and may reject the request if the fields are populated. These ASPSP specific requirements must be documented.
Data Dictionary
NameOccurrenceXPathEnhancedDefinitionClassCodesPattern
OBFile2 OBFile2The Initiation payload is sent by the initiating party to the ASPSP. It is used to request movement of funds using a payment file.OBFile2  
FileType1..1OBFile2/FileTypeSpecifies the payment file type.Max40Text  
FileHash1..1OBFile2/FileHashA base64 encoding of a SHA256 hash of the file to be uploaded.Max44Text  
FileReference0..1OBFile2/FileReferenceReference for the file.Max40Text  
NumberOfTransactions0..1OBFile2/NumberOfTransactionsNumber of individual transactions contained in the payment information group.Max15NumericText [0-9]{1,15}
ControlSum0..1OBFile2/ControlSumTotal of all individual amounts included in the group, irrespective of currencies.DecimalNumber  
RequestedExecutionDateTime0..1OBFile2/RequestedExecutionDateTimeDate at which the initiating party requests the clearing agent to process the payment. Usage: This is the date on which the debtor’s account is to be debited.ISODateTime  
LocalInstrument0..1OBFile2/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  
DebtorAccount0..1OBFile2/DebtorAccountUnambiguous identification of the account of the debtor to which a debit entry will be made as a result of the transaction.OBCashAccountDebtor4  
SchemeName1..1OBFile2/DebtorAccount/SchemeNameName of the identification scheme, in a coded form as published in an external list.OBExternalAccountIdentification4Code  
Identification1..1OBFile2/DebtorAccount/IdentificationIdentification assigned by an institution to identify an account. This identification is known by the account owner.Max256Text  
Name0..1OBFile2/DebtorAccount/NameThe account name is the name or names of the account owner(s) represented at an account level, as displayed by the ASPSP’s online channels. Note, the account name is not the product name or the nickname of the account.Max70Text  
SecondaryIdentification0..1OBFile2/DebtorAccount/SecondaryIdentificationThis is secondary identification of the account, as assigned by the account servicing institution. This can be used by building societies to additionally identify accounts with a roll number (in addition to a sort code and account number combination).Max34Text  
RemittanceInformation0..1OBFile2/RemittanceInformationInformation supplied to enable the matching of an entry with the items that the transfer is intended to settle, such as commercial invoices in an accounts’ receivable system.OBRemittanceInformation1  
Unstructured0..1OBFile2/RemittanceInformation/UnstructuredInformation supplied to enable the matching/reconciliation of an entry with the items that the payment is intended to settle, such as commercial invoices in an accounts’ receivable system, in an unstructured form.Max140Text  
Reference0..1OBFile2/RemittanceInformation/ReferenceUnique reference, as assigned by the creditor, to unambiguously refer to the payment transaction. Usage: If available, the initiating party should provide this reference in the structured remittance information, to enable reconciliation by the creditor upon receipt of the amount of money. If the business context requires the use of a creditor reference or a payment remit identification, and only one identifier can be passed through the end-to-end chain, the creditor’s reference or payment remittance identification should be quoted in the end-to-end transaction identification. OB: The Faster Payments Scheme can only accept 18 characters for the ReferenceInformation field - which is where this ISO field will be mapped.Max35Text  
SupplementaryData0..1OBFile2/SupplementaryDataAdditional information that can not be captured in the structured fields and/or any other specific block.OBSupplementaryData1  

The OBWriteFileConsent3 object will be used for the call to:

  • POST /file-payment-consents

UML Diagram

OBWriteFileConsent3

Notes

The file-payment-consent request contains these objects:

  • Initiation
  • Authorisation
  • SCASupportData

For the file-payment-consent request object:

  • There is no Risk section in the OBWriteFileConsent3 object - as this is not relevant for a file payment.

Data Dictionary

NameOccurrenceXPathEnhancedDefinitionClassCodesPattern
OBWriteFileConsent3 OBWriteFileConsent3 OBWriteFileConsent3  
Data1..1OBWriteFileConsent3/Data OBWriteDataFileConsent3  
Initiation1..1OBWriteFileConsent3/Data/InitiationThe Initiation payload is sent by the initiating party to the ASPSP. It is used to request movement of funds using a payment file.OBFile2  
Authorisation0..1OBWriteFileConsent3/Data/AuthorisationThe authorisation type request from the TPP.OBAuthorisation1  
SCASupportData0..1OBWriteFileConsent3/Data/SCASupportDataSupporting Data provided by TPP, when requesting SCA Exemption.OBSCASupportData1  

The OBWriteFileConsentResponse3 object will be used for a response to a call to:

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

UML Diagram

OBWriteFileConsentResponse3

Notes

The file-payment-consent response contains the full original payload from the file-payment-consent request with these additional elements:

  • ConsentId.
  • CreationDateTime the file-payment-consent resource was created.
  • Status and StatusUpdateDateTime of the file-payment-consent resource.
  • CutOffDateTime Behaviour is explained in Payment Initiation API Profile, Section - Payment Restrictions -> CutOffDateTime Behaviour.
  • Charges array - for the breakdown of applicable ASPSP charges.

Data Dictionary

NameOccurrenceXPathEnhancedDefinitionClassCodesPattern
OBWriteFileConsentResponse3 OBWriteFileConsentResponse3 OBWriteFileConsentResponse3  
Data1..1OBWriteFileConsentResponse3/Data OBWriteDataFileConsentResponse3  
ConsentId1..1OBWriteFileConsentResponse3/Data/ConsentIdOB: Unique identification as assigned by the ASPSP to uniquely identify the consent resource.Max128Text  
CreationDateTime1..1OBWriteFileConsentResponse3/Data/CreationDateTimeDate and time at which the resource was created.ISODateTime  
Status1..1OBWriteFileConsentResponse3/Data/StatusSpecifies the status of consent resource in code form.OBExternalConsentStatus2CodeAuthorised AwaitingAuthorisation AwaitingUpload Consumed Rejected 
StatusUpdateDateTime1..1OBWriteFileConsentResponse3/Data/StatusUpdateDateTimeDate and time at which the consent resource status was updated.ISODateTime  
CutOffDateTime0..1OBWriteFileConsentResponse3/Data/CutOffDateTimeSpecified cut-off date and time for the payment consent.ISODateTime  
Charges0..nOBWriteFileConsentResponse3/Data/ChargesSet of elements used to provide details of a charge for the payment initiation.OBCharge2  
Initiation1..1OBWriteFileConsentResponse3/Data/InitiationThe Initiation payload is sent by the initiating party to the ASPSP. It is used to request movement of funds using a payment file.OBFile2  
Authorisation0..1OBWriteFileConsentResponse3/Data/AuthorisationThe authorisation type request from the TPP.OBAuthorisation1  
SCASupportData0..1OBWriteFileConsentResponse3/Data/SCASupportDataSupporting Data provided by TPP, when requesting SCA Exemption.OBSCASupportData1  

Usage Examples

POST /file-payment-consents

Request

POST /file-payment-consents HTTP/1.1
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
x-idempotency-key: FRESCO.21302.GFX.20
x-jws-signature: TGlmZSdzIGEgam91cm5leSBub3QgYSBkZXN0aW5hdGlvbiA=..T2ggZ29vZCBldmVuaW5nIG1yIHR5bGVyIGdvaW5nIGRvd24gPw==
x-fapi-auth-date: Sun, 10 Sep 2017 19:43:31 UTC
x-fapi-customer-ip-address: 104.25.212.99
x-fapi-interaction-id: 93bac548-d2de-4546-b106-880a5018460d
Content-Type: application/json
Accept: application/json
{
  "Data": {
    "Initiation": {
      "FileType": "UK.OBIE.pain.001.001.08",
      "FileHash": "m5ah/h1UjLvJYMxqAoZmj9dKdjZnsGNm+yMkJp/KuqQ",
      "FileReference": "GB2OK238",
      "NumberOfTransactions": "100",
      "ControlSum": 3459.30
    }
  }
}

Response

HTTP/1.1 201 Created
x-jws-signature: V2hhdCB3ZSBnb3QgaGVyZQ0K..aXMgZmFpbHVyZSB0byBjb21tdW5pY2F0ZQ0K
x-fapi-interaction-id: 93bac548-d2de-4546-b106-880a5018460d
Content-Type: application/json
{
  "Data": {
    "ConsentId" : "512345",
    "Status": "AwaitingUpload",
    "CreationDateTime": "2018-06-05T15:15:13+00:00",
    "StatusUpdateDateTime": "2018-06-05T15:15:13+00:00",
    "Initiation": {
      "FileType": "UK.OBIE.pain.001.001.08",
      "FileHash": "m5ah/h1UjLvJYMxqAoZmj9dKdjZnsGNm+yMkJp/KuqQ",
      "FileReference": "GB2OK238",
      "NumberOfTransactions": "100",
      "ControlSum": 3459.30
    }
  },
  "Links":{
    "Self":"https://api.alphabank.com/open-banking/v4.0/pisp/file-payment-consents/512345"
  },
  "Meta":{}
}

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

Request

POST /file-payment-consents/512345/file HTTP/1.1
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
x-idempotency-key: FRESCO.21302.GFX.20
x-jws-signature: TGlmZSdzIGEgam91cm5leSBub3QgYSBkZXN0aW5hdGlvbiA=..T2ggZ29vZCBldmVuaW5nIG1yIHR5bGVyIGdvaW5nIGRvd24gPw==
x-fapi-auth-date: Sun, 10 Sep 2017 19:43:31 UTC
x-fapi-customer-ip-address: 104.25.212.99
x-fapi-interaction-id: 93bac548-d2de-4546-b106-880a5018460d
Content-Type: text/xml
Accept: application/json

[File-Data]

A sample file with 3 transactions is provided below:

File Data Expand source ```xml ABC/120928/CCT001 2012-09-28T14:07:00 3 11500000 ABC Corporation Times Square 7 NY 10036 New York US ABC/086 TRF false
2012-09-29 ABC Corporation Times Square 7 NY 10036 New York US 00125574999 BBBBUS33 ABC/120928/CCT001/01 ABC/4562/2012-09-08 10000000 SHAR AAAAGB2L DEF Electronics Corn Exchange 5th Floor Mark Lane 55 EC3R7NE London GB 23683707994125 GDDS CINV 4562 2012-09-08 ABC/120928/CCT001/2 ABC/ABC-13679/2012-09-15 500000 CRED DDDDBEBB GHI Semiconductors Avenue Brugmann 415 1180 Brussels BE BE30001216371411 PHOB +32/2/2222222 GDDS CINV ABC-13679 2012-09-15 ABC/120928/CCT001/3 ABC/987-AC/2012-09-27 1000000 SHAR BBBBUS66 ABC Corporation Treasury department Bush Street 13 CA 94108 San Francisco US 4895623 INTC CINV 987-AC 2012-09-27 ```

Response

HTTP/1.1 200 OK
x-fapi-interaction-id: 93bac548-d2de-4546-b106-880a5018460d