| Table of Contents | ||||
|---|---|---|---|---|
|
...
The PISP connects to the ASPSP (Bank) that services the PSU's payment account and creates a new payment-order consent resource. This informs the ASPSP (Bank) that one of its PSUs intends to make a payment-order. The ASPSP (Bank) responds with an identifier for the payment-order consent resource (the ConsentId, which is the intent identifier).
This step is carried out by making a POST request to the payment-order consent resource.
...
The PISP requests the PSU to authorise the consent. The ASPSP (Bank) may carry this out by using a redirection flow or a decoupled flow.
In a redirection flow, the PISP redirects the PSU to the ASPSP (Bank).
The redirect includes the ConsentId generated in the previous step.
This allows the ASPSP (Bank) to correlate the payment order consent that was setup.
The ASPSP (Bank) authenticates the PSU.
The PSU selects the debtor account at this stage (if it has not been previously specified in Step 1).
The ASPSP (Bank) updates the state of the payment order consent resource internally to indicate that the consent has been authorised.
Once the consent has been authorised, the PSU is redirected back to the PISP.
In a decoupled flow, the ASPSP (Bank) requests the PSU to authorise consent on an authentication device that is separate from the consumption device on which the PSU is interacting with the PISP.
The decoupled flow is initiated by the PISP calling a back-channel authorisation request.
The request contains a 'hint' that identifies the PSU paired with the consent to be authorised.
The ASPSP (Bank) authenticates the PSU
The PSU selects the debtor account at this stage (if it has not been previously specified in Step 1)
The ASPSP (Bank) updates the state of the payment order consent resource internally to indicate that the consent has been authorised.
Once the consent has been authorised, the ASPSP (Bank) can make a callback to the PISP to provide an access token.
...
The PISP creates a payment-order resource to indicate that the payment created in the steps above should be submitted for processing.
This is carried out by making a POST request to the appropriate payment-order resource.
The ASPSP (Bank) returns the identifier for the payment-order resource to the PISP.
...
The maximum InstructedAmount allowable.
The domestic-standing-order Frequency patterns supported.
The maximum future date on a future dated payment.
Each ASPSP (Bank) must determine appropriate restrictions that they support based on their individual practices, standards and limitations. These restrictions should be documented on ASPSP (Bank) developer portals.
An ASPSP (Bank) must reject the payment-order consent if the ASPSP (Bank) is unable to handle the request.
2.2.1 CutOffDateTime Behaviour
An ASPSP (Bank) may return the specific CutOffDateTime when responding to a payment-order consent request.
An ASPSP (Bank) must document the behaviour for a payment receipt before and after the CutOffDateTime for a payment-order has elapsed.
...
In this scenario, the behaviour of payment-order execution is explicit to the PISP and PSU.
An ASPSP (Bank) must reject the payment-order consent if the CutOffDateTime for a specific payment-order type has elapsed.
An ASPSP (Bank) must reject an authorisation request when the underlying intent object is associated with a CutoffDateTime that has elapsed. The ASPSP (Bank) must not issue an access token in such a situation. The ASPSP (Bank) must set the status of the payment-order consent resource to “Rejected”.
An ASPSP (Bank) 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.
...
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 (Bank) must accept the payment-order consent if the CutOffDateTime for a specific payment-order type has elapsed.
An ASPSP (Bank) must accept an authorisation request when the underlying intent object is associated with a CutoffDateTime that has elapsed.
An ASPSP (Bank) must accept the payment-order resource if the CutOffDateTime for a specific payment-order type, has been established and has elapsed.
An ASPSP (Bank) 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
...
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 (Bank) may choose to make ConsentIds accessible across versions
E.g., for a PaymentId created in v1, an ASPSP (Bank) may or may not make it available via v3, as this is a short-lived consent
...
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 (Bank) 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
...
A PISP must refer to the ASPSP's (Bank’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 (Bank) must document the behaviour on the accessibility of a payment-order resource in a newer version on the ASPSP's (Bank’s) online Developer Portal.
An ASPSP (Bank) must allow access to the payment-order resource created in a previous version on a newer version endpoint (depending on an ASPSP's (Bank’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 (Bank) 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 (Bank’s) Developer Portal clearly specifying the behaviour.
E.g., a new field StatusUpdateDateTime was introduced in v3, an ASPSPs ASPSP (Bank) must populate this with the last status update time (as the StatusUpdateDateTime is a mandatory field).
...
The PISP must begin a payment-order request by creating a payment-order consent resource through a POST operation. These resources indicate the consent that the PISP claims it has been given by the PSU. At this stage, the consent is not yet authorised as the ASPSP (Bank) has not yet verified this claim with the PSU.
The ASPSP (Bank) responds with a ConsentId. This is the intent-id that is used when initiating the authorisation code grant.
As part of the authorisation code grant:
The ASPSP (Bank) authenticates the PSU.
The ASPSP (Bank) 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 (Bank) presents the PSU with a list of accounts from which the PSU may select one.
...
If the PSU does not complete a successful consent authorisation (e.g., if the PSU has not authenticated successfully), the authorisation code grant ends with a redirection to the TPP PISP with an error response. The PSU is redirected to the TPP PISP with an error parameter indicating the error that occurred.
...
4.1.1.1 UML Diagram
...
4.1.1.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 | String | 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 |
|
|
StreetName | 0..1 | OBRisk/DeliveryAddress/StreetName | Name of a street or thoroughfare | String | ||
BuildingNumber | 0..1 | OBRisk/DeliveryAddress/BuildingNumber |
| String |
|
|
PostCode | 0..1 | OBRisk/DeliveryAddress/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 |
|
|
TownName | 0..1 | OBRisk/DeliveryAddress/TownName | Name of a built-up area, with defined boundaries, and a local government | String |
|
|
CountrySubDivision | 0..1 | OBRisk/DeliveryAddress/CountrySubDivision |
| String |
|
|
Country | 0..1 |
|
| String |
|
|
...
...
4.1.2.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.1 UML Diagram
...
4.1.3.2 Data Dictionary
Name | Occurrence | Xpath | Enhanced Definition | Class | Codes | Pattern |
OBAuthorisation |
| OBAuthorisation | The authorisation type request from the TPPPISP. | 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.1 UML Diagram
...
4.1.4.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 |
|
|
4.1.5 OBInternationalRefundAccount
...
4.1.5.2 Data Dictionary
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 |
|
|
StreetName | 0..1 | OBInternationalPaymentInitiation/Creditor/PostalAddress/StreetName | Name of a street or thoroughfare | String | ||
BuildingNumber | 0..1 | OBInternationalPaymentInitiation/Creditor/PostalAddress/BuildingNumber | Number that identifies the position of a building on a street | String |
|
|
PostCode | 0..1 | OBInternationalPaymentInitiation/Creditor/PostalAddress/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 |
|
|
TownName | 0..1 | OBInternationalPaymentInitiation/Creditor/PostalAddress/TownName | Name of a built-up area, with defined boundaries, and a local government | String |
|
|
CountrySubDivision | 0..1 | OBInternationalPaymentInitiation/Creditor/PostalAddress/CountrySubDivision | Identifies 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 |
|
|
StreetName | 0..1 | OBInternationalPaymentInitiation/CreditorAgent/PostalAddress/StreetName | Name of a street or thoroughfare | String | ||
BuildingNumber | 0..1 | OBInternationalPaymentInitiation/CreditorAgent/PostalAddress/BuildingNumber | Number that identifies the position of a building on a street | String |
|
|
PostCode | 0..1 | OBInternationalPaymentInitiation/CreditorAgent/PostalAddress/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 |
|
|
TownName | 0..1 | OBInternationalPaymentInitiation/CreditorAgent/PostalAddress/TownName | Name of a built-up area, with defined boundaries, and a local government | String |
|
|
CountrySubDivision | 0..1 | OBInternationalPaymentInitiation/CreditorAgent/PostalAddress/CountrySubDivision | Identifies 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:
|
|
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 |
|
|
4.1.6 OBWritePaymentDetails
...
4.1.6.1 UML Diagram
...
4.1.6.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 |
|
|
...
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 (Bank) for SCA Exemption.
4.1.7.1 UML Diagram
...
4.1.7.2 Data Dictionary
Name | Occurrence | Xpath | Enhanced Definition | Class | Codes | Pattern |
OBSCASupportData |
| SCASupportData | Supporting Data provided by TPPPISP, 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 TPPPISP | 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 |
|
|
...
Generated | Identifier | Business Description |
Merchant/PISP Sent in API Payload | EndToEndIdentification | The EndToEndIdentification reference is a reference that can be populated by the debtor (or merchant in the ecommerce space). This reference is important to the debtor (could be an internal reference Id against the transaction), it Is NOT the reference information that will be primarily populated on the statement of the creditor (beneficiary). |
Merchant/PISP Sent in API Payload | InstructionIdentification | The PISP generates the InstructionIdentification which is a unique transaction Id and passes it to the ASPSP (Bank) (this is mandatory), but this does not have to go any further in the payment flow. The flow of this identifier needs to align with payment scheme rules. The expectation is that this is unique indefinitely across all time periods. The PISP can ensure this is indefinitely unique by including a date or date time element to the field, or by inserting a unique Id. |
Merchant/PISP Sent in API Payload | RemittanceInformation | The RemittanceInformation is the reference information that the creditor (or beneficiary) will need to reconcile (e.g. Invoice 123). |
ASPSP / API System | ConsentId | A unique identification as assigned by the ASPSP (Bank) to uniquely identify the payment-order consent resource. |
ASPSP / API System | Payment Order Id | A unique identification as assigned by the ASPSP (Bank) to uniquely identify the payment-order resource.
|
ASPSP / Payment Scheme | Scheme Payment ID | This is generated by the ASPSP (Bank) to uniquely identify a payment through a processing scheme. |
...
This example illustrates a scenario where an ASPSP (Bank) choses to Reject the Payment-Order consent/resource request, after the CutoffTime. We have a payment-order consent created after the CutOffDateTime, and ASPSP (Bank) rejects the Consent, and the PISP chooses to place a Future Dated Payment-Order consent.
...
This example illustrates a scenario where an ASPSP (Bank) choses to Reject the Payment-Order consent/resource request, after the CutoffTime. We have a payment-order Consent created and the Authorisation completed before the CutOffDateTime, but the Payment-Order submission happened after the CutOffDateTime, so the ASPSP (Bank) has rejected it.
...