A2A Routing & Redirection Paths

Understanding the network architecture and fallback mechanics of Open Banking gateways.

The Redirection Flow

When a payment is initiated, the Pisria gateway determines the optimal authorization route based on the user's selected bank. The process strictly follows OIDC (OpenID Connect) standards embedded within FAPI (Financial-grade API) profiles.

1. Intent Creation: Merchant calls POST /v1/payments. Pisria registers the intent with the target bank.
2. User Redirection: The user is redirected to an authorization URL (e.g., https://auth.barclays.co.uk/...). If on mobile, universal links intercept this and open the native banking app.
3. Authentication: The user authenticates (FaceID) and confirms the exact amount and payee.
4. Callback: The bank redirects the user back to the merchant's redirect_uri with an authorization code.
5. Clearing: The bank clears the funds via the underlying scheme (Faster Payments in the UK, SEPA Instant in the EU).

Fallback Vectors

Open Banking APIs are not infallible. Some European banks suffer from unannounced downtime or degraded performance. Pisria implements intelligent fallback routing:

• Screen-scraping (Modified Customer Interfaces): Where permitted by local regulators, if the API is down, we fall back to a secure credential-sharing flow.
• Manual SEPA entry: As a final resort, we provide the user with structured IBAN/Reference data to execute a manual push from their app.

Common Implementation Mistakes

Merchants often fail to correctly handle the asynchronous nature of the callback. The user redirecting back to your site does not mean the payment is settled. It means the intent is authorized. You must wait for the definitive webhook (e.g., payment.settled) from Pisria before dispatching inventory.