Micro Merchants: P2P Squared?

by Carol Coye Benson on November 4, 2011

in Carol Coye Benson, Intuit, Merchants, Mobile Banking & Payments, Mobile Technology, P2P, Square

Post image for Micro Merchants: P2P Squared?

I’ve been thinking a lot about the opportunities around helping micro merchants accept electronic payments. You know, your basic nanny/gardner/hot dog vendor/flea market vendor scenario.

There are two competing emerging-payments approaches to this market. One is mobile card acceptance, as evidenced by Square, Intuit GoPayment, and many others. In this model, which “rides the card rails”, the merchant pays a discount fee, some portion of which stays with the acquirer, and some portion of which finds its way back to the card issuer through the mechanism of interchange.

The other approach is an electronic P2P payment, as evidenced by products such as Fiserv’s ZashPay and the clearXchange consortium (being formed by Wells Fargo, JPMorgan Chase, and Bank of America). In these examples, the two banks involved set their own prices to end customers – but there is no interchange mechanism to create, effectively, a minimum price to the receiving merchant. The odds are that many banks will not charge the receiving micro merchant for posting the transaction into their account – rather, it will be incorporated into the receiving merchant’s checking account “bundle”. (This is the way I expect consumers receiving this type of P2P payment to be treated.)

There is a third, hybrid model– represented by PayPal, American Express Serve, and a number of others. PayPal provides P2P payments both directly to end users and as a service to enable banks (and others, such as Discover) to do the same. PayPal, as always, has a unique angle to this. In their own core business, they are very good at identifying when a P2P transaction is to split a dinner tab or pay for a purchase – and then ensuring that fees are paid on the purchase transaction. Presumably (but I’m not sure on this) a similar tracking would be used when the PayPal capabilities are sold to bank partners to support P2P payments. I would assume that Serve will take their product in a similar direction. Of course, from the micro merchant’s perspective, this then becomes just another flavor of the card acceptance model.

I think the big question is whether or not the P2P model will eventually trump the card payment model. After all, the hot dog vendor would clearly prefer to pay nothing rather than a merchant discount fee. Or will the two models develop in tandem? Will some kind of service evolve (perhaps offered by Fiserv or clearXchange) to help banks using this model identify receivers as vendors – and enable banks to charge them? If not, it seems like money is being “left on the table”, as the expression goes.

What do you think? I’d welcome your comments.

4 Responses to “Micro Merchants: P2P Squared?”

  1. Byron says:

    Great summary, Carol. A few thoughts:

    In my opinion, long-term banks will be very tough to beat in P2P due to their ability to bundle and not charge fees. Of course, banks have to make the P2P experience seamless to the end-customer and not misfire on how the service is packaged. I also believe that different P2P models will prevail in different parts of the world.

    In general, the P2P revenue model is tough in the U.S., but I do think that there is a good freemium P2P model out there. It is probably tied around the ability to discriminate the transaction and/or bundle services on top of the transaction.

    One example: As a consumer, I do not want to pay for P2P transactions, however in a Craigslist-like P2P use case, I might be willing to pay. The criteria is around convenience and risk: I do not know you/you do not know me, I need to pay you for something, no credit, cash is a pain to get and awkward (“Can you break a $20?”) and there is no way the collector is taking a check from someone they do not know. It has some similarities to servicing the unbanked.

    BTW, your book should be mandatory reading for any company doing anything in payments. I plug it all the time.

  2. unc says:

    Surely OpenTransactions is the solution which you describe. Whilst the initial fixed costs might be large(ish), the transaction costs would be so close to zero as to be negligible. Peer2peer payments via OT are a solution to a real problem, but I don’t think it will ever get implemented. Sometimes it’s a case of being too much of a radical departure to be viable.

  3. Dave Birch says:

    There are other people who can bundle P2P (eg, Google with advertising) and the “three party” models like Serve appear to have a lower cost floor. Maybe low-value retail and interpersonal payments just aren’t a banking business after all?

  4. Square / Intuit, etc.: Good UX for both payor and payee, but payee suffers interchange cost. ZashPay: Their current operating model is too cumbersome for me to even imagine how I’d use this method to make payments like these. My prediction: Cash will be king until payors insist upon payees to accept non-cash alternatives, at which point we might see a shift to Square / Intuit.

Leave a Reply

Previous post:

Next post:

Clicky Web Analytics