Today, someone — probably in India or Africa — is purchasing their first mobile. It will likely be a prepaid account, and possibly will be a device that has multiple SIMs, because it’s often much cheaper to make a call on your own carrier than across to another carrier.
That phone will likely look a lot like the Nokia 3310 — what we used to call a mobile, but which we now refer to as a ‘dumbphone’.
It’s getting hard to remember, but a decade ago — before iPhone — all our mobiles were dumbphones. We’d use them to call or text and perhaps play the occasional game of snake. But that’s it. That’s all we could do.
Yet even that completely changed our lives. And that’s just as true in Africa as in Australia. Actually, it’s more true in Africa.
In Kenya, back in 2007, the dominant carrier — Safaricom — launched a service for the millions of mobile-owning of Kenyans.
M-PESA allows you to send money via a text message.
How does that work?
Before I explain that, you have to understand something about East Africa, and about the developing world generally — there aren’t a lot of banks, there aren’t a lot of bank branches, and most people are ‘unbanked’ — they don’t have a bank account.
Why is this? In the developing world, banks really only want to deal with rich companies and rich individuals. Even the average SME in Kenya doesn’t have enough money to make it worthwhile for a bank to do business with them.
All that meant that Kenya had a huge cash economy in 2007 — simply because there was no alternative.
M-PESA became that alternative.
Safaricom already had a network of agents throughout Kenya, who would sell you a phone or a SIM or calling minutes. These agents were authorised to receive cash as well, that could then be deposited with an individual’s M-PESA ‘account’ — a savings account connected to their SIM.
Once that cash had been deposited with an agent, it can be transferred via a text message, to anyone else with M-PESA. Once transferred, the recipient could visit an agent and receive the cash.
That might not sound like much, but in Kenya — where people migrate from villages to Nairobi for work — it means the world.
Instead of spending a full day every fortnight traveling back to that village to hand cash over to a family member, the cash could be transferred instantly — and much more safely.
M-PESA became an immediate, roaring success. Peer-to-peer bank transfers — something we rarely use here in Australia transformed the Kenyan economy, because it became so much easier for people to move their money. That added velocity to money, and — over the last decade — has given Kenya one of the fastest growth rates in the world.
Although ideal for person-to-person money transfers, M-PESA hadn’t been designed for commercial transactions.
You couldn’t walk into a corner store and pay for a packet of laundry detergent using M-PESA. You’d need to visit an agent, get some cash, then go to the corner store, cash in hand. And if if you were that shop owner, you had to pay your wholesalers in cash — which means you had to have a lot of cash on hand — making every SME an attractive target for robbers.
One startup thought they had a solution for that shortcoming.
Kopo Kopo created a merchant services interface to M-PESA, allowing SMEs from the corner store to electrician and every other kind to have business M-PESA accounts.
When Kopo Kopo launched, Kenya began a slow transition to a cashless society — and they did this without banks, without credit cards, without tap-and-go payments. All anyone needs is a dumbphone, because Kopo Kopo realised they could build a monster of a business atop the APIs offered by M-PESA.
That was just the prelude. As Kopo Kopo signed up merchants, and those merchants began to receive payments via M-PESA, they created something they’d never had before — a verifiable digital ledger of transactions. Those transactions might not cover all of the cash flow of the business — Kenyans continue to use banknotes — but it captured enough of a snapshot that the ledger itself became a useful source of data.
Kopo Kopo realised they’d unlocked a fantastically rich source of analytics for these businesses. Immediately Kopo Kopo offered that data to the businesses, so they could understand their cash flow, their cash needs, and their cash trajectory.
Keep in mind that all of these SMEs were (and mostly still are) unbanked. That makes an awareness of their cash trajectory even more important, because they couldn’t run to the bank for a bit of help through a rough patch.
When Kopo Kopo realised this, they took the next logical step — prequalifing SMEs for lines of credit.
Let’s unroll this: these SMEs are unbanked because it’s too expensive for a bank to do the lengthy credit checks required to ensure the business is an appropriate capital risk. The costs of doing that are far higher than any profit realised from making a loan to the business.
But Kopo Kopo had all the data it needed in hand to be able to assess the creditworthiness of the business.
It could use its analytics — based on that business’ stream of transactions — to understand whether the business qualified for a line of credit. That took all of the costs away from the bank, and with Kopo Kopo as market-maker, connecting SME to bank, credit began to flow into Kenyan SMEs that had never had access to working capital.
In 2017, Kenyans have a banking system that is in some significant ways more sophisticated than anything we have here in Australia. And they did it all themselves.
Everything that’s happened in Kenya is happening in Australia.
It’s not exactly the same, of course — by and large Australians and Australian businesses have bank accounts, access to capital, and a variety of payment systems — from cheques to EFTPOS to BPAY to tap-and-pay. So some of the drivers in Kenya simply aren’t present here.
But we have other drivers.
At the ten-year anniversary of the introduction of the iPhone, well north of eighty percent of adult Australians carry a smartphone. What started as simply a clever device for combined music, messages and voice calls into a single device has become the universal tool.
And I do mean universal: By 2020 eighty percent of all adults everywhere in the world will use a smartphone. Kenya will catch up to Australia.
In Australia, the world of commerce remains curiously disconnected from the smartphone. You probably have a banking app, but how many of your transactions actually pass through your smartphone?
Even now — in 2017 — it’s not uncommon to encounter a web page that hasn’t been redesigned to work well on a smartphone. It’s as though these devices have become so common they get ignored.
But the truth is a bit more brutal — we haven’t yet climbed that first hill. Many of Australia’s businesses haven’t even made it to the lowest rung of the ladder — simple APIs that make the Web accessible on mobiles.
Some companies have gone right around the Web, creating their own apps to capture commerce. But that introduces its own problems, because there are big roadblocks to commerce on the smartphone.
If an Australian company writes an app that allows a purchase to be made — and paid for, via the app — it’s more likely than not that Apple or Google will appear, asking for a big slice of that sale.
Companies can get around this by holding your credit card details — keeping the transaction away from the smartphone. But that’s an obstacle in itself, because you have to get the customer to enter those details within the app — and the customer has to trust the seller before they’re willing to do that.
All of this is fine if you’re buying an album from iTunes, but what if you’re buying a sofa from IKEA? Payments platforms like PayPal try to bridge this gap — keep your details in PayPal, then use your PayPal account to make a payment to any retailer. That works if you have a PayPal account — and the merchant accepts PayPal. But if the edges don’t meet — and that’s often the case — customer and merchant are frustrated.
When you consider that by the early 2020s the majority of all online transactions will happen through a smartphone, these payments failures constitute a looming catastrophe for Australian commerce.
Fortunately there’s a solution.
Eighteen months ago the World Wide Web Consortium (W3C) launched a Web Payments Working Group, chartered to bring a rich set of APIs to the browser — and in particular, the mobile browser — so the user enters their payment details once, in the browser, then can present those payment details to any compatible mobile website.
W3C’s Web Payments project can transform Web commerce, making it flexible and seamless.
With Web Payments, a website has more capability than an app, and creates a payment mechanism that doesn’t route the payment through Apple or Google. Intriguingly, the payment mechanism is now being extended so it can be any payments mechanism both buyer and seller agree to — it could be a credit card, or PayPal or AliPay or bitcoins, or… whatever you can dream up.
That doesn’t mean you’ll be able to take your Ethereum and use them to pay for groceries at Coles. But it does mean that you can easily make payments in whatever currency you choose to use, with any payments processor you choose to use, so long as the seller agrees.
Right away you can see that the Web Payments API is going to create an explosive growth in ‘exchanges’ that will take a currency or payment mechanism and convert it into something compatible with a particular seller.
Just as Kopo Kopo recognized merchant services as the missing element in M-PESA, smart companies will be seizing the moment with Web Payments, building these marketplaces, and enabling very broad commercial connections between buyers and sellers of all different stripes.
And of course you folks, as experts in APIs, will be going to all of your clients and offering to integrate Web Payments into their mobile websites and their mobile apps — or will, as soon as it’s in the mobile browser. Right now only Chrome Android v53 supports this API, and while it will clearly spread to other mobile browsers — they’ve all supported this standardisation effort — it may be 18 to 24 months before it becomes relatively ubiquitous.
That gives us a great moment to think about how to rethink payments from the customer’s point of view. Payments have been constrained by payment mechanism — credit cards work one way, PayPal works another, BPAY is weirder still. Each of them had their own user experience. All of that can be hidden away now, making it all seamless. That opens new possibilities for all sorts of payments systems.
Consider micropayments. From the birth of the Web, micropayments have been held out as a holy grail, the salvation of media. Instead of the New York Times or the Guardian fighting with you for a yearly subscription, they’d charge you a few cents for each article.
That’s never been possible because the transaction processing fees for payments have always been far greater than any amount any reader would be willing to pay to read a single article.
There have been a lot of attempts to solve the micropayments problem — and all of them have required some complication to the user experience. No one wants that, so micropayments have never taken off.
With the Web Payments API, a micropayments system can be just another payments interface. Hit a news site, it requests a payment using a micropayments service via the API, and you’re on your way. I don’t know if that can be entirely frictionless — you clearly want a user to authorize a transaction, even if it’s only a few cents — but it can be nearly frictionless.
Of course, someone will have to setup a micropayments processor — and that’s something that perhaps the publishers could do as a non-profit financial institution whose sole purpose is to hold the funds used to make micropayments. There’s precedent for this: Safaricom is required by Kenya’s central bank to hold all M-PESA funds in a special bank account that can’t be used for any other purpose.
This is the most interesting thing about payments APIs. As soon as you set up a new payments mechanism, an ecosystem of related applications constellate around it.
A Web Payments API means micropayment. It means micropayments processors. It means micropayments accepting websites. It means micropayments analytics tools. And on and on and on.
The Web Payments API is not a culmination of commerce on the Web. On the contrary it’s just the beginning. Once you have a mobile API, you can start to build services around it, and services on top of it. That’s the lesson of M-PESA, and we’ll see it happen all over again — at global scale — with Web Payments.
Things are about to get a whole lot more interesting.
As an advanced economy Australia already has all sorts of whizzy payment systems — we’re even getting Apple Pay, someday — but remarkably all of these systems sit atop a foundation that is over thirty years old. Back in the mid-1980s the Reserve Bank led an effort to move the nation’s payment infrastructure to an electronic network.
That payment system keeps bankers hours — only clearing payments during the working week — and isn’t anything like instantaneous. Unless you’re moving funds within a bank, it takes hours or days to make a payment using any of Australia’s payment systems. Sure, your bank will cover you when you use your tap-and-pay card — that’s what you’re paying for, in part — but those payments won’t be processed, credited and debited until the payments as a whole are processed in a ‘batch’, generally overnight.
We rarely hear the term ‘batch processing’ anymore, but until the late 1980s that was the way most computer systems were designed. They ran one program at a time, ran through all the data, then moved on to the next program. So of course our payments processing system worked in batches.
Then along came the modern PC, which can do many dozens of things simultaneously. And the Internet, which sent messages to-and-fro 24 hours a day.
And, of course, the smartphone, which is the mash-up of the PC and the internet — constantly connected and constantly doing many different things.
This goes some way to explain why our 35 year old national payments system isn’t just looking a little long in the tooth, it’s actually hindering innovation. Australians have tens of millions of smartphones that integrate poorly with the payments system.
We’re not alone in this. Even the most advanced national payments systems — such as Singapore — remain separate from all those smartphones. Although the smartphone has become the most important piece of technology most people own, that hasn’t been reflected in payments.
Yet.
In October, the New Payments Platform (NPP), a multi-year initiative of the Reserve Bank, will be released to the public. Unlike any previous Australia payments platform, the NPP has been designed from the ground up as an open platform. It’s a set of APIs that any company can use to build their own payments services.
Australia’s New Payments Platform is an open API for payments. Open to everyone.
Right now only a very few firms — the big banks, and a few other payments processors — have access to Australia’s payments infrastructure. And, has already been mentioned, it’s slow. The NPP promises settlement within minutes — and mostly within a few seconds. So it’s not only open, it’s fast.
What can we do with that?
The first thing you’ll see is a whole crop of peer-to-peer payment applications. That’s right, the first thing we’ll do with NPP is replicate the functionality of Kenya’s M-PESA.
Why exactly Australians need a peer-to-peer payments system isn’t exactly clear, but we’ll have several to choose from.
However, there’s another type of peer-to-peer payments that looks very interesting indeed: payments passing between smartphone apps.
Right now, your smartphone apps don’t really talk to one another. And they certainly don’t trade with one another.
Let’s say a restaurant booking app wanted to get you a taxi to take you door to door — right now that would all happen behind the scenes, because that booking app can’t order and pay for that taxi. There’s no API allowing these apps to perform transactions.
In every case these apps either have to go through Apple or Google — with their 30% cut — or they have to rely on credit card information that the user may not want to enter. And these apps only do that for themselves. One app can’t pay another.
But if a peer-to-peer payment can move cash between two individuals, why couldn’t it also be used to move cash between two apps owned by the same individual?
All those apps need is an API to a payments service that allows these apps to send payments to one another instantly. With that API apps will be free to perform their own commercial operations.
Why would we want to add that capacity to an app? I’ve already given one example, where you get a restaurant and taxi booking together.
But once you have the capacity to perform these intra-smartphone transactions, you’ll see a new class of apps that provide little pieces of a value chain — a value chain connected via peer-to-peer payments.
This is not how we think of smartphones today. Apps are little islands, each of them having very little to do with any other. But payments are the golden carrot, the lure that provides all the reason any developer or merchant needs to open that capacity up to other apps. Today there’s no reason, but in October there will be an overwhelming reason: dollars.
You have seven months until the NPP is released, and all of the documentation you need to use to write services that make these APIs available to apps has already been released. It’s my hope that at least one person in the room today gets the opportunity that’s opening up here, to create a new economy around smartphones.
And it’s not just opening up here.
The NPP is being built by SWIFT. You’ve heard of them before — because when you send money overseas, you use a SWIFT code to transfer the funds. They’re the international payments network for the banks. They’re building the NPP here in Australia, and once they’ve got it all worked out and debugged, they’ll be offering it to every other country that wants a 21st century payments platform.
Creating a peer-to-peer payments platform for smartphone apps using the NPP isn’t just a neat solution for Australians — it’s a bridgehead to a global solution for intra-smartphone payments.
By 2020, more than five billion adults will be using smartphones. As these folks get their own versions of the NPP, a smartphone payments platform will travel with them. It will become the foundation for commerce in the middle of the 21st century.
That’s absolutely going to happen. The question before you is simple — do you want to be the person to make that happen? You have the insight, you have the tools, and you have the APIs.
What else do you need?