Today Dwolla announced a new financing led by A16Z with Scott Weiss joining the board. The funding will go towards establishing a new office in San Francisco, an expanded presence in New York and much needed additions to the team in Des Moines starting with a lot of engineering hires. I am of course excited about this as an investor but even more so as a user of Dwolla. It already works well for me in in paying contractors but I can’t wait for it to be more broadly available. It is 2013 after all and we have self driving cars — yet I still find myself having to scribble amounts on little pieces of paper, sign those and then put them in the mail. So: congrats to team Dwolla on the funding and now please hurry up so that I don’t need to re-order my check book!
Sorry, no Tech Tuesday today (due to my travel schedule). Quite fortunately that creates an opening for a brief post about Dwolla, Iowa and the Midwest more generally. I spent my first year in the US as an exchange student in Rochester, Minnesota and came away with a real fondness for the Midwest. I am still in touch with my host family who provided a wonderful experience including travel to the far North of Minnesota and North and South Dakota.
One of the things I came to appreciate in particular about the Midwest is a “no drama” pragmatic attitude to problem solving. That’s why I have tremendously enjoyed working with the team at Dwolla which has been cranking away on some big problems in payments. And today they receive some terrific recognition of that effort: the state of Iowa announced it will be accepting a variety of payments via Dwolla. As Fred points out this also happens to be a pragmatic way for government to support a local business.
Google’s announcement of the initial availability of Google Wallet was interesting but not because of any immediate impact. Initially, this will be the equivalent of a large field trial as it will be available only on Nexus S phones and only on Sprint. Much of the coverage has focused on using Wallet to pay merchants in the real world (e.g. in a Cab or at Macy’s), but Google Wallet has far reaching implications for apps and in-app transactions.
If Google Wallet offers APIs that can be accessed by native apps on the phone, then payment processing could be shifted away from the app market to the phone itself. Ideally that would happen with minimal transaction processing costs at or even below those used in card present transactions. It could also have absolutely minimal enduser overhead. For instance, a Zynga game app could simply pop open a dialog on the phone to let the user purchase a virtual good with a single click!
If Google enabled such public on-device APIs, it would start to pull the rug out underneath Apple’s 30% tax on in-app purchases. It would also result in a Cambrian explosion of phone based payments because unlike paying a real world merchant with apps there is no need for local NFC device. Google has in the past stated that they are committed to an open ecosystem with Wallet. Let’s hope that includes on-device APIs for third party apps!
Apple app store subscription policy is a clear case of overreaching. I have written before about how I don’t think the 30% take rate for Apple is justified or sustainable. Extending that pricing to an ongoing relationship is particularly problematic. The argument — made by no less than Jobs himself — that Apple should be entitled to a 30% cut for a “new subscriber” seems to suggest that these subscribers simply would not exist without Apple. While true that Apple has built a hugely innovative mobile delivery platform it is no longer the only such platform and people frequently learn about apps they want to download outside of the platform. I am not suggesting that Apple shouldn’t take a cut. I am simply arguing that it should be considerably less.
This turns out to be a huge moment of opportunity for Google, if they were able to deliver on a payment solution that is easy to use and attractively priced. Payments would be important not just in competing with Apple but also with Facebook. Facebook is taking a similarly large cut of payments made with credits and is also aggressively pushing platform developers to only use Facebook credits. Google faces a huge uphill battle here because they don’t have a lot of consumer credit cards on file, whereas Apple has 100 million or more. They’ll need to come up with a fairly aggressive play here. Instead of spending $6 billion on Groupon, Google could — for instance — give people $50 credit when they link a credit card, get to 100 million credit cards and still have $1 billion left over!
UPDATE: That was quick. Google has announced One Pass — now let’s see how aggressive they are about pushing it into the market.
Each has more than 100 Million credit cards on file to enable 1-click purchases of content, apps, and virtual goods. When I compare doing anything involving payment on other platforms the experience is cumbersome to the point of being useless. My 10-year old son had no trouble hijacking my Kindle, finding the store and getting a book for himself. And that’s on the Kindle! On his iPod touch he blew through the app budget we had set for the month within the first two days of having it. It will be interesting to see who figures out how to catch up with Apple and Amazon and how they do it. In the meantime, companies like Zong with their Zong Plus offering are trying to get there independently. If they get to 10s of millions of linked credit cards, they will make a juicy acquisition target.
Over at DailyLit (my wife’s company), some books are free and others require payment. Right now, DailyLit accepts credit card and PayPal. From that I have some good first hand experience with online payments. Based on that here are some of reasons why the existing solutions are painful and ready for disruption:
1. The fees are outrageous. Not only do the card companies take a cut but you also pay for a gateway fee. With PayPal you just pay them, but again it’s a hefty fee. Now it is well known that if you have volume you can negotiate down these fees, so a lot of it has to do with margin not with credit risk. A disruptor would drive down fees for everyone based on observed behavior of participants. There is so much data sloshing around (both on customers and merchants) to help assess actual risk in real time and the cost of moving a few bytes around should be near zero.
2. The APIs are horrendous. OK, implementing PayPal is a cinch, but you wind up sending people off your own site over to PayPal. That’s not the use experience anyone wants. For most credit card gateways the APIs have a lot of different calls with a ton of parameters and return values that require a lot of additional logic to figure out what just happened. There tend to literally be dozens of possible return codes that the application logic has to figure out how to handle.
3. Chargeback processing is manual. Yes manual. It is 2009 and when someone questions the charge on their card, you receive a letter asking for information on the purchase, such as whether you received positive address verification and whether the good was actually delivered. For online payments at least up to some amount, this should be entirely automated. A single additional API call would suffice.
4. For small amounts it should be easy and affordable to charge someone’s phone. It is easy today using Zong, but the carriers take up to a 30% cut. That may work for virtual goods which have 100% gross margin, but it doesn’t work if you are trying to sell anything else. Even for a digital good, such as a book on DailyLit, where you have to pay royalties to others it is hard if not impossible to make the Zong economics work.
If someone were to come along and offer a clean API, with reasonable fees that allowed people to pay via credit card and cell phone (and made it easy to keep a card on file for repeat customers) they could rapidly grab a large share of online payments.