An Obstacle Free Redirection Based Customer Journey for Payment Initiation and Account Information Service

The evolution of Open Banking and regulatory frameworks like PSD2 has fundamentally shifted the financial landscape, empowering Third-Party Providers (TPPs) to offer enhanced financial services. Central to this ecosystem are the Payment Initiation Service (PIS) and the Account Information Service (AIS). While various technical methods exist for connecting these providers with banks, the redirection-based model remains the most prevalent due to its compatibility and relative ease of implementation. However, the user experience in these flows is often fragmented, leading to high drop-off rates. To maximize adoption and trust, it is imperative to design an obstacle-free redirection-based customer journey that is seamless, secure, and intuitive.

The Redirection Model and Its Challenges

In a standard redirection flow, the customer is transported from the Third-Party Providers (TPP) interface to the Account Servicing Payment Service Providers (ASPSP)the banksenvironment for authentication and authorization. Once the action is completed, the user is redirected back to the TPP.

The primary friction points in this journey include "context switching," where the user feels disconnected from the original goal, and technical discontinuities such as session timeouts, broken deep links on mobile applications, or lack of clarity regarding the return path. An obstacle-free journey eliminates these friction points, ensuring the transition between the TPP and the bank feels like a single, unified experience rather than two disjointed interactions. The goal is to reduce the cognitive load on the user and the technical latency between systems.

Payment Initiation Service (PIS): The Ideal Flow

For Payment Initiation Services, the objective is to authorize a transfer of funds. The user is typically in the middle of a checkout process or a bill payment scenario. Any hesitation or confusion can lead to cart abandonment. An obstacle-free PIS journey follows a distinct, optimized path.

• Initiation and Clarity: The journey begins at the TPPs checkout. When the user selects their bank or "Pay by Bank," the TPP must clearly display that the user is about to be redirected to their banks secure environment. Managing expectations is the first step in reducing friction and building trust.
• The Seamless Handoff: When the user proceeds, the redirection must be instantaneous. On mobile devices, an obstacle-free implementation utilizes app-to-app redirection. If the user has the banks mobile application installed, the flow should trigger a deep link to open that specific app directly to the payment authorization screen, rather than launching a web browser where the user may need to log in again.
• Authentication within Context: Upon arrival at the bank, the user authenticates. To ensure the journey is obstacle-free, the bank should recognize the context of the request. The payment amount, the payee, and the reference should be pre-filled based on the data sent by the TPP. This ensures the user does not have to re-enter data, minimizing errors and frustration.
• Authorization and Immediate Feedback: The authorization screen must be unambiguous. The user is asked to confirm the specific transaction. Once confirmed via Strong Customer Authentication (SCA), the bank must provide immediate feedback that the transaction is successful.
• The Precision Return: The most critical stage for retention is the return loop. The bank must automatically redirect the user back to the TPPs landing page. This redirect should be parameterized to pass back a transaction ID or status code instantly, allowing the TPP to display a confirmation page without the user having to wait.

Account Information Service (AIS): Building Trust through Transparency

For Account Information Services, the user is granting consent for a TPP to access their financial data. The journey hinges on trust and the clear communication of permissions (scopes).

• Consent Elicitation: The journey starts on the TPP's dashboard. The TPP must transparently explain exactly what data is being requested (e.g., balance, transaction history) and for how long the consent is valid. An obstacle-free design presents this in simple, non-legalistic language.
• Bank Selection and Routing: The user selects their bank, and the TPP generates a redirection request. This link contains the necessary "consent ID" so that upon arrival, the bank knows precisely which permissions the user is reviewing, eliminating the need for manual selection on the bank side.
• The Bank Consent Interface: Upon reaching the bank, the user authenticates. The bank presents a screen that mirrors the permissions requested by the TPP but in the banks own trusted UI. To avoid obstacles, this screen should not bury the "Approve" button under layers of legal jargon. It should be a clear, summarized view of the permissions.
• Data Delivery: After the user grants consent, they are redirected back to the TPP. The TPP then uses the granted authorization code to fetch the data. An obstacle-free journey ensures this data populates in real-time. If there is a minor delay, a visual progress indicator is essential to prevent the user from thinking the redirect failed.

Technical Components for a Frictionless Experience

Creating an obstacle-free journey requires strict adherence to technical standards and cooperation between the bank and the TPP.

State Preservation: The redirection process relies heavily on the "state" parameter. The TPP generates a unique token and sends it to the bank. The bank echoes this back in the response. This mechanism ensures that when the user returns, the TPP can recognize exactly which session to resume. This prevents errors such as CSRF attacks and ensures the user does not lose their shopping cart or application context during the switch.

Error Handling Presentation: Errors are inevitableperhaps the user cancels the payment, the session times out, or the bank systems are down. An obstacle-free journey handles these gracefully. Instead of displaying a cryptic "HTTP 400 Bad Request" error or a blank screen, the bank should redirect back to the TPP with a specific, standardized error code. The TPP then translates this into human-friendly language, such as "The payment was cancelled at the bank. Please try again or use a different payment method."

The Role of SCA and Mobile Optimization

Regulatory requirements demand Strong Customer Authentication (SCA), which inherently adds steps to the customer journey. Designing an obstacle-free experience does not mean bypassing security; it means integrating security smoothly. The use of biometric authentication (FaceID, fingerprint) via the bank's mobile app is the gold standard. This allows the user to authenticate and authorize in a single motion without typing passwords or SMS codes.

Furthermore, considering that the vast majority of Open Banking interactions occur on mobile devices, the redirection flow must be mobile-first. This means avoiding pop-up blockers and ensuring that web-views within apps handle cookies and session persistence correctly. A truly obstacle-free journey leverages deep linking to switch from the TPP app to the Bank app and back again without ever exposing the user to a clunky mobile web browser experience.

Conclusion

An obstacle-free redirection-based customer journey for Payment Initiation and Account Information Service is the cornerstone of successful Open Banking adoption. By focusing on the continuity of the user experience, leveraging state-of-the-art mobile deep-linking, handling errors with transparent communication, and integrating biometric security, financial institutions and Third-Party Providers can remove the friction that causes drop-offs. The ultimate goal is to make the complex security infrastructure of open banking feel invisible to the user, allowing them to initiate payments and access information with speed, confidence, and ease.