| Table of Contents | ||||
|---|---|---|---|---|
|
...
Security & Access Control: Specifies the means for PISPs and PSUs users/customers to authenticate themselves and provide consent.
...
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 user/customer consent authorisation.
The Status field for the payment-order resource reflects the status of the payment-order initiation or execution.
...
Step 1: Agree Payment-Order Initiation
This flow begins with a PSU user/customer consenting to a payment being made. The consent is between the PSU user/customer and the PISP.
The debtor account details can optionally be specified at this stage.
...
The PISP connects to the ASPSP (Bank) that services the PSU's user’s/customer’s payment account and creates a new payment-order consent resource. This informs the ASPSP (Bank) that one of its PSUs users/customers 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.
Step 3: Authorise Consent
The PISP requests the PSU user/customer 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 user/customer 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 PSUuser/customer.
The PSU user/customer 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 user/customer is redirected back to the PISP.
In a decoupled flow, the ASPSP (Bank) requests the PSU user/customer to authorise consent on an authentication device that is separate from the consumption device on which the PSU user/customer 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 user/customer paired with the consent to be authorised.
The ASPSP (Bank) authenticates the PSUuser/customer
The PSU user/customer 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.
Step 4: Confirm Funds (Domestic and International Single Immediate Payments Only)
Once the PSU user/customer is authenticated and authorised the payment-order-consent, the PISP can check whether funds are available to make the payment.
This is carried out by making a GET request, calling the funds-confirmation operator on the payment-order-consent resource.
...
In this scenario, the behaviour of payment-order execution is explicit to the PISP and PSUuser/customer.
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 user/customer 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 PSUuser/customer, and the payment-order will be executed on the next available working day.
...
A consent authorisation is used to define the fine-grained scope that is granted by the PSU user/customer to the PISP.
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 PSUuser/customer. At this stage, the consent is not yet authorised as the ASPSP (Bank) has not yet verified this claim with the PSUuser/customer.
The ASPSP (Bank) responds with a ConsentId. This is the intent-id that is used when initiating the authorisation code grant.
...
The ASPSP (Bank) authenticates the PSUuser/customer.
The ASPSP (Bank) plays back the consent (registered by the PISP) back to the PSU user/customer to get consent authorisation. The PSU user/customer 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 user/customer with a list of accounts from which the PSU user/customer may select one.
Once these steps are complete, the consent is considered to have been authorised by the PSUuser/customer.
3.3.1 Error Condition
If the PSU user/customer does not complete a successful consent authorisation (e.g., if the PSU user/customer has not authenticated successfully), the authorisation code grant ends with a redirection to the PISP with an error response. The PSU user/customer is redirected to the PISP with an error parameter indicating the error that occurred.
3.3.2 Consent Revocation
A PSU user/customer cannot revoke a payment-order consent once it has been authorised.
...
Payment consents are short-lived and cannot be re-authenticated by the PSUuser/customer.
3.4 Risk Scoring Information
...
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 user/customer 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 |
|
|
...
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}$ |
...
Name | Occurrence | Xpath | Enhanced Definition | Class | Codes | Pattern |
OBSCASupportData |
| SCASupportData | Supporting Data provided by PISP, 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 user/customer was subject to SCA performed by the PISP | 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 |
|
|
...
Code Class | Name | Definition |
OBExternalPaymentContextCode | BillPayment | The context of the payment initiation is a bill payment. |
OBExternalPaymentContextCode | EcommerceGoods | The context of the payment initiation is for goods via an ecommerce channel. |
OBExternalPaymentContextCode | EcommerceServices | The context of the payment initiation is for services via an ecommerce channel. |
OBExternalPaymentContextCode | PartyToParty | The context of the payment initiation is a party to party payment. |
OBExternalPaymentContextCode | Other | The context of the payment initiation is of another type. |
OBTransactionIndividualStatusCode | AcceptedSettlementCompleted | Settlement on the debtor's account has been completed. Usage: this can be used by the first agent to report to the debtor that the transaction has been completed.
Warning: this status is provided for transaction status reasons, not for financial information. It can only be used after bilateral agreement. PISPs must not use this status as confirmation that settlement is complete on the creditor's account. |
OBTransactionIndividualStatusCode | AcceptedSettlementInProcess | All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution. |
OBTransactionIndividualStatusCode | Pending | Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed. |
OBTransactionIndividualStatusCode | Rejected | Payment initiation or individual transaction included in the payment initiation has been rejected. |
OBTransactionIndividualStatusCode | AcceptedWithoutPosting | Payment instruction included in the credit transfer is accepted without being posted to the creditor customer's account. |
OBTransactionIndividualStatusCode | AcceptedCreditSettlementCompleted | Settlement on the creditor's account has been completed. |
OBExternalConsentStatusCode | AwaitingAuthorisation | The consent resource is awaiting PSU user/customer authorisation. |
OBExternalConsentStatusCode | Rejected | The consent resource has been rejected. |
OBExternalConsentStatusCode | Authorised | The consent resource has been successfully authorised. |
OBExternalConsentStatusCode | Consumed | The consented action has been successfully completed. This does not reflect the status of the consented action. |
OBChargeBearerTypeCode | BorneByCreditor | All transaction charges are to be borne by the creditor. |
OBChargeBearerTypeCode | BorneByDebtor | All transaction charges are to be borne by the debtor. |
OBChargeBearerTypeCode | FollowingServiceLevel | Charges are to be applied following the rules agreed in the service level and/or scheme. |
OBChargeBearerTypeCode | Shared | In a credit transfer context, means that transaction charges on the sender side are to be borne by the debtor, transaction charges on the receiver side are to be borne by the creditor. In a direct debit context, means that transaction charges on the sender side are to be borne by the creditor, transaction charges on the receiver side are to be borne by the debtor. |
OBExternalAuthorisationCode | Single | Single authorisation type is requested. |
OBExternalStatusCode | InitiationCompleted | The payment-order initiation has been completed. |
OBExternalStatusCode | InitiationFailed | The payment-order initiation has failed. |
OBExternalStatusCode | InitiationPending | The payment-order initiation is pending. |
OBExternalStatusCode | InitiationCompleted | The payment-order initiation has been completed. |
OBExternalStatusCode | InitiationFailed | The payment-order initiation has failed. |
OBExternalStatusCode | InitiationPending | The payment-order initiation is pending. |
OBExternalStatusCode | Cancelled | Payment initiation has been successfully cancelled after having received a request for cancellation. |
OBExchangeRateTypeCode | Actual | Exchange rate is the actual rate. |
OBExchangeRateTypeCode | Agreed | Exchange rate is the agreed rate between the parties. |
OBExchangeRateTypeCode | Indicative | Exchange rate is the indicative rate. |
OBPriorityCode | Normal | Priority is normal. |
OBPriorityCode | Urgent | Priority is urgent. |
OBAddressTypeCode | Business | Address is the business address. |
OBAddressTypeCode | Correspondence | Address is the address where correspondence is sent. |
OBAddressTypeCode | DeliveryTo | Address is the address to which delivery is to take place. |
OBAddressTypeCode | MailTo | Address is the address to which mail is sent. |
OBAddressTypeCode | POBox | Address is a postal office (PO) box. |
OBAddressTypeCode | Postal | Address is the complete postal address. |
OBAddressTypeCode | Residential | Address is the home address. |
OBAddressTypeCode | Statement | Address is the address where statements are sent. |
OBTransactionIndividualExtendedISOStatusCode | Accepted | Request is accepted. |
OBTransactionIndividualExtendedISOStatusCode | AcceptedCancellationRequest | Cancellation is accepted. |
OBTransactionIndividualExtendedISOStatusCode | AcceptedCreditSettlementCompleted | Settlement on the creditor's account has been completed. |
OBTransactionIndividualExtendedISOStatusCode | AcceptedCustomerProfile | Preceding check of technical validation was successful. Customer profile check was also successful. |
OBTransactionIndividualExtendedISOStatusCode | AcceptedFundsChecked | Preceding check of technical validation and customer profile was successful and an automatic funds check was positive. |
OBTransactionIndividualExtendedISOStatusCode | AcceptedSettlementCompleted | Settlement on the debtor's account has been completed.
Usage: this can be used by the first agent to report to the debtor that the transaction has been completed.
Warning: this status is provided for transaction status reasons, not for financial information. It can only be used after bilateral agreement |
OBTransactionIndividualExtendedISOStatusCode | AcceptedSettlementInProcess | All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution. |
OBTransactionIndividualExtendedISOStatusCode | AcceptedTechnicalValidation | Authentication and syntactical and semantical validation are successful |
OBTransactionIndividualExtendedISOStatusCode | AcceptedWithChange | Instruction is accepted but a change will be made, such as date or remittance not sent. |
OBTransactionIndividualExtendedISOStatusCode | AcceptedWithoutPosting | Payment instruction included in the credit transfer is accepted without being posted to the creditor customer’s account. |
OBTransactionIndividualExtendedISOStatusCode | Cancelled | Request is cancelled. |
OBTransactionIndividualExtendedISOStatusCode | NoCancellationProcess | No cancellation process. |
OBTransactionIndividualExtendedISOStatusCode | PartiallyAcceptedCancellationRequest | Cancellation is partially accepted. |
OBTransactionIndividualExtendedISOStatusCode | PartiallyAcceptedTechnicalCorrect | Authentication and syntactical and semantical validation are successful. |
OBTransactionIndividualExtendedISOStatusCode | PaymentCancelled | Transaction has been cancelled. |
OBTransactionIndividualExtendedISOStatusCode | Pending | Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed. |
OBTransactionIndividualExtendedISOStatusCode | PendingCancellationRequest | Cancellation request is pending. |
OBTransactionIndividualExtendedISOStatusCode | Received | Payment initiation has been received by the receiving agent. |
OBTransactionIndividualExtendedISOStatusCode | Rejected | Payment initiation or individual transaction included in the payment initiation has been rejected. |
OBTransactionIndividualExtendedISOStatusCode | RejectedCancellationRequest | Cancellation request is rejected |
OBTransactionIndividualStatusReasonCode | Cancelled | Reason why the payment status is cancelled |
OBTransactionIndividualStatusReasonCode | PendingFailingSettlement | Reason why the payment status is pending (failing settlement). |
OBTransactionIndividualStatusReasonCode | PendingSettlement | Reason why the payment status is pending (settlement). |
OBTransactionIndividualStatusReasonCode | Proprietary | Defines a free text proprietary reason. |
OBTransactionIndividualStatusReasonCode | ProprietaryRejection | Defines the reason that has been used by the Local Instrument system to reject the transaction |
OBTransactionIndividualStatusReasonCode | Suspended | Reason why the payment status is suspended. |
OBTransactionIndividualStatusReasonCode | Unmatched | Reason why the payment status is unmatched. |
OBExternalSCAExemptionTypeCode | BillPayment | Bill Payment |
OBExternalSCAExemptionTypeCode | ContactlessTravel | Contactless Travel |
OBExternalSCAExemptionTypeCode | EcommerceGoods | Ecommerce Goods |
OBExternalSCAExemptionTypeCode | EcommerceServices | Ecommerce Services |
OBExternalSCAExemptionTypeCode | Kiosk | Kisok |
OBExternalSCAExemptionTypeCode | Parking | Parking |
OBExternalSCAExemptionTypeCode | PartyToParty | Party To Party |
OBExternalAppliedAuthenticationApproachCode | CA | Single Factor Strong Customer Authentication |
OBExternalAppliedAuthenticationApproachCode | SCA | Multi Factor Strong Customer Authentication |
OBReadRefundAccountCode | Yes | Yes |
OBReadRefundAccountCode | No | No |
...