Reducing fake pickups with a pickup verification code
How we improved Heetch’s reliability with a radius and code to verify pickup.
I’m a Product Manager at Heetch, a ride-hailing platform operating across Europe and Africa. Within the Booking and Ride Experience team, one of our objectives is to offer the most reliable ride experience to every passenger and driver on the platform. Some of this involves detecting fraudulent behaviors and preventing them while ensuring that we’re not blocking any legit rides.
Heetch Pickup Code Verification is one of the features I worked on that was shipped in October 2022 to Heetch passengers and drivers, and this post documents how we came up with this solution.
[Problem] How enabling drivers to indicate pickup from anywhere led to fake pickups
Anna has been invited to a birthday party starting in 30 minutes. So she calls a Heetch ride and Heetch says that her driver, Rayan, is on his way and should arrive in 5 minutes.
As she’s waiting, Anna looks at the Heetch app. All of a sudden, it looks like she’s already in the car and she can no longer cancel. It’s because Rayan indicated pickup already. She doesn’t understand what’s happening and the driver doesn’t take her calls.
A few minutes later, the driver indicates dropoff, and Anna receives a notification from her bank of a charge for a ride she didn’t even make. Shortly after, Heetch identifies this behavior with an algorithm and automatically pays back Anna for the ride — but the horse is already out of the barn: Anna feels really mad at Heetch and won’t ever order again.
In an ideal world, passengers order from a pickup address, where drivers meet them. Drivers start the ride in the app when the passenger enters the car, and they ride together to the dropoff point.
However, some drivers may indicate pickup while the passenger is not yet in the car —because:
- Heetch doesn’t enable passengers to cancel during the ride so starting the ride early enables drivers to avoid being canceled by passengers,
- Drivers believe they can make easy money in case the ride is paid by card,
- Drivers do not have access to certain information before starting the ride so they fake the pickup, and later cancel it when the ride doesn’t meet their expectations,
- Drivers do not want to impact their cancellation rate
- …
[Solution #1] Preventing fake pickups far from the requested pickup location
As we started looking for immediate solutions to decrease the number of fake pickups, the focus was to prevent drivers from indicating pickup without being near the passenger-requested pickup location. So it was decided to implement a radius around it. When drivers enter this radius, we consider they’re close enough to the pick-up location for the pickup to be legitimate. Otherwise, we warned drivers they needed to get closer, and the pickup was locked.
However, this would prevent some legitimate rides to be started, such as when:
- Drivers forget to start the ride after picking up the passenger. When they realize it, they’re already on their way, or even (most of the time) at the dropoff point.
- Drivers can’t meet the passenger at the requested pickup address, such as within pedestrian areas or parks — where we haven’t implemented suggested pickup points.
- Passengers request pick up at the wrong address and call the driver to let them know they should meet somewhere else. This happens very often in some of the Western African countries where we operate, as some areas can be poorly mapped and local landmarks are used instead to help drivers find their way.
While drivers may find workarounds, this experience was painful because they got frustrated with the basic ride flow and ultimately had to cancel and give the ride off-platform, even though this is not what they intended to do. So by solving our initial problem, another one was created — and we had to use a loose radius around the pickup before adding an extra layer to our solution.
[Solution #2] Enable drivers to start all legitimate rides from anywhere, without increasing fraud
How would we know that we solved the problem? The first signal of success would be the increase in completed rides after an attempt to pick up passengers outside of the pickup radius (with fewer rides given off-platform). Because we would add a constraint to drivers, we also wanted drivers not to feel like they had to exert too much effort to start their rides by asking them “How easy was it to indicate pickup after you used the pickup code verification today?” (User Effort Score).
Once we had a good sense of the objective and the requirements, we explored different directions of identifying that passengers and drivers were on a ride together- including location-based locks (which could be an issue in low-network areas) or unlocking the ride with NFC contact (which could be an issue when ordering for someone else).
We decided to focus on a code shared by passengers to verify the ride. When drivers try to start the ride outside of the pickup zone, riders are given a code. When the passenger is in the vehicle, they can verbally communicate the code to the driver. The driver must enter the code into the app, and if the correct code is entered, the pickup is validated.
Our next step was to map the flows to be able to kickstart the technical discovery, as we figured out that there were some challenges to ensuring that the passenger would receive the code exactly when the driver would need it, including in countries with poor network connections.
In the meantime, our product designer took the requirements and explored different code approaches. Heetch is a playful brand and he suggested exploring variations beyond the basic number code, such as variants made out of emojis.
It was time to test the designs with drivers to gather insights on how they felt about asking for information from passengers and understand what was the easiest information that passengers could communicate to them. The takeaways of the research were:
- Most drivers either didn’t care or felt reassured about asking for a code from passengers.
- Drivers highlighted the need for convenience and efficiency, hence they largely favored a number PIN code. They mentioned that numbers are easier to read, communicate and find on a keyboard, and work better with all types of passengers.
- Drivers highlighted the need for safety and were worried that other drivers would try to cheat the system, or that passengers wouldn’t be able to communicate the code (in case they would no longer have battery on their device, or wouldn’t be the person ordering).
All insights influenced how we ultimately designed the feature, which is fairly straightforward:
- We picked a 3-digit code, which would be reliable enough with 1000 possible combinations and more convenient than a 4-digit code.
- When the drivers are close enough to the requested pickup, they can start the ride without needing the pin code. This is to ensure that legitimate rides don’t encounter unnecessary friction.
- To prevent abuse, drivers have up to 5 attempts to enter the code correctly. After 5 incorrect attempts, a timer locks further attempts for a minute.
- In the first drop of the feature, we only enabled drivers to request a pickup code when both they and the passengers would have compatible mobile versions. In a second drop of the feature, we enabled drivers to request a code from any passenger by leveraging our in-ride chat.
- We decided not to handle the case when the ride would be an order for someone else, thinking that passengers themselves could share the code with the person they were ordering for.
The pickup code verification is now available in the Heetch app 5.61+ on both iOS and Android and is enabled in all countries where we operate. Please feel encouraged to leave questions, suggestions, or insights from your own experience, I’d be happy to hear them!
Congrats to all my colleagues without whom this project wouldn’t have been possible: Bastien Gillet, Przemysław Cackowski, Ignacio Ruiz Martin, David Hontecillas, Charles de Lassence, Joana Da Costa, Kiril Popadinski, Christophe Dufour, Mathieu Jacob.
