Other pages in this section Themes identified from consumer and SME research CX Guidelines Consultation – Research Data Deep Linking for App-to-App redirection Payment Initiation Services (PIS) parameters and considerations Card-specific Permissions and Data Clusters for AIS journeys Read/Write API Specification – Standard Error Codes Contingent Reimbursement Model Payment Status
CX and other processing requirements A Payment Consent Response Status After payment consent has been posted by 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 should be ‘Awaiting Authorisation’. The ASPSP responds back to the PISP that the request has been successful (201 message) including the payment consent status. A ‘GET’ status call by the PISP at this stage should also respond with status ‘Awaiting Authorisation’ If the request fails, a 4xx series message with a failure code is sent back to the PISP. B PSU Authentication Status If payment consent is set up successfully, the PSU is redirected to the ASPSP for authentication. If the PSU authenticates successfully, then: if there is no call to action for the PSU (such as in journey Single Domestic Payments – a/c selection @ PISP) the status of the payment consent should become ‘Authorised’ If there is a call to action for the PSU (such as in supplementary information journey Single Domestic Payments – Supplementary info, then the PSU decision to proceed with the payment should make the status of the payment consent become ‘Authorised’ If the PSU call to action leads to the PSU cancelling the payment, then the status of the payment consent should become ‘Rejected’ A PISP could make a call to the ‘GET’ status endpoint at this stage to find out if the payment consent resource has been ‘Authorised‘ or ‘Rejected’ by the PSU. If the PSU does not authenticate successfully, then there is no authorisation code sent back to the PISP. However, ASPSP will respond with error information back to the PISP. The status of the payment consent resource should still be ‘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. C Payment Initiation Response Status In the case that the payment consent has been authorised by the PSU, the PISP will submit the payment order to the ASPSP. if the request is successful: the payment consent resource status should become ‘Consumed’ a new payment order resource is created. The status of the payment order at this state should be ‘Pending’. The ASPSP responds back to the PISP that the request has been successful (201 message) including the payment order status. A PISP could make a call to the ‘GET’ status endpoint at this stage to confirm that the payment consent resource has been ‘Consumed’ as part of the payment order initiation. If the request fails, a 4xx series message with a failure code is sent back to the PISP. Depending on the error code the PISP could make the decision whether to submit the payment order again or not. D Further Payment InitiationStatus In case the payment order submission is successful and the payment order resource is created (with ‘Pending’ status), there are further checks and validations that will take place at the ASPSP as part of the payment initiation. If all the checks complete successfully, the payment order resource status should become ‘AcceptedSettlementInProcess’.The payment will then proceed to the payment processing phase. If any of the checks fail, the payment order resource status should become ‘Rejected’ A PISP could make a call to the ‘GET’ status endpoint at this stage to find out if the payment initiation has been successful (i.e. payment order resource status is ‘AcceptedSettlementInProcess’’)and the payment progressed the payment processing stage or the payment initiation has failed. (i.e. payment order resource status is ‘Rejected’). Note: In several occasions (such as in single domestic payments), the progress from payment initiation to payment processing will happen extremely quickly and the status that could be returned by the payment order submission response or subsequent call(s) to the GET status endpoint, will be any of the statuses described in items #C or #D. This may also depend on the implementation by various ASPSPs. E Payment Processing Status In case the payment initiation is successful, the payment order during payment processing may undergo further checks. Further to these checks: If any of the checks fail, then the status of the payment order resource should become ‘Rejected’ If all aspects of the payment processing are successful, then: The PSU account is debited with the amount of the payment The payment order resource should become ‘AcceptedSettlementCompleted’’ The payment is sent by the sending ASPSP to the underlying payment system for execution A PISP could make a call to the ‘GET’ status endpoint at this stage to find out if the payment processing has been successful (i.e. payment order resource status is AcceptedSettlementCompleted’’)and the payment progressed the payment execution stage or the payment processing has failed. (i.e. payment order resource status is ‘Rejected’). Note: In several occasions (such as in single domestic payments), the progress from payment initiation to payment processing and further to payment execution will happen extremely quickly and the status that could be returned by the payment order submission response or subsequent call(s) to the GET status endpoint, will be any of the statuses described in items C, D or E. This may also depend on the implementation by various ASPSPs. F Payment Execution Status In case the payment processing is successful and the payment is sent to the underlying payment system for execution, the payment may undergo further checks by the payment system (or scheme if applicable), intermediary FIs and the receiving ASPSPs and banks. These checks may include technical and business parameters/rules specific to the underlying payment system, fraud/sanctions and business rules checking at the intermediary or receiving banks and other checking and validations related to the payment execution (subject to various implementations by relevant parties). For further details of these checks, please refer to section Payment Systems specific information – FPS payment types and status. Further to these checks: If any of the checks fail, then the status of the payment order resource status should become ‘Rejected’ If all aspects of the payment execution are successful, then: If the receiving ASPSP or bank confirms that they have received the payment but have not credited the beneficiary account yet, then the payment order resource status should become ‘AcceptedWithoutPosting’’ If the receiving ASPSP or bank confirms that they have received the payment and have applied the credit to the beneficiary account, then the payment order resource status should become ‘AcceptedCreditSettlementCompleted’’ A PISP could make a call to the ‘GET’ status endpoint at this stage to find out if the payment execution has been successful (i.e. payment order resource status is ‘AcceptedWithoutPosting’or‘AcceptedCreditSettlementCompleted’’) or the payment execution has failed (i.e. payment order resource status is ‘Rejected’). Note: There are edge cases where the payment has been received by the receiving ASPSP or bank but the payment cannot be applied to the PSU account and thus is returned to the originating ASPSP. These cases cannot be covered by the payment status as they are returned payments and will appear as incoming credits to the PSUs account. For details on edge cases, please refer to section Payment Systems specific information – FPS payment types and status.
This content is best viewed on a desktop browser. 1 CX Considerations 2ASPSP should be able to provide the PISP with payment status information across the whole payment journey, from payment initiation, to payment processing and payment execution. This payment status information should include both high level ISO processing payment status, and also lower lever payment status information specific to the underlying payment system (for example qualified and unqualified accept for UK faster payments). PISP should use this information to determine the confidence level about the status of the payment and inform the PSU (and the receiving party if relevant) about the status of the payment. Select to scroll left Select to scroll right
CX Considerations 1 ASPSP should be able to provide the PISP with payment status information across the whole payment journey, from payment initiation, to payment processing and payment execution. This payment status information should include both high level ISO processing payment status, and also lower lever payment status information specific to the underlying payment system (for example qualified and unqualified accept for UK faster payments). PISP should use this information to determine the confidence level about the status of the payment and inform the PSU (and the receiving party if relevant) about the status of the payment.
Contingent Reimbursement Model Previous Related articles Please select API specifications Change Log Next