GAS station Payments with Riverpay
RiverPay is a software company that develops integrated payment methods and marketing platforms to connect Chinese consumers with merchants globally. RiverPay focuses on developing mobile payment solutions that allow Chinese customers to pay in CYN using Alipay, WeChat Pay, and UnionPay. Typically for merchants such as restaurants or store retailers, RiverPay’s generic payment application is installed with the merchant’s compatible Point of Sale system which enables the merchants to easily receive payments in their desired currency via a different channel. RiverPay was approached to design and implement a payment system gas stations that enables customers the freedom to use different payment options such as Alipay and WeChat pay.
Company
Riverpay
Year
2020
Type
Product Design
UX Research
Design and integrate a payment channel so that customers can use riverpay without disrupting the current payment flow at Gas Station
Roadmap for Success
The team was tasked with a problem space that nobody has explored yet. The checkout experience at a gas-station is different than through e-commerce or a typical retail storefront. The information architecture was already defined for our product, but we wanted a stronger understanding of how we can make using RiverPay as seamless as possible for users. We decided that the first month of the product roadmap should be dedicated to market research, developing and testing a MVP.
01 EXploration
Exploring the User Journey
What are some problems with the current user journey, and why does this stop us from being able to implement it at a gas station?
Our current checkout flow was mapped out, and at each point we consider if it’s a viable step to be executed at a gas station flow. A typical payment flow at a gas station was also mapped out (based on the team’s own experiences at the gas stations) and compared against Riverpay’s checkout flow. We want to round out our understanding of the operational processes at a gas station.
Exploration of a Primary User’s Journey
1.2 Our Learnings From this Exploration:
Paying with AliPay is a a multi-step process for the users, and is different than the typical Canadian processes with Interact or Apple/GooglePay. For example, AliPay doesn’t offer a “tap” option, and users can only pay with a generated QR code. If the users are paying inside, then customers must interact with the clerk, and the clerk must be trained to know how to use the terminal. How ever, paying at the pump requires much more manual input from the users. Some extra steps include:
Selection Alipay vs Credit/Debit
Entering or selecting pre-authorized payment amount
Users to scan code
Our Thinking: Refilling & paying for gas is already a tedious process for many. The user flow of paying inside doesn’t add more than 2 extra steps, but what we want to do is refactor the “pay at pump” flow such that there is no cognitive overload for any users and to integrate a new interface to display the QR codes
02 Technical Specifications
1. Research
I had to do some research first into what our client (the gas station) was currently using as a part of their current payment processing system. I performed a technical feasibility study to evaluate current technical specs from the client and Riverpay’s dev teams. I established the technical requirements by reviewing RiverPay’s API and the gas station POS system to identify any potential incompatibilities. The review included an analysis of API endpoints, authentication mechanisms, and payment processing methods. After reaching out to the client and doing our own research out their payment systems, we gathered enough intel on their technical specs to inform how we can redesign our technical specs so that both systems can work with one another
2. Relevant Learnings
Our client’s current POS system is run on Java mobile & Windows OS. The connection between the POS and fuel dispenser is rigged through a Forecourt Device Controller API, provided to React POS application through a Java-based Android container. The Java Container provides an extra API to connect to hardware like Printers, Cash Drawers, Scanners, Payment Terminals, and FDC. The Forecourt Device Controller API side is a scalable, cloud-based service written on TypeScript and NestJS, PHP, .NET, and Java.
3. Next Steps
I defined some technical specifications that the dev team should follow to ensure that our product can be integrated with the existing POS system. I was responsible for defining the API endpoints/authentication as well as the payment request parameters. These specifications were then reviewed by the lead technical product manager and CTO.
Exploring the scope of the technical payment process, and how our product can be integrated with it
03 MEasuring Success
To measure the specifics of how well our search solution would work, we defined our KPIs along with secondary metrics. These were defined based on previous metrics collected on the product. For example, we can compare time it takes to complete a transaction at a retail store vs at the gas station.
Primary Metrics
Number of Alipay transactions
Conversion rate
Revenue
Secondary Metrics:
Time to complete a transaction
Error rates
Customer retention rate for Alipay users
04 Design Solution & Validation
From our design methods, we drafted several new solutions. New user flows and mockups were presented and the technical team and iterated based on the technical limitations that were presented.
Design Mockups
Reflections & My Learnings
This project really emphasized the importance of regular communication between teams in design work. It was my first time working on a project where we had to research new technology that nobody was familiar with. As a PM, I was unsure of how much technical knowledge I had to communicate to the dev team, but I learned that a strong cross-team collaboration mindset is immensely beneficial.
Some other learning experiences were the importance of having detailed designs, and considering every edge case!