Jargon Buster

If you ever find yourself confused by any of the technical jargon used in this article or the wider payment industry, don’t worry, refer to our handy open banking jargon buster here.

What is “pre-authorisation flow”?

Some ASPSP authorisation flows (account or payment) require multiple PSU authentication steps. At Yapily, we refer to this kind of authorisation flow as pre-authorisation flow and we call the first authentication step the pre-authorisation step. When the PSU completes this step, the consent status changes to pre-authorised. The consent is not in the authorised state yet. For account consent, that means that the PSU cannot retrieve their accounts data. And, for payment consent, it means their payment has not been initiated yet.

In order for PSUs to get their consent authorised, they will need to authenticate once more. This usually entails Strong Customer Authentificaiton (SCA) and is done via a security key retrieved via Multi-Factor Authentification (MFA).

Multiple authentication steps imply multiple API endpoints on the ASPSP side that need to be hit by the Third Party Provider (TPP) as part of the flow. Therefore, in most of these cases, there will be two API requests as part of the consent authorisation flow.

The first request will return an initial authorisation URL. The TPP will return the URL to the PSU and the PSU can complete the first step of authentication on the ASPSP’s authentication screen (website or mobile app) in order for their consent to become pre-authorised. The first authentication step usually entails basic customer authentication where the PSU inputs their basic username and password credentials. The second API endpoint can then be hit by the TPP to initiate the final step of the authorisation process for the PSU. This request usually contains any payment details needed for payment initiation or account details for account access as part of the request body. After the PSU has authorised via the second URL the browser will redirect back to Yapily. The consent will be fully authorised with the ASPSP.

For the rest of this article we will be strictly referring to the pre-authorisation flow for payments only. The payment and account flows are almost identical for the TPP, where only the endpoint names and request bodies will differ.

Yapily Payment Pre-Authorisation Flow

The below sequence diagram outlines the payment pre-authorisation flow for all parties involved. Note that in order to start the second authorisation step, the TTP must fetch and provide the Yapily consent token. This grants access to the Yapily endpoint where we call the consent endpoint of the ASPSP.

This flow can be summarised in five main steps:

• TPP : pre-authorisation request POST /pre-auth-requests
• PSU : authenticates (username & password)

• TPP : retrieve consent token GET /consents
• TPP : authorisation request PUT /payment-auth-requests
• PSU : authenticates (security key received via multi-factor authentication)

Why Implicit Redirect?

Pre-authorisation requires multiple PSU authentication steps. As illustrated above, TPPs need to make three API requests to Yapily and handle the multiple redirects between themselves and the ASPSP. An additional API request implies additional journey interruption, causing a potential drop out during the authorisation flow. This would mean that some authorisations may be initiated but do not get authorised.

Naturally, the flow above also makes it difficult for TPPs to integrate pre-authorisation ASPSPs. As a result, the additional endpoint and additional step of authentication make this journey for PSUs more complex than the standard authorisation flow, where TPPs only have to hit a single endpoint and PSUs only have to authenticate once.

Last but not least, pre-authorisation flow is common across ASPSPs. At Yapily, about 13% of supported ASPSPs implement pre-authorisation flow (at the time of writing this article). This comprises 252 ASPSPs, including significant banking groups that are implementers of PSD2 APIs, most of which enforce this pre-authorisation flow.

How can we improve?

The idea is to trigger the pre-authorisation steps under the hood so Yapily’s standard authorisation endpoints can be used. This will make the complex pre-authorisation flow virtually invisible from a TPP perspective and reduce the number of steps as well as the interaction time required for TPPs to authorise a consent, therefore enhancing user experience.

In the end, implicit redirect flow will look just like a standard authorisation flow, requiring only a single endpoint to be hit for TPPs. However, PSUs will still have to authenticate twice.

TPPs now need to provide all the information required to authorise the payment in the first initiation request. This includes all payment details required to complete a payment for this specific ASPSP. Once the ASPSP responds with the authorisation URL and the PSU successfully completes the first step of authentication, the PSU is implicitly redirected to the final authorisation URL without TPP involvement.

For this implicit redirect to occur, Yapily’s exchange code logic is executed as before but we no longer return the pre-authorised consent or wait for a second request from the TPP. Yapily will hit the second ASPSP endpoint internally to generate the final authorisation URL. The PSU is implicitly redirected and can complete the consent authorisation.

Yapily Payment Implicit Redirect Flow

The below sequence diagram outlines what the implicit redirect flow for payments would look like for all parties involved. Note that the additional API request from the TPP to fetch the Yapily consent token is no longer necessary because the TPP no longer needs to hit a second endpoint. Yapily has the consent context from the ASPSP response stored internally - this will be used in the next ASPSP call.

This new flow can now be summarised in three main steps:

• TPP : authorisation request POST /payment-auth-requests
• PSU : authenticates (username & password)

• PSU : authenticates (security key received via multi-factor authentication)

Technical Details

In order to implement the implicit redirect we simply trigger the existing pre-authorisation logic under the hood when TPPs call our standard authorisation endpoints. For our standard authorisation API controller to detect that we want to trigger the implicit redirect, we make use of an institution-level configuration flag.

Storage

Since TPPs only make a single request with the new flow, they will now need to provide all the information required to authorise the payment consent in this single request. This includes all payment details required to initiate a payment for this specific ASPSP. Because the payment payload is only needed for the second request to the ASPSP, we will no longer be able to access this data in memory, as the second request is triggered from the browser redirect and not the TPP request. This requires us to temporarily store the payment request data for it to be submitted later on as part of the second outgoing request to the ASPSP.

We decided to temporarily store this data in a non-relational secure key value store, which does not enforce any restrictions on the data to be stored, allowing for a quick setup and changing requirements. Secondly, during the implicit redirect flow we expect consents to spend a minimal amount of time in the pre-authorised state, meaning that in most cases there is little need to persist the payment data long-term. We generally do not expect PSUs to leave consents in pre-authorised state for more than a few seconds.

To allow for the above we created a new internal API with endpoints for the secure storage, retrieval and deletion of the request data via the non-relational database. This API can be reused to store virtually anything within Yapily and there are no restrictions regarding the data that is stored - the API simply consumes a String key and String value and inserts these as Key-Value pair into the key-value store.

Encryption

In order to protect ourselves from potential attacks, we make use of multiple third-party libraries to encrypt and decrypt the data that is stored using industry recognized strong symmetric key encryption algorithms.

Results

The new implicit redirect flow allows for a single Yapily API request to authorise consents, reducing the number of interaction steps for TPPs. Instead of having TPPs execute an initial POST /pre-auth-requests request, an intermediate GET /consents request, and a final PUT /payment-auth-requests request, the same functionality can now be achieved with a single POST /payment-auth-requests request. This has allowed us to accelerate the payment request end-to-end flow, almost halving the overall interaction time from about 110 seconds to just 60 seconds.

Using data visualisation tools to compare the number of payment authorisations initiated (the first request to start the authorisation process) against the number of payments ultimately completed over time, we have identified that since implicit redirect was implemented, Yapily payment conversion rates have increased from 36% to 59%.

Future Improvements

During the implicit redirect flow between the first and the second authentication steps the PSU’s browser is being redirected to auth.yapily.com. This will display the below loading screen.

From a PSU perspective, it would be preferable to instead directly load on the ASPSP’s website in the browser (or mobile app), making auth.yapily.com invisible.

This could be achieved by updating our successful 200 HTTP response code, which is followed by our code exchange logic to trigger the second API request, to be a 302 response code instead. A 302 HTTP response code implies that the resource requested has been temporarily moved to the URL given by the Location header. While this needs to be investigated further, it could be a potential solution to improve user experience.

Secondly, from a technical perspective, we could make the implicit redirect flow more efficient by removing our interaction with the third parties for encryption and decryption. This is because there exists the overhead of retrieving the encryption key from the external libraries for every request that is made. Furthermore, relying on third parties creates some degree of dependency. Instead of relying on third parties for symmetric key encryption of our data, we could make use of an internal encryption mechanism, ultimately avoiding the expensive outgoing calls and further enhancing our resilience.

To learn more about Yapily Payments, check out our API documentation or get in touch with us to book a demo

If these kinds of problems sound interesting to you, check out our Yapily Careers page for current openings.