Introducing Rave Checkout: A Mobile First approach to payments for Africa.
Rave Checkout(apay button designed and engineered by Flutterwave) is a very important part of the Payment experience we have been building, and we are very excited to announce that the Checkout Form will be getting a massive upgrade in the coming weeks.
For now, we are still in the process of building out this mobile experience and making sure it improves and enhances the Flutterwave payment experience. Let's have a lookat the design direction and some of the exciting new features of Rave Checkout!
Somebody say MACHINE LEARNING RAVE CHECKOUT?
At the moment, the Rave checkout experience on a mobile phone is not very pleasant. How have we survived then? Maybe it’s not that bad or maybe our customers don’t pay for airline tickets on their mobile phones. Or do they?
60% of the payments we have processed since the first Rave Checkout have come from mobile phones.
Most of these customers make payments via the Opera Mini browser!(put a link here)
Most of them use smartphones.
No surprises here actually; we are in Africa aren't we? If we are able to get these results with a process that is not optimized for getting them, what happens if we do?
The Redesign
First we need to answer a few questions to give us direction.
Who is the product for?
People paying for goods and services via the opera mini browser.(These people account for the 60% of our traffic)
People paying for goods and services via modern mobile browsers.
People paying for goods and services with their smartphones.
People paying for goods and services on their laptops/desktop computers.
What problems do they want solved?
They want to pay for goods and services as fast as possible.
They have trust issues; they cannot afford even one error.
What is their big goal?
Complete the payment(successfully) with a sense of security.
What is their secondary goal?
They may have a variety of secondary goals, many of which aren't always apparent; perhaps they want to enjoy simple pleasures without the stress of the process overshadowing their enjoyment of it, or maybe they want to be able to send that tweet about getting Lebron Sneaks!
So what are we building?
We are building a fast, reliable, flexible, and simple payment button and service called Rave Checkout that users can always trust.
Why might someone not want to use Rave Checkout?
They may lack trust in it.
They may not be familiar with it.
They may have had a terrible payment experience or experiences in the past.
Given the above questions and the answers to them, the question then becomes: what are the metrics? What are we looking to improve on? The only way to know the redesign is successful or not is to have trackable metrics; something we can always go back to for comparison. Watch out for Part 2…
Somebody say
MACHINE LEARNING RAVE CHECKOUT?The Redesign
Who is the product for?
What problems do they want solved?
What is their big goal?
What is their secondary goal?
So what are we building?
Why might someone not want to use Rave Checkout?