- PROJECT HELP
- WHITE PAPERS
It's common these days to refer to any new payment story as a "mobile payment" story. While there is an element of mobile to the Starbucks/Square partnership, it's really not a mobile story, it's just a payments story.
The new "SquareBucks" announcement (wish I could take credit for that; it was a slip of the tongue by a colleague) has caused some analysts to predict a seismic shift in the payments market. They may be right. Call it "attack of the non-processors."
Let's be absolutely clear about one thing: Square is not a payments processor. In the payments industry value chain, Square occupies two clear non-payment segments.
First, Square is a merchant. They have a traditional merchant account with a traditional merchant processor. When a consumer makes a purchase at a Square merchant, Square itself stands in for the actual merchant and is the "merchant of record" for that transaction. Only later does Square settle with the merchant that actually delivered the goods, keeping a 2.75 percent bounty.
Second, and perhaps of greater importance, Square is a software company, or what is generically known in the payments world as a value-added reseller or "VAR." Square provides a set of client applications and services that offer merchants a variety of payment and point of sale management tools. This is a critical distinction. Payment companies know how to handle payments; software companies know how to deliver applications.
The idea behind Square is not to create another payment company, but to change the way merchants relate to payment companies. I believe that when Jack Dorsey says that the traditional payment system is broken, it is not the hardware, networks, software, and services that he is referring to. Those systems are not broken at all; they work very well, and Square depends on them for every transaction it handles.
The piece that needs fixing is the business model. Payment processing is usually sold in a very old fashioned way, often door-to-door, and is priced in what merchants view as a needlessly complex set of schemes that leave them confused and frustrated. The business arrangement is the same for most mobile acceptance solutions offered by traditional processors; the equipment is the only thing that is different.
Square hides all of that complexity in a black box, wraps it up in a highly functional set of applications, and sells the package with an easy-to-understand set of terms and conditions. Square users often pay a significant premium for this, depending on their volumes and payments mix, but many have decided that they are receiving sufficient value for the money.
And that's the key: Merchants will actually pay more if they feel they are getting more. Applications and functionality trump cost.
This actually happened: Recently, a major QSR chain issued an RFP to find a new merchant processor. Several of the leading acquirers responded as they typically do, with proposals that included low pricing, promises of excellent customer service, deals on equipment, etc. The winner, it turned out, was none of the usual suspects. In fact, the contract was awarded not to a processor at all, but to a VAR.
The winning company had proposed a set of applications and services that not only would process payments, but also would improve the way the client served its customers, managed inventory, and handled store finances. The actual payment processing was treated as a commodity service that was subcontracted out to a well-known provider, who was happy to take on the business.
This story is very similar to what I suspect happened at Starbucks. Square offered a range of applications and services that add value to the basic payment event. Starbucks can offer a new and unique customer experience, reduce their software licensing costs, capture customer email, create loyalty programs, and do it at a very predictable cost. First Data, the incumbent processor, likely could not offer anything but better pricing.
To be sure, there are some massive question marks around the Squarebucks deal. Can Square scale the platform to handle the volume? Will Starbucks abandon their hardware in favor of tablets or handhelds? But the biggest question is this: Can Square make any money on this deal? Adding 7,000 stores, billions in transactions and an influx of capital seems like a no-brainer — until you run the numbers.
On a typical $6 sale, under the current Durbin-driven pricing regime, a debit transaction would normally cost Starbucks about 26 cents in total. Under Square, that same transaction costs Starbucks only about 17 cents. That's great for Starbucks. But Square has to eat the difference, and they lose money on every transaction under about $9.50. I'm guessing that is a significant portion of sales at Starbucks.
Of course, the arbitrage benefit for credit works in Square's favor — they will make roughly five cents on a $6 transaction, more for larger tickets. And they will make money on debit transactions over $9.50. But if Starbuck's electronic payment mix is a typical split of 60 percent credit cards vs. 40 percent debit cards, Square stands to lose a lot of money.
One very interesting side note: Starbucks has said that it will use Square to process all card transactions, and will do so using existing equipment. This means that there is a version of the Square software that will run on something other than a handset or a tablet, a significant shift in strategy, putting Square in direct competition with a range of companies that offer specialized POS and retail management software. It could also allow Square to opt out of the payments piece of the equation, instead relying solely on the application in situations where the merchant likes the Square software but prefers a traditional merchant acquiring relationship.
Aaron Press is a payment industry veteran with more than a decade of experience as a market analyst. Currently with mobile and digital security provider Gemalto, Press was previously market analyst for merchant acquirer Chase Paymentech as well as Alliance Data.
© 2014 Networld Media Group All rights reserved.