Over the past several years, my colleagues and I at Glenbrook have been working on a variety of projects focused on bringing low-cost financial services to the poor in developing countries. While there has been a lot written on how mobile or eMoney payments systems such as M-PESA in Kenya have grown in many developing countries—and how they have brought much-needed electronic payments to the poor and underserved—there’s a critical missing piece that demands attention.

Specifically, few are talking about the criticality of merchant acceptance of eMoney payments.  At Glenbrook, we believe this is a problem, that the lack of widespread acceptance has both inhibited growth in these systems and remains a roadblock to “digital liquidity” in even the more successful of implementations.

Without exception in the developing world, the vast majority of transactions in mobile payment systems are person-to-person (P2P).  That’s fine since poor people, those at the bottom of the pyramid, derive meaningful benefits from the shift of cash to mobile transactions. Those benefits include reducing the theft risk of carrying cash—which can be very dangerous—and the efficiency of being able to send money to someone without losing half a day of work to travel across town. For someone able to afford it, the mobile eMoney service can also provide a safe place to store value but few poor people have the luxury of idle balances in their mobile money accounts.

However, since most merchants don’t accept eMoney as payment, their customers must “cash out” their mobile monies in order to spend, a relatively expensive conversion.  Those cash-out costs work against the goal of providing low-cost payment services to the poor.

We are fortunate to be part of an ongoing working group on digital financial services at the ITU, the United Nations agency for information and communication technologies^[1].  One of our working group’s findings is that “digital liquidity” and the associated network effect are critical to the overall goals and growth of any electronic payment system. Keeping electronic money “in the system” creates transaction volume and velocity that keeps costs low, true not just within the processing system itself but also when calculating the “all in” costs of cash-out conversions. In short, digital liquidity reduces the expense of cash-out services.

A shift to fully electronic commerce to achieve those savings won’t be easy. Based on our experience in these developing economies, and affirmed by numerous studies, we have concluded that there just isn’t a silver bullet or a “waive the magic wand” solution to eMoney merchant acceptance.

In developed markets, merchants are happy to “pay to be paid” for a variety of reasons. While each merchant has its priorities—and many complain about the cost of accepting electronic transactions—merchants also realize that electronic payment acceptance produces incremental sales. And that they risk losing sales if they don’t. Incremental sales are driven by the expanded purchasing power made available by credit-based products and services, sales that would not have been made had customer spending been limited to the cash in their pockets. Other merchants understand they could lose sales to competitors if they don’t accept the customer’s preferred payment method (think rewards cards).  And of course, merchants selling to online buyers rely almost entirely on electronic payments.

To merchants in the developing world these benefits aren’t compelling, neither for small sellers (who may be poor themselves) or larger ones, for a range of reasons:

• Their consumers are largely unbanked and don’t have access to credit products
• Cash is the traditional payment method. Everyone is used to it. Cash is “good enough”
• There aren’t enough merchants accepting eMoney to warrant concern of lost sales to competitors who do accept it
• eMoney transactions are often viewed as costly to accept
• Merchants usually incur costs of cashing out themselves since there isn’t a robust B2B ecosystem in place, i.e., for supplier payments. The alternative costs of transferring funds from mobile operators’ eMoney systems to a traditional bank account—if the option is even available—are high
• Remote commerce, our online or mobile commerce model, doesn’t exist or isn’t on anyone’s radar screens
• It costs a lot of money to develop a merchant ecosystem with uncertain economics
• Merchants may be concerned that revenues would now be visible to tax authorities
• Many merchants would have to buy equipment dedicated to eMoney acceptance, such as a dedicated phone for the store or at each checkout till

It’s a tough problem, so where do we go from here?  Is there hope?

I believe that it’s critical that eMoney systems develop a robust merchant business. I also believe it’s achievable if done right. But it’s important to understand that, while merchants will pay to garner new customers or generate more visits and revenue from existing customers, there isn’t a single factor that in itself will be sufficiently compelling to drive merchant adoption.  In my opinion, success will be driven by a combination of factors:

• Credit History Development. By accepting eMoney payments, merchants can create a “digital history” that enable prospective lenders to extend all-important working capital and other forms of credit to merchants. Recognizing that traditional credit bureaus simply don’t exist in most of the developing world, coupled with the fact that many small merchants don’t have access to credit, we are starting to see an explosion in alternative credit decisioning, of which eMoney transaction history is an important factor. In addition, some lenders could be more likely to extend credit given access to an electronic settlement stream they could tap into for regular or ad hoc loan repayments
• Contextual Ecommerce. The notion of remote payments is hitting more and more radar screens and it doesn’t need to look like traditional developed-world web and app-based ecommerce. Remote transactions for bottom of the pyramid customers could be a merchant taking payment for goods now that will be picked up or delivered later
• Merchant-provided Credit. Merchants could increase sales by extending small amounts of credit to their own customers, knowing that repayment isn’t necessarily tied to when the customer happens to next visit the store
• Embedded Payments. As in the developed world, payments will eventually become an embedded part of commercial or community relationships, providing benefits to payment acceptors
• Cash Reduction. Reduction of cash on hand to reduce theft and loss risk
• Light Regulation. Government entities are viewing a robust eMoney systems as a priority, often under the financial inclusion umbrella. Relaxed or grandfathered tax policies could go a long way in the critical, early years of building a robust merchant ecosystem
• Social Messaging and Payments. Social networks with commerce-enabling capabilities using eMoney are turning toward the developing world and could quite conceivably enable merchants of all sizes
• Broad Payment Method Acceptance. There is increasing focus on the notion of interoperability at the payment acceptor level, the ability to accept multiple forms of electronic payment. Open payment platforms based on standards, APIs, etc. are key components to not only help achieve digital liquidity, but also to help ensure payments providers compete on both price and innovation
• System Interoperability. Some eMoney players are increasingly open to cooperating – pursuing the notion of working together to bring up a merchant business by sharing the cost of some non-strategic functions, creating merchant joint ventures, etc. The network effect could build ubiquity, benefiting all participants in the ecosystem

My colleagues at Glenbrook and I will continue to participate in many developing world projects, helping to bring affordable financial services to bottom of the pyramid people and businesses. We do this with incredible optimism and enthusiasm. It doesn’t get much better than this for “payments geeks” like us!

[1] See http://www.itu.int/en/ITU-T/focusgroups/dfs/Pages/default.aspx