Transaction Timeline

We’ve been working on the development of a transaction timeline during the last few weeks. This new feature provides you with additional information and visibility why your customer might have abandoned the checkout. Using this tool correctly can have significant impact on your conversion.

Why is this important?

Standard payment integration allows you to see the status of a payment transaction. You gather from there if the transaction could be processed successfully or if it was declined. However, I do not know of any payment provider that shows you exactly what happened during the checkout process, when which button was pressed and which details the customer entered. In order to do this, you normally have to install additional tools like hotjar. We therefore decided that it is this one key value we want to provide to our merchants: Visibility within the transaction flow. Because this is the basic foundation for you to optimize your checkout.

We revised our transaction timeline design completely. Having a look at this transaction timeline now gives you the opportunity to see and understand the different steps your customers went through. In this blogpost, we’re going to show you a few examples of these different kinds of transaction timelines. Seeing it, enables you to understand how you can take advantage of this feature.

How it works

The transaction timeline can be used as a control and monitoring tool. You can see at which point the customers’ order has failed to complete the transaction and for what reason. The transaction timeline will give you insights why the customer could not complete the order. This should provide you with additional information on how the sales process can be optimized and therefore increased.

We record any action that occurred related to the transaction. This includes the different events during the checkout, too. We’re going to dive a bit more into the events related to the checkout process. The other events are most likely quite obvious.

Every successful transasction will undergo the following process at least once:

1. Pre-Validation: During this pre-validation process, we determine the payment methods, which are available for a particular transaction. We reject payment methods where there is no suitable payment connector. A connector may not be suitable when the currency of the transaction is not applicable to a connector.
2. Form Generation: When the customer chooses a particular payment method we try to render the form for entering the payment details (e.g. credit card number). Failures in this step are unlikely since we ensured that the payment method is available in step 1.
3. Validation: Once the customer clicks on the pay or continue button, we validate the provided payment details. When the JavaScript (browser side) validation succeeds, we send the data to the server and validate the input there as well. We consider this step as failed, when there is no connector that validates the payment data successfully.
4. Authorization: Depending on the integration, we may trigger the authorization of the transaction immediately after the validation. The other option is that the customer has to confirm the order. If you choose this option, we’re going to send the transaction to the payment processor. In case the transaction fails, we try the next connector automatically. When there is no connector that is able to process the transaction, we consider this step as failed.

Sure, not each transaction will have this straight flow. Some or all steps can be repeated, depending on the sales journey of the customer. Below you find some examples to illustrate typical transaction flows and the related information in the timeline.

How to read the transaction timeline

There are always a few options, why a transaction could not be authorized (e.g. technical issues, the customer closes the window, connection issues, 3D Secure, etc.). In order to tackle potential issues effectively, it is important that you know why and where the customer stopped the sales journey. It is the worst case scenario if you loose a customer in the checkout as he has already committed to buy the product and marketing and maybe pre-sales support expenses have already happened at this stage.

Therefore, the transaction timeline is the solution to understand, why the transaction could not have been created during the purchase process. Whenever there’s an error, you can see a red cross as well as a short sentence in form of a mistake description. You do also have an overview, which connector has been chosen in every purchase.

Basic Example: successful transaction

In order to receive a successful transaction, the mentioned four steps have been passed. The payment methods have been determined in the first step, the payment form has been generated and the provided payment details got validated. Lastly, we've triggered the authorization of the transaction.

Example of a correct transaction flow

Example 1: Currency Mismatch

In this case, you can notice that TWINT as well as ESR have not been chosen as payment methods. The reason is, that these two payment methods only support Swiss francs as a currency. This is indicated in the pre-validation step where you see the error why TWINT and ESR were not visible.

Successful transaction with showing that TWINT & ISR are not in use

Example 2: Incomplete checkout after choosing the payment method

This example shows that all the necessary payment methods were determined but the customer has not loaded the form for entering the payment details. This happens mainly if you offer additional payment options that do not run through wallee and therefore the customer simply chooses another payment method. It can also happen if the customer stopped unexpectedly during the checkout.

Failed transaction as the customer has not loaded the payment form

Example 3: Customer did not finalize the transaction

The third example shows that the payment form has been generated and we even forwarded the customer to the Sofort page but he never returned successfully. New is that you now have complete visibility where in the payment process the customer failed to finalize the transaction.

Failed transaction as the customer did not return from SOFORT

Example 4: Authorization Error

In this case, the transaction failed because the timeout has been reached before the successful authorization has been carried out. The reason is, that the provided payment data were invalid according to a rejected solvency check.

Invalid payment data due to a rejected solvency check

Requirements and costs

The transaction timeline is a basic feature and therefore available in all wallee subscriptions.

Support

If you have any remaining questions, do not hesitate to contact us.