Payment Status

User Journey

The Open Banking Standard has been updated to allow ASPSPs to provide the PISPs with the following payment status information: 

• The status any time after payment submission for all supported payment types, including Single Immediate Domestic, Single Future-dated Domestic, Standing-order Domestic, Single Immediate International, Single Future-dated International, Standing-order International and Bulk/Batch payments, VRP for sweeping (sVRPs) and commercial VRPs (cVRPs). 
• A meaningful status message to a PISP request for each processing phase and particularly when settlement on the debtor’s account has been completed thus providing the PISP with a sufficient status message that the payment will be sent to the receiving bank. 
• A confirmation that the payment has been executed and has been received by the payee bank (e.g. provide the status message ‘ACCC’ which means ‘Accepted Settlement Completed Creditor Account’) 
• Enriched and more granular list of payment status messages and reasons for failure/rejection as per the ISO 20022 standard and other standards through the payment initiation, processing and and execution stages of payments at the sending bank and the receiving bank.  

CX and other processing requirements

A. Payment Consent Response Status

Payment Consent Response Status

• After payment consent has been staged by the PISP to the ASPSP. 
• If the request is successful, a new payment consent resource is created. The status of the payment consent at this state must be ‘AWAU’ which means ‘Awaiting Authorisation’. The ASPSP responds back to the PISP that the request has been successful (201 message) including the payment consent status. 
• If the request fails, a 4xx series message with a failure reason code(s) are sent back to the PISP. There could be one or more reasons for  failure. 
• A ‘GET’ status call by the PISP at this stage should also respond with status ‘AWAU’. If the staging is unsuccessful the PISP must rely on the reason code(s) provided by the ASPSP in the error message. 

Note: For various reasons the consent may not move to its next natural stage of ‘Authorised’ or ‘Rejected’ if the PSU is not redirected to the ASPSP for authentication. In this case, the ASPSP must populate the appropriate reason code(s) after timeout.

Status Code	Status Reason Code	Status Reason Description
AWAU	U036	Authorisation not completed

Extract of error message for a Failed to stage Consent
“ErrorCode”: “U001”,
            “Message”: “UK.OB.Field.Expected”,
“Path”: “Data.Initiation.CreditorAccount.Name”

B. PSU Authentication Status

Status Code	Status Reason Code	Status Reason Description
AUTH

If the PSU call to action leads to the PSU cancelling the payment, then the status of the payment consent should become ‘RJCT’ which means ‘Rejected.

Note: For various reasons, the consent may be considered as ‘Rejected’, in which case the ASPSP must populate the appropriate reason codes, e.g.:

Status Code	Status Reason Code	Status Reason Description
RJCT	AM04	Insufficient Funds
RJCT	U037	Authorisation failed (after x attempts)
RJCT	CN01	Authorisation Cancelled

A PISP could make a call to the ‘GET’ status endpoint at this stage to find out if the payment consent resource has been updated to ‘AUTH’ which means ‘Authorised‘ or ‘RJCT’ which means ‘Rejected’.

If the PSU does not authenticate successfully, then there is no authorisation code sent back to the PISP. However, ASPSP must respond with error information back to the PISP. The error information must include the reason(s) codes as specified below. The status of the payment consent resource should still be ‘AWAU’ which means ‘Awaiting Authorisation’. The PISP may notify the PSU in order to decide whether to redirect the PSU again to the ASPSP or take some other action.

Status Code	Status Reason Code	Status Code Description
AWAU	U036	Authorisation not completed
AWAU	U000	UK.OB.UnexpectedError
AWAU	AM04	Insufficient Funds
AWAU	U037	Authorisation failed