Wepay is a payment processing platform that was acquired by JP Morgan Chase in 2018. Clear, the company's core product, is a white-label payment solution. During the summer of 2022, I interned with the Payments Platform team as a product manager.
I was given a problem statement to work on, for which I had to create a PRD (Product Requirement Document) and launch a potential MVP solution.
"Let's develop solutions to reduce the number of merchant payout returns/failures"
Whenever you pay for a cup of coffee with a credit/debit card, the money isn't transferred directly to the coffee shop's bank account. It is first sent to the their payment processing platform (Stripe, Paypal, Wepay…). The merchant (coffee shop in this case) then schedules a payment to its bank account from the payment gateway.
This is called a "Merchant Payout".
Sometimes, however, these merchant payouts don't go through and fail, and the coffee shop does not get paid as scheduled. This creates friction between merchants and Wepay, and leads to a negative user experience and an overall bad brand image.
After meeting with various teams to understand Wepay's data infrastructure, I identified which BigQuery tables would provide me with a holistic picture of payout returns. Using SQL and Looker, I then merged tables, cleaned data, and synthesized my findings to create a story.
This was much lower than what my team and I expected. That said, I needed to investigate further as I did not have a benchmark to compare this rate to.
Besides merchant info, $ value, and other general information, each failure entry also included an ACH reason code, which described WHY the payout failed. The most common ones were:
While conducting my research, I also stumbled upon an unexpected finding:
What are recovery attempts? They are a mechanism under which Wepay tries to recover funds from a merchant after a chargeback or payer refund (caused by fraud or other).
It seemed that recovery attempts failures were a much bigger problem than payout failures. That said, I still kept working within my scope (payout failures) at that point.
To complement my data analysis, I interviewed both internal stakeholders and the Zendesk team (Customer Experience) to get a deep understanding of the problem (if any):
It seemed like a big reason for a push to work on a merchant payout failure solution was driven by the market; main competitors had an instant bank verification feature that allowed a major reduction of R03 and R04 returns.
Through my interviews, I was also able to confirm my hypothesis that recovery attempt returns were both a more urgent and important problem than payout returns. Specifically, there were several millions of $ written off as a loss due to the inability to retrieve funds from merchants.
I then laid out the foundations of MVPs for both payout and recovery attempt returns. While the scope of my work extended, I also had to get buy-in from the Chargeback team (overseeing recovery attempts) to work on the latter.
Based on my research, I assumed that most of the ~2,000 instances/year of payout returns were caused by merchants fat-fingering their bank details. I thought of and developed pilots for 3 potential solutions:
Of the ~$15M of failed recovery attempts, less than half ends up being recovered (which in itself requires substantial resources and time). I worked through the following solutions to drastically reduce failures from happening in the first place:
While I was able to develop wireframes for better merchant communication and education emails, I could not launch any features during my short time at Wepay.
That said, I created a detailed document outlying the context so that all relevant teams were informed about the issues and the current processes in place.
Bias for Action
Sometimes, it's better to act quick to avoid analysis paralysis
Technical Expertise
Critical to earn the trust of engineers and establish a sustainable team dynamic
Confidence
By pushing back on unchecked assumptions, I showcased the importance of thorough research to my team