Photo by Fabian Blank on Unsplash
In the fintech industry, there are several times when your user journey involves dealing with bankwire payments. This can be for topping up a e-wallet, to make an investment or to pay a bill. When the amount is over €2500, the preferred mean of payment is the bankwire.
This article will study a basic case of user journey involving a bankwire payin (SEPA) and explore ways to enhance it.
Note : This article is the first of a new serie called Fintechs’ crumbs exploring the fintech’s web journey.
1. The use case
Let’s take a random and imaginary fintech called SmartFintek. On SmartFintek, users can top up their e-wallet. The e-wallet is used only for big transactions so the only mean of payment allowed is the SEPA bankwire.
A basic “top-up your e-wallet” page (web)
The top up process is basically the following:
1. User logs-in to SmartFintek
2. User goes to his wallet and chooses “Top up”
3. User is provided an IBAN and a BIC linked to his e-wallet
4. User does the payment with his bank
5. User receives the money on his SmartFinteck’s e-wallet
As we can see, this is a very basic user journey that you might have experienced or implemented for your users if you own a fintech. Now let’s dig up some accurate data about how the final users actually experience this journey.
There are two main questions that we need to ask ourselves :
What is the most used device type for this user journey ?
How does the user actually make the payment ?
Photo by Jessica Lewis on Unsplash
What is the most used device type for this user journey?
a typical web device usage repartition chart for Fintechs (made with AM charts)
If we head up to Google Analytics, here’s what we can see about our users’ devices repartition. At CapSens, we work with a lot of fintechs and these stats are representative of the sector ; almost 2 thirds on desktop, 1 third on mobile and 5 to 7% on tablet.
Based on this graphic, you’d say : “Ok then we have our answer. 2 thirds of the users will do the top-up process on desktop and the other third on their mobile”. Not quite.
The repartition above is an average for all the visitors of the website and for all the pages including the homepage or other content pages. If we want accurate data about the devices repartition for the topping up process, we need to dig a little more.
a typical web device usage repartition chart logged-in pages for Fintechs (made with AM charts)
This chart now shows the device usage repartition for pages accessible upon login (all pages nested inside /account for instance). We clearly see that the desktop is now very dominant with almost 80% of the total usage and mobile devices now account for only less than 20% of the total usage, tablets on the other hand are nearly insignificant with less than 4%.
Ok so we have a user journey that will happen mainly on desktop devices. Now let’s focus on the payment itself.
How does the user actually make the payment ?
To perform the bankwire, our users have three possibilities :
Use their banking website => desktop
Use their banking mobile app => mobile
Use an ATM
(yes such thing does exist) => ???
First of all, the answer to this question might depend on the age of our audience. Does Analytics provide this data? Yes it does :
Chart of the sessions by age (made with AM charts)
The chart above shows us proportion of sessions by different age slice. We can see that 25 to 34 years old visitors account for more than 30% of the total sessions.
Hum .. that’s good but not enough. Let’s see if we can dig up a little more with these data.
Cumulative chart of the sessions by age (made with AM charts)
Now the chart above is cumulative, in other words it gives us the proportion of sessions from visitors born before a certain date.
The red guide is here to highlight the fact that 80% of the visitors are born before 1966.
Based on this stat, we can now look out for data about how people behave as far as they are less than 54 years old: do they go to an ATM, use their computer or their banking mobile app ?
According the fifth edition of the famous Deloitte’s (one of the “Big Four” accounting organizations) study “Les Français et les nouveaux services financiers” (French and their new financial services”) :
How French people perform bankwire payments according to the 5th edition of “Les Français et les nouveaux services financiers” by Deloitte (chart made with AM charts)
As expected, there are only 3 ways to perfom a bankwire but the most used is the mobile banking app accounting to 43% of the total usage. Then comes the banking website (35%) and last but surprisingly not least comes the ATM or agency (17%).
Now let’s explore what this most common case induces for the user journey.
User journey with a mobile banking app performed bankwire transfer
As we have seen earlier in this article, this user journey is the most common scenario:
User gets the banking coordinates (IBAN & BIC) on desktop
User uses its smartphone to add the new beneficiary
(if it’s the 1st time) and initiate the bankwire transfer.
Our user journey is not seamless ; the user switches from desktop to mobile to perform the bankwire. Hence we have a rupture in the flow.
User journey with a mobile banking app performed bankwire transfer
Given this fact, we can now ask ourselves : How to make this user journey the easiest for the final user ? Let’s explore some tracks.
Manually typing the IBAN and BIC
If you didn’t take any particular measure for the top up flow, this is what 43% of your users are doing. I’ve done it many times; you read the IBAN and BIC on your computer screen and you type each character one by one on your smartphone. An IBAN can be up to 34 characters long. Hew !
Okay we all survived this experience but this is not what we can call a good UX. Let’s see if we can find a better solution.
Send coordinates by mail
To avoid the user to manually type the IBAN and BIC, one solution could be to send the coordinates by email to the user so that he can copy the IBAN and BIC from it and paste it inside his mobile banking app.
It seems okay but somewhat not terrible. There might be some trouble with the email reception. Transactional emails often come with a delay, end up in the spam folder or don’t reach their destination at all.
EPC QR Codes
These QR Codes can be used to initiate SEPA credit transfer. They are defined by the European Payments Council. Basically you get a QR code and when you scan it with your mobile banking app, the bankwire is created, you just have to verify its beneficiary and amount and in a click you have initiated the bankwire transfer. Awesome, no ?
Well unfortunately, there’s a huge no-go : only a few european countries support it : Austria, Belgium, Finland, Germany, The Netherlands. So unless your users are located in one of these countries, no EPC QR Codes for you!
Allowing the user to access the page with its smartphone
One other solution could be to allow the user to access the page from his smartphone. One big setback for this is the authentication : the user might be reluctant to reproduce his journey on an other terminal :
Go to the website
Log in
Go into his account then to “the top up your wallet” page
That’s a lot of steps just to avoid to manually type 45 characters (34 + 11). But can’t we find a solution to make it faster ?
We have a user already logged in on its computer and we have a smartphone. What can we do about it ?
One solution could be to set up a QR Code that contains a direct URL to this page. The user would just have to scan it with its smartphone camera and is automatically redirected to the same page on its mobile.
Wait. What ? Without authentication ?
The page accessed with the QR code would only contain the IBAN and the BIC. These are not sensitive data. Don’t you see these on every invoice? Moreover the link could be secured with a token to ensure that these data couldn’t be accessed without knowing the token. Last but not least, the token could be strong enough to ensure that it would be hard to brute force it.
Let’s try to set up this functionality.
1. The user can display a QR Code by clicking on a “see this information on your mobile phone” link.
The link should not be displayed on tablets and mobile devices otherwise it would be weird. In my solution, a click on the link displays a modal with QR Code but there are plenty of other solutions (tabs, collapsing content…).
The “Credit my SmartFintek’s wallet” page with the link added
2. The user gets the QR code
Here, the QR Code is server side generated. To achieve this, there are many APIs available such as the Google Chart API (recently deprecated). For this article, I coded the website in Ruby on Rails, so I used a rQRCode gem which is really straight forward.
The gem allows to choose whether the output should be a .png or a .svg. In my opinion .svg achieves a more precise rendering (no pixellization) and is lighter than a png file. Besides the options, it requires a content which is here a link.
The link to the wallet page (token version)
Concerning this link, the process is pretty straightforward. Each user is given a unique token in the database. This token is added to the URL as a parameter (green color). Whenever someone tries to access the page, we search if the token exists in our database, if it does we fetch the wallet infos and display them, else we return a 404 Not found error.
As you can see the token is unbearable, that’s why we never display it directly to the user. The URL containing the token can be found only by scanning the QR code.
The generated QR code
3. The user scans the QR Code and is redirected to the same page on his mobile phone
That’s it! If you’re interested in the technical implementation you can take a look at the full code here (Rails 6 / Ruby 2.6.2).
This functionality enhances the user journey of the ones that use a mobile banking app to perfom the bankwire (43% of our users). On the other hand, this does not help the 17% that go physically to an ATM or at their bank’s front-desk. One easy solution could be to also implement a “send the payment instruction by mail” button so that they could have the banwire coordinates in their mailbox ready to be used whenever they’ll need it. Regarding the 35% that do all the process on their computer, the flow is already simple for them as there is the fast-copy button for both the IBAN and the BIC.
Et voilà. Don’t hesitate to give me a feedback on how you actually handled this user journey (maybe you’d like to share a better solution that you found).