| Table of Contents | ||||
|---|---|---|---|---|
|
1. 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:
...
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.
1.1. Document Document Overview
This document consists of the following parts:
...
Alternative Flows: Documents rules for alternative flows
1.2. Resources 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:
...
1.3. Design Principles
1.3.1 1 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.
2. Basics
2.1. 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:
...
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.
...
2.1.1 1 Steps
Step 1: Agree Payment-Order Initiation
...
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
2.1.2 2 Sequence Diagram
...
2.2. Payment Restrictions
...
An ASPSP must reject the payment-order consent if the ASPSP is unable to handle the request.
2.2.1 1 CutOffDateTime Behaviour
An ASPSP may return the specific CutOffDateTime when responding to a payment-order consent request.
...
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
2.2.1.1 1 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 authorisation 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 future dated payment endpoint to create a new payment-order consent. The PISP may use the /domestic-future-dated-payment-consents endpoint to create a consent for the same payment for the next working day.
2.2.1.2 2 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 authorisation 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
...
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.
2.3.1 Payment1 Payment-Order Consent
2.3.1.1 1 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
2.3.1.2 2 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
2.3.2 2 Payment-Order Consent (Confirm Funds)
2.3.2.1 GET1 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.
2.3.3 3 Payment-Order Resource
2.3.3.1 POST1 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
2.3.3.2 GET2 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, which 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).
3. Security & Access Control
3.1. Scopes
The access tokens required for accessing the Payment APIs must have at least the following scope:
payments: Generic payment scope
3.2. 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 authorisation 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 Authorisation Code".
PISPs must use a client credentials grant to obtain a token to make GET requests (excluding confirming funds).
3.3. Consent Authorisation
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.
...
The ASPSP responds with a ConsentId. This is the intent-id that is used when initiating the authorization authorisation code grant.
As part of the authorization authorisation 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.
3.3.1 1 Error Condition
If the PSU does not complete a successful consent authorisation (e.g., if the PSU has not authenticated successfully), the authorization authorisation code grant ends with a redirection to the TPP with an error response. The PSU is redirected to the TPP with an error parameter indicating the error that occurred.
3.3.2 Consent 2 Consent Revocation
A PSU cannot revoke a payment-order consent once it has been authorizedauthorised.
3.3.3 Changes 3 Changes to Selected Account
For a payment-order consent, the selected debtor account cannot be changed once the consent has been authorizedauthorised.
3.3.4 Consent 4 Consent Re-authentication
Payment consents are short-lived and cannot be re-authenticated by the PSU.
3.4. Risk Scoring Information
...
Payments for EcommerceGoods and EcommerceServices will be expected to have a MerchantCategoryCode and MerchantCustomerIdentification populated. Payments for EcommerceGoods will also have the DeliveryAddress populated.
4. Data Model
4.1. Reused Classes
4.1.1 1 OBRisk
This section describes the OBRisk class which is reused in the payment-order consent and payment-order resources.
4.1.1.1 1 UML Diagram
...
4.1.1.2 Data 2 Data Dictionary
Name | Occurrence | Xpath | Enhanced Definition | Class | Codes | Pattern | ||
OBRisk |
| OBRisk | The Risk section is sent by the initiating party to the ASPSP. It is used to specify additional details for risk scoring for Payments. | OBRisk |
|
| ||
PaymentContextCode | 0..1 | OBRisk/PaymentContextCode | Specifies the payment context | Stirng | Enum:
|
| ||
MerchantCategoryCode | 0..1 | OBRisk/MerchantCategoryCode | Category code conform to ISO 18245, related to the type of services or goods the merchant provides for the transaction. | String |
|
| ||
MerchantCustomerIdentification | 0..1 | OBRisk/MerchantCustomerIdentification | The unique customer identifier of the PSU with the merchant | String |
|
| ||
DeliveryAddress | 0..1 | OBRisk/DeliveryAddress | Information that locates and identifies a specific address, as defined by postal services or in free format text. | OBRisk/DeliveryAddress |
|
| ||
AddressLine | 0..7 | OBRisk/DeliveryAddress/AddressLine | Information that locates and identifies a specific address, as defined by postal services, presented in free format text. | String |
|
| ||
BuildingNumberStreetName | 0..1 | OBRisk/DeliveryAddress/BuildingNumberNumber that identifies the position of a building on a street.StreetName | Name of a street or thoroughfare | String | ||||
| BuildingNumber | RoadNumber | 0..1 | OBRisk/DeliveryAddress/RoadNumberBuildingNumber |
| String |
|
|
BlockNumberPostCode | 0..1 | OBRisk/DeliveryAddress/BlockNumberNumber that identifies the position of a block in a city.PostCode | Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail | String |
|
| ||
CityTownName | 0..1 | OBRisk/DeliveryAddress/CityTownName | Name of the citya built-up area, with defined boundaries, and a local government | String |
|
| ||
CountryCountrySubDivision | 0..1 | OBRisk/DeliveryAddress/CountryCountrySubDivision |
| String |
|
| ||
Country | 0..1 |
|
| String |
|
|
4.1.2 2 OBCharge
This section describes the OBCharge class - which is reused in the response payloads in the payment-order consent and payment-order resources.
4.1.2.1 UML 1 UML Diagram
...
4.1.2.2 Data 2 Data Dictionary
Name | Occurrence | Xpath | Enhanced Definition | Class | Codes | Pattern |
OBCharge |
| OBCharge | Set of elements used to provide details of a charge for the payment initiation. | OBCharge |
|
|
ChargeBearer | 1..1 | OBCharge/ChargeBearer | Specifies which party/parties will bear the charges associated with the processing of the payment transaction. | String | Enum:
|
|
Type | 1..1 | OBCharge/Type | Charge type, in a coded form. | String | Enum: · To be determined
|
|
Amount | 1..1 | OBCharge/Amount | Amount of money associated with the charge type. | OBActiveOrHistoricCurrencyAndAmount |
|
|
Amount | 1..1 | OBCharge/Amount/Amount | A number of monetary units specified in an active currency where the unit of currency is explicit and compliant with ISO 4217. | String |
| ^\d{1,13}.\d{1,5}$ |
Currency | 1..1 | OBCharge/Amount/Currency | A 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". | String |
| ^[A-Z]{3,3}$ |
4.1.3 3 OBAuthorisation
This section describes the OBAuthorisation class which is used in the payment-order consent request and payment-order consent response payloads.
4.1.3.1 UML 1 UML Diagram
...
4.1.3.2 Data 2 Data Dictionary
Name | Occurrence | Xpath | Enhanced Definition | Class | Codes | Pattern |
OBAuthorisation |
| OBAuthorisation | The authorisation type request from the TPP. | OBAuthorisation |
|
|
AuthorisationType | 1..1 | OBAuthorisation/AuthorisationType | Type of authorisation flow requested. | String | Enum:
|
|
CompletionDateTime | 0..1 | OBAuthorisation/CompletionDateTime | Date and time at which the requested authorisation flow must be completed. | DateTime |
|
|
4.1.4 4 OBDomesticRefundAccount
This section describes the OBDomesticRefundAccount class which is used in the response payloads of Domestic Payment, Domestic Future Dated Payment and Domestic Standing Order.
4.1.4.1 UML 1 UML Diagram
...
4.1.4.2 Data 2 Data Dictionary
Name | Occurrence | Xpath | Enhanced Definition | Class | Codes | Pattern |
OBDomesticRefundAccount |
| OBDomesticRefundAccount | Unambiguous identification of the refund account to which a refund will be made as a result of the transaction. | OBDomesticRefundAccount |
|
|
Account | 1..1 | OBDomesticRefundAccount/Account | Provides the details to identify an account. | OBDomesticRefundAccount/Account |
|
|
SchemeName | 1..1 | OBDomesticRefundAccount/Account/SchemeName | Name of the identification scheme, in a coded form as published in an external list. | String | Enum:
|
|
Identification | 1..1 | OBDomesticRefundAccount/Account/Identification | Identification assigned by an institution to identify an account. This identification is known by the account owner. | String |
|
|
Name | 0..1 | OBDomesticRefundAccount/Account/Name | Name of the account, as assigned by the account servicing institution. Usage: The account name is the name or names of the account owner(s) represented at an account level. The account name is not the product name or the nickname of the account. OB: ASPSPs may carry out name validation for Confirmation of Payee, but it is not mandatory. | String |
| SecondaryIdentification |
...
4.1.
...
OBDomesticRefundAccount/Account/SecondaryIdentification
...
This 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).
...
String
...
...
4.1.5 OBInternationalRefundAccount
...
5 OBInternationalRefundAccount
This section describes the OBInternationalRefundAccount class which is used in the response payloads of International Payment, International Future Dated Payment and International Standing Order.
...
Name | Occurrence | Xpath | Enhanced Definition | Class | Codes | Pattern | |||||
OBInternationalRefundAccount |
| OBInternationalRefundAccount | Unambiguous identification of the refund account to which a refund will be made as a result of the transaction. | OBInternationalRefundAccount |
|
| |||||
Creditor | 0..1 | OBInternationalRefundAccount/Creditor | Party to which an amount of money is due. | OBInternationalRefundAccount/Creditor |
|
| |||||
Name | 0..1 | OBInternationalRefundAccount/Creditor/Name | Name by which a party is known and which is usually used to identify that party. | String |
|
| |||||
PostalAddress | 0..1 | OBInternationalRefundAccount/Creditor/PostalAddress | Information that locates and identifies a specific address, as defined by postal services. | OBPostalAddress |
|
| |||||
AddressType | 0..1 | OBInternationalRefundAccount/Creditor/PostalAddress/AddressType | Identifies the nature of the postal address. | String | Enum:
|
| |||||
Department | 0..1 | OBInternationalRefundAccount/Creditor/PostalAddress/Department | Identification of a division of a large organisation or building. | String |
|
| |||||
SubDepartment | 0..1 | OBInternationalRefundAccount/Creditor/PostalAddress/SubDepartment | Identification of a sub-division of a large organisation or building. | String |
|
| |||||
AddressLine | 0..7 | OBInternationalRefundAccount/Creditor/PostalAddress/AddressLine | Information that locates and identifies a specific address, as defined by postal services, presented in free format text. | String |
|
| |||||
BuildingNumberStreetName | 0..1 | OBInternationalRefundAccount OBInternationalPaymentInitiation/Creditor/PostalAddress/BuildingNumberNumber that identifies the position of a building on a street.StreetName | Name of a street or thoroughfare | String | |||||||
|
| RoadNumberBuildingNumber | 0..1 | OBInternationalPaymentInitiation/Creditor/PostalAddress/BuildingNumber | Number that identifies the position of a building on a street | String |
|
| |||
PostCode | 0..1 | OBInternationalRefundAccount OBInternationalPaymentInitiation/Creditor/PostalAddress/RoadNumberPostCode | Number Identifier consisting of a road or thoroughfare.group of letters and/or numbers that is added to a postal address to assist the sorting of mail | String |
|
| |||||
BlockNumberTownName | 0..1 | OBInternationalRefundAccount OBInternationalPaymentInitiation/Creditor/PostalAddress/BlockNumberNumber that identifies the position of a block in a city.TownName | Name of a built-up area, with defined boundaries, and a local government | String |
|
| |||||
CityCountrySubDivision | 0..1 | OBInternationalRefundAccount OBInternationalPaymentInitiation/Creditor/PostalAddress/CityCountrySubDivision | Name of the cityIdentifies a subdivision of a country such as state, region, country | String |
|
| |||||
Country | 0..1 | OBInternationalRefundAccount/Creditor/PostalAddress/Country | Nation with its own government. | String |
| ^[A-Z]{2,2}$ | |||||
Agent | 0..1 | OBInternationalRefundAccount/Agent | Financial institution servicing an account for the creditor. | OBInternationalRefundAccount/Agent |
|
| |||||
SchemeName | 0..1 | OBInternationalRefundAccount/Agent/SchemeName | Name of the identification scheme, in a coded form as published in an external list. | String | Enum:
|
| |||||
Identification | 0..1 | OBInternationalRefundAccount/Agent/Identification | Unique and unambiguous identification of a financial institution or a branch of a financial institution. | String |
|
| |||||
Name | 0..1 | OBInternationalRefundAccount/Agent/Name | Name by which an agent is known and which is usually used to identify that agent. | String |
|
| |||||
PostalAddress | 0..1 | OBInternationalRefundAccount/Agent/PostalAddress | Information that locates and identifies a specific address, as defined by postal services. | OBPostalAddress |
|
| |||||
AddressType | 0..1 | OBInternationalRefundAccount/Agent/PostalAddress/AddressType | Identifies the nature of the postal address. | String | Enum:
|
| |||||
Department | 0..1 | OBInternationalRefundAccount/Agent/PostalAddress/Department | Identification of a division of a large organisation or building. | String |
|
| |||||
SubDepartment | 0..1 | OBInternationalRefundAccount/Agent/PostalAddress/SubDepartment | Identification of a sub-division of a large organisation or building. | String |
|
| |||||
AddressLine | 0..7 | OBInternationalRefundAccount/Agent/PostalAddress/AddressLine | Information that locates and identifies a specific address, as defined by postal services, presented in free format text. | String |
| format text. | String |
|
| ||
StreetName | 0..1 | OBInternationalPaymentInitiation/CreditorAgent/PostalAddress/StreetName | Name of a street or thoroughfare | String | |||||||
BuildingNumber | 0..1 | OBInternationalRefundAccount OBInternationalPaymentInitiation/AgentCreditorAgent/PostalAddress/BuildingNumber | Number that identifies the position of a building on a street. | String |
|
| |||||
RoadNumberPostCode | 0..1 | OBInternationalRefundAccount OBInternationalPaymentInitiation/AgentCreditorAgent/PostalAddress/RoadNumberPostCode | Number Identifier consisting of a road or thoroughfare.group of letters and/or numbers that is added to a postal address to assist the sorting of mail | String |
|
| |||||
BlockNumberTownName | 0..1 | OBInternationalRefundAccount OBInternationalPaymentInitiation/AgentCreditorAgent/PostalAddress/BlockNumberNumber that identifies the position of a block in a city.TownName | Name of a built-up area, with defined boundaries, and a local government | String |
|
| |||||
CityCountrySubDivision | 0..1 | OBInternationalRefundAccount OBInternationalPaymentInitiation/AgentCreditorAgent/PostalAddress/CityCountrySubDivision | Name of the cityIdentifies a subdivision of a country such as state, region, country | String |
|
| |||||
Country | 0..1 | OBInternationalRefundAccount/Agent/PostalAddress/Country | Nation with its own government. | String |
| ^[A-Z]{2,2}$ | |||||
Account | 1..1 | OBInternationalRefundAccount/Account | Unambiguous identification of the account of the creditor to which a credit entry will be posted as a result of the payment transaction. | OBInternationalRefundAccount/Account |
|
| |||||
SchemeName | 1..1 | OBInternationalRefundAccount/Account/SchemeName | Name of the identification scheme, in a coded form as published in an external list. | String | Enum: BH.OBF.BBAN
|
| |||||
Identification | 1..1 | OBInternationalRefundAccount/Account/Identification | Identification assigned by an institution to identify an account. This identification is known by the account owner. | String |
|
| |||||
Name | 1..1 | OBInternationalRefundAccount/Account/Name | The account name is the name or names of the account owner(s) represented at an account level. Note, the account name is not the product name or the nickname of the account. OB: ASPSPs may carry out name validation for Confirmation of Payee, but it is not mandatory. | String |
|
| SecondaryIdentification | 0..1 | OBInternationalRefundAccount/Account/SecondaryIdentification | This 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). | String |
...
4.1.6 6 OBWritePaymentDetails
This section describes the OBWritePaymentDetails class which used in the response payloads of payment-detail sub resources.
4.1.6.1 UML 1 UML Diagram
...
4.1.6.2 Data 2 Data Dictionary
Name | Occurrence | Xpath | Enhanced Definition | Class | Codes | Pattern |
OBWritePaymentDetails |
| OBWritePaymentDetails | Payment status details. | OBWritePaymentDetails |
|
|
PaymentTransactionId | 1..1 | OBWritePaymentDetails/PaymentTransactionId | Unique identifier for the transaction within an servicing institution. This identifier is both unique and immutable | String |
|
|
Status | 1..1 | OBWritePaymentDetails/Status | Status of a transfer, as assigned by the transaction administrator. | String | Enum:
|
|
StatusUpdateDateTime | 1..1 |
| Date and time at which the status was assigned to the transfer. | DateTime |
|
|
StatusDetail | 0..1 | OBWritePaymentDetails/StatusDetail | Payment status details as per underlying Payment Rail. | OBWritePaymentDetails/StatusDetail |
|
|
LocalInstrument | 0..1 |
| User 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. | String | Enum:
|
|
Status | 1..1 | OBWritePaymentDetails/StatusDetail/Status | Status of a transfer, as assigned by the transaction administrator. | String |
|
|
StatusReason | 0..1 | OBWritePaymentDetails/StatusDetail/StatusReason |
| String | Enum:
|
|
StatusReasonDescription | 0..1 | OBWritePaymentDetails/StatusDetail/StatusReasonDescription | Reason provided for the status of a transfer. | String |
|
|
4.1.7 OBSCASupportData7 OBSCASupportData
This section describes the OBSCASupportData class, which is used across all payment order consent request resources, enabling PISPs to provide Supporting Data when requesting ASPSP for SCA Exemption.
4.1.7.1 UML 1 UML Diagram
...
4.1.7.2 Data 2 Data Dictionary
Name | Occurrence | Xpath | Enhanced Definition | Class | Codes | Pattern |
OBSCASupportData |
| SCASupportData | Supporting Data provided by TPP, when requesting SCA Exemption. | OBSCASupportData |
|
|
RequestedSCAExemptionType | 0..1 | SCASupportData/RequestedSCAExemptionType | This field allows a PISP to request specific SCA Exemption for a Payment Initiation | String | Enum:
|
|
AppliedAuthenticationApproach | 0..1 | SCASupportData/AppliedAuthenticationApproach | Specifies 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 | String | Enum:
|
|
ReferencePaymentOrderId | 0..1 | SCASupportData/ReferencePaymentOrderId | Specifies 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. | String |
|
|
...