ProjectSpark! #2: HappyPayments
I announced last week that I’m starting what I’m calling ProjectSpark! As a quick summary, ProjectSpark! is my attempt to publicly describe business ideas I’ve come up with that I think have merit. My intent is to collect feedback on the idea and, if I’m lucky, to try to build a team of partners with complementary skills to work together to bring the idea to market and to share in its guidance, ownership, and profits. Without further ado, here is my second ProjectSpark! idea:
I’ve mentioned in the past that I was working with some people to start a new non-profit called Supporting.us. Unfortunately it looks Supporting.us is dead in the water.
The basic concept of Supporting.us was that non profits or charitable causes could create “Supporting.us Codes” which would look something like this:
Potential donors would recognize these codes and could scan the QR code in the image with a QR reader on their smart phone. This would take them to a mobile-optimized web page where they would be able to make a donation with a single click.
Unfortunately, this won’t fly. This falls under the realm of Third Party Payment Processing (TPPP) and I have been unable to find a way to work around this. The problem is that credit card processors do a credit check on merchants (IE: Supporting.us) before they let them process credit cards.
With Supporting.us, we were essentially wanting to extend that processing capability to our customers, the charities. But, since the processor wouldn’t be the ones deciding if our recipients were worthy of credit, they wouldn’t approve us. Basically, it’s too risky for them. What if we let someone use our system and they are fraudulent? The processor will end up holding the bag on the chargebacks, not Supporting.us. We’ve tried a few different processors and keep running into the same problem. There’s still a chance we might be able to work around this, but I’m not sure how.
However, this experience got me thinking about mobile payments, which is, well, a huge area of investment at the moment. You have the up-and-coming NFC technology where you can just wave your phone by a reader, rather than whipping out your credit/debit card and sliding it through the reader. (I’m excited about NFC!) There are also card readers that can attach to phones for mobile payment processing. While both of these are awesome, they don’t really change how people actually make purchases and interact with stores.
So, I had an idea: What if you could change the way people buy things in stores altogether?
Think about this: What if you could walk into Best Buy (or any other retailer), find the merchandise you want to purchase, scan the barcode on the product using an app, and click one button to make your purchase? At this point you’d own the item and could walk out the front door, skipping waiting in line. Your phone would show a receipt for your purchase with a QR code that contained encrypted information about your purchase.
On the way out of the store, Best Buy’s security guys would scan your receipt’s QR code with their own mobile device to validate it. This would lookup your purchase and confirm that the receipt is valid and that the user hasn’t already left the store before with this product. Heck, this could be put into a stand-alone kiosk to remove the human element from the equation.
As a note, buyers would enter their credit card information into this app the first time they used it. This would be securely stored either on the phone itself or, perhaps, in a PCI compliant data store in the cloud.
There are a couple of things that make this distinct from the failing Supporting.us concept. First off, this business (let’s call it HappyPayments Inc, for the sake of a recognizable name in this article) would itself be a credit card processor. They would fulfill the same role as First Data, or any other processor. Basically, companies that want to use the HappyPayments to process mobile credit card payments would use their existing merchant account, but would use HappyPayments as the processor. This would not prevent them from continuing to use the same payment processor they currently use for in store and online purchases.
HappyPayments would have an API that the merchant could use to either populate HappyPayment’s database with store locations, products, prices, inventory, etc. Also, HappyPayments would also be able to call web services specified by the client to dynamically get this information. Of course, it could also be manually managed if merchants so wished.
So, when I’m in Best Buy making my purchase, I select where I am from a list of stores near me that use HappyPayments. This would be similar to how FourSquare works when you check in. Using this, when I scan the product’s barcode, HappyPayments is able to lookup the price of the product at that store at that time. When purchases are made, HappyPayments can relay that information back down to the store’s POS via a standard web service API (if the client wishes to implement this feature).
The fees for using this would be similar to any other payment processor gateway: A small percentage and a small transaction fee. The mobile app would be free on the various app stores. Any deeper or custom integration with store systems would likely have associated fees. But, the idea here is to make money off of the transaction fees and not from the consulting fees. This helps lower the barriers to entry and makes it easier for merchants to start using this service.
Now, this is not a simple nut to crack. How does one get started? Well, it seems that if you want to break into being a payment processor, there are some fairly high costs and legal requirements. To get around this, new companies will often partner with existing processors. So, that’s the approach to the first problem: partner with a payment processor to avoid having to actually be a payment processor at first. As a part of the partnership, the processor would get a significant percentage interest in HappyPayments.
Secondarily, how do you get any sort of scale to get started? And how do you finance development and the initial work that needs to be done? Well, again, you partner. In this case, I’d love to partner with a business like Best Buy. They would make an initial investment to build this app (and business). They would get exclusive use of it for a period of time while kinks are worked out. In exchange for this investment Best Buy would also get a significant percentage of the company.
Once the system is stable, BestBuy starts promoting this in all of it’s stores to get people to install the app and make purchases using it. Then, we open up the gates to other retailers and businesses that want to offer a similar buying experience. (Apple, perhaps?)
While that more or less wraps up the idea, I wanted to add that I recently learned that Stephen Gillett, who pioneered StarBuck’s recent forays into mobile payments, has moved to Best Buy where he be doing the same thing. If I had a way to get in touch with Mr. Stephen Gillett, I think he might just be interested in this concept. Who knows? Anything’s possible, and it never hurts to ask.
So, what do you think?
DougHughes.net 