Execution of an authorized payment instruction made conditional on manual user redirection

If an Account Servicing Payment Service Provider (ASPSP) makes the execution of a payment instruction, already successfully authorized via Strong Customer Authentication (SCA) in its app, conditional on the Payment Service User (PSU) subsequently manually returning from the ASPSP's authentication app back to the Third Party Provider's (TPP) environment, does this condition constitute an obstacle under Article 32(3) of the RTS?

Article 32(3) of the RTS prohibits obstacles to the provision of PIS and AIS. Paragraph 16(ii) of the EBA Opinion on obstacles (EBA/OP/2020/10) further clarifies that after a successful authentication with the ASPSP, the PSU must be " automatically redirected back to the AISP/PISP’s app, without for example the PSU having to manually reopen the TPP’s app, which would be an obstacle ". A critical issue has been observed in practice where some ASPSPs go beyond a mere failure to automatically redirect. In this scenario, a PSU successfully authenticates a payment instruction within the ASPSP's app and is shown a success confirmation message (e.g., "Successfully confirmed"). However, the ASPSP does not execute the payment instruction unless and until the PSU manually navigates back from the ASPSP's app to the TPP's environment (app or web). If the user closes the ASPSP's app, believing the payment has been made, the payment is never processed. This makes the execution of an already authorized instruction conditional upon a subsequent, non-obvious manual action by the user. It is unclear if this practice, which fundamentally compromises the payment instruction itself, is merely an obstacle or a more severe breach of the RTS.