734 Followers
·
Follow

Case Study: Olacabs — Debit card payments

a.k.a Debit Card Fraud Prevention

The Problem

Payments made via debit card were deferred payments. Which means, Ola would have to trust the user to make the payments after the ride ends or before he takes his next ride. While most users honored and made the payments immediately after the ride ended or before the next booking, there were few users who used this to de-fraud the company. Users with intention to defraud used this deferred payment to take the ride and never comeback.

Backstory

Ola has its own wallet, Ola Money. Maximum rides are either Ola Money or Cash. Credit and Debit cards were not even close to the staggering numbers of Ola Money wallet or Cash payments. But one decision by India’s Reserve Bank of India was set to change this.

Reserve Bank of India a.k.a RBI mandated all the digital wallet (Ola Money, Paytm, Freecharge, Oxigen etc.) users be KYC verified. Users would have to do a mandatory KYC (Know your customer. Details which helped us and RBI identify the user using the app). Just like you do when you open a bank account. This meant, the wallet apps would have to go the extra mile and ask users to be KYC verified, else their wallet would cease to exist. They wouldn’t be able to use the app to make their cab ride payments anymore. This meant, either we would experience a sharp dip in ride, or increased cash transactions. But, once a cashless user, always a cashless user. Ola would have to open up Debit and Credit card payments to most of its users, which meant the defaulter numbers would sky rocket.

With this backstory, we had to look forward for a robust fraud capture mechanism and prevent it from happening.

Ideas

This whole product construct went to Product Spec to Design and back to drawing room 3 times. We had to identify various connected sections and provide an experience with minimum friction. The whole idea kept refining till we reached a minimum friction solution which would cater to all users. There had to be a mechanism to identify high risk users and take them to a different flow and no-risk (trusted) users to a different flow. Some of ideas which were bounced off.

  • Ask the user to make an authorization to charge the debit
  • Ask the user to make the payment within stipulated time (15 mins) after the ride starts.
  • Get the user to make the payment when he is riding, maximum 5 minutes before the ride ends
  • Convert the payment mode to cash if the user fails to make the payment

While some of the solutions appealed, we were most concerned about ruining the experience of a trusted rider. He didn’t do anything wrong to get that kind of experience.

Solution

After a lot of deliberation, delay, we finally arrived at a solution which would provide unchanged experience for trusted user, while get the untrusted user to pay upfront before his ride ends.

Flow depicting trusted user’s journey.
Flow depicting non-trusted user’s journey.
Various notifications to keep user informed throughout his journey
Various states of the payment card

Written by

Designer. Current: Sr. Product Designer @Ola. Prev: Design Lead @Scandid.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store