Some of my favorite stories are about how a team worked through a hard problem and found a solution together. That’s how WingCash LLC discovered payment codes.
A few years ago, our team noticed that businesses were having a hard time accepting WingCash because the businesses couldn’t easily match a WingCash payment with an order. Since customers were expected to simply send money directly to businesses, many customers sent cash well ahead of time, leading to confusion and mistakes. How could the cashier verify that the customer actually paid? Customers showed cashiers their payment confirmation screen (sometimes even a printed copy of the confirmation screen), but that wasn’t enough to solve the problem.
I built a solution that involved having the customer and the cashier both enter the exact amount; the payment would complete only when both confirmed the amount. We tested that solution internally; it bombed. The solution was worse than the problem. I thank my tester for revealing just how bad that idea was.
So we decided to focus all our efforts on solving this specific problem. After a few of days of thinking and discussion, the solution emerged: we would create a short code that customers were expected to tell cashiers in order to complete the payment. The code would be valid only for the specified recipient, so it would be possible to keep the code quite short. If the code were not accepted within a time limit chosen by the customer, the code and payment would be canceled.
It took time to figure out what to call this concept, but once we came up with “payment code”, we knew it was the right name. It took years after that to figure out exactly how payment codes should behave. We initially decided that creating a payment code reserves money from the sender’s wallet, but that turned out very limiting for the liquidity algorithm. We needed the algorithm to choose which cash to send as late as possible, providing the best possible deal for the customer. So today, payment codes don’t reserve cash; they only authorize an amount to be sent.
More recently, we realized that cashiers get confused about the amount field they have to fill in when accepting WingCash. Sometimes the customer wants to use WingCash for only part of the payment, so the cashier has to ask for that amount. It would be much friendlier for the cashier to simply enter the total purchase amount and let WingCash say how much the customer still owes after the WingCash payment. We intend to change the WingCash Sale app and the API to work this way. (We expect to change the API in a backward compatible way.)
So that’s how payment codes came about. We’re quite happy with that little innovation and how it makes push-based payments possible in an environment deeply accustomed to pull-based payments. Payment codes even provided unexpected answers to other questions. For example, let’s say you’re a parent and your son needs some cash immediately to pay for some specific thing. How can you send it? Well, you can create a payment code and just give him the payment code over the phone. In fact, now customers don’t even need any electronic device at the time of payment; they can set up the payment ahead of time and write down the code on paper.
Now that WingCash is open source (released last week), I hope everyone can benefit from this innovation as well as the many others we’ve discovered.