Online card payments still suck

06 October 2022
Adrian Hope-Bailie

We are suckers for convenience. When something “just works” it’s hard to look past it at any other options, and so we get drawn into habits and behaviours that exercise our muscle memory instead of our brains.

This is the ultimate product marketing challenge, breaking entrenched user behaviour. The number of terrible habits we’ve developed as consumers is probably pretty extensive, but among the worst must be how we do online card payments.

I recall, at least 20 years ago, attending a conference where one of the most successful e-commerce sites in the country (a flower delivery service) explained how they got started with accepting card payments.

In short, they had a card entry form on their website where they captured all your card details and these were simply sent via email to their ordering service. Every morning, for the first few hours before the work day started, somebody worked through these emails and manually captured each card transaction into the physical point of sale that they had sitting on the desk in their office. Classic “swivel-chair integration”. Like all great fintech innovations it walked the line between genius and wildly irresponsible.

Two decades later, the user experience of paying by card is pretty much the same for end users. The security of your card details is only marginally improved. In fact, the only major change for end users is the terrible post-payment authentication shambles called 3D-secure, which in the name of security, makes the whole payment experience even worse.

Figure 1: A typical card payment flow.

What most end users don’t know is that instead of finding a better alternative to card numbers, for payments in the digital world, the card industry opted for a whack-a-mole approach to fraud and imposed expensive audits on anyone that handles card data to try and preserve the credibility of card payments as a payment method. None of that was free and in the end the consumers and merchants paid, or more accurately, the consumers paid, both directly and indirectly.

This is a problem space I know intimately. I co-chaired the W3C’s Web Payments Working Group from its formation in 2015 until I left to start Fynbos last year. All the right stakeholders are part of that working group, the platforms and browser vendors (Apple, Google, Microsoft, Samsung, Mozilla, Facebook/Meta etc), the Payment Service Providers (Stripe, Adyen, Shopify etc) and the networks (Visa, MasterCard, Amex, Discover, JCB etc).

Figure 2: A sample of the Web Payments WG participants.

But every stakeholder group has different incentives that drive their approach to “make payments easier and more secure on the Web” and in reality only a concerted, unified effort would ever have been successful given the massive challenge of changing user behaviour to move to a better way of paying. This is an ideal problem to be solved by open technical standards adopted by the whole industry but the participants need to have a genuine desire to solve it, together, and with a solution that puts end-users first.

The networks tried their own approach with Secure Remote Commerce (SRC, also known as Click to Pay) but ultimately it’s the platforms, with ultimate control over the user experience, that get to decide on the direction the industry must follow and they have made their intentions clear, the future is wallets.

Online payments with Apple Pay, Google Pay, or the like, are stupidly simple and they handle authentication elegantly in-the-flow of the payment. But that wasn’t always the case. Payments industry veterans will recall that for a long time Google Pay (or Wallet or Android Pay or whatever it’s called now) and Apple Pay were considered lumbering failures with below par user adoption. But if there is anything the big tech companies know how to do, it’s leverage their monopoly on distribution and their deep pockets to outlast the competition even while their product flounders and they iterate looking for product market fit.

PayPal, who could have become the de-facto digital wallet of the Web, and were first to market by many years, seem to have been asleep at the wheel. I’d love to know what was happening internally at PayPal as this opportunity slowly sailed by.

The recent announcement that a consortium of companies are co-ordinating an open source wallet project (ostensibly to compete with the platform wallets) makes this all feel a lot like the browser wars of the early dotcom era. The platforms (Apple, Google, Microsoft, Samsung and others) continue to leverage their distribution advantage in the face of early push-back from competition watchdogs (as usual Europe paving the way) while the rest of the industry fights for the scraps.

It seems ordained that the success, and ultimately dominance, of the end user login experience with “Login with Google” and now “Login with Apple” will soon be followed by a complete monopoly over “Pay with X” by the same big tech players. Participants in other parts of the value chain seem content to ride the coattails of the platforms for now. Maybe they’re hoping they can find another way to survive when, inevitably, their own value proposition (convenience, security, merchant networks, payment method diversity etc.) is replaced by the wallets themselves or maybe they’re just genuinely naive to the threat.

On the Web (as opposed to the native platform world), indie players like Mozilla, Brave, Puma Browser, The Browser Company, and others, valiantly try to provide decent alternatives to the dominant browsers but together they make up less than 10% of the market share. As a result, anything they do to support an open wallet ecosystem is doomed unless that wallet itself becomes the differentiator that starts to win them market share.

Brave have made a bet on crypto-wallets as a differentiator, which is interesting, but I expect will remain very niche for long enough to allow Apple and Google to offer payments via crypto just as soon as it makes commercial sense (if ever), leaving Brave to rely on privacy as their last remaining differentiator.

At W3C I tried to push a standard Web API that would have allowed anyone to build wallets, using Web technologies, but ironically this was only ever implemented in Chrome and leveraged by Google to build Google Pay into the browser. PayPal, probably the best candidate to leverage this ability to embed a wallet in the browser, never bothered to implement one, even as an experiment (asleep at the wheel?). In the end the Payment Handler API (as its called) got caught up in mindless bureaucratic debates, supposedly on behalf of the poor user, all the while that same user’s ability to choose the wallet they want to use on the Web continues to be slowly eroded away. It's now hard to imagine a future where the wallet you use comes from a different vendor to the browser or OS you use.

The W3C’s Web Payments Working Group hasn’t failed. You have to give up to fail, and W3C staff involved and the current chairs are too good for that. On the contrary they recently got their first two standards through the standards track, despite some naive opposition from new anti-Google W3C members that clearly don’t fully understand the big picture of what’s playing out.

But, there is a lot to do to get the Web ecosystem to realise the value of developing an open standard that would allow independent wallets to embed themselves in a user’s browser rather than relying on the platform wallets. I’m sure this is the battle that will follow the app store payment wars raging today as the focus moves from the native app ecosystems to the open app ecosystem that is the Web. (No, Web3, or Web5, or WebN is not the silver-bullet that makes this all irrelevant, but that’s another whole discussion).

Between the work being done at OWF, the still alive, but barely, Payment Handler API, and the work we’re doing on Open Payments, I’m confident something will gain momentum and hit a critical mass of adoption. If not, we need to depend on the competition watchdogs to untether the concept of a payment wallet from the platform as they did with browsers once before. But it’s clear from the recent bust ups around app store fees that Google and Apple won’t give up their monopoly without a fight and the gears of the legal machine move slowly. Google has shown a willingness to embrace open standards and technologies (they implemented Google Pay using the Payment Handler API), I wonder if this particular walled garden is one they’d like to keep closed or if we might see an independent wallet that can be invoked directly from the Web on Chrome?

Continue the conversation with us on Twitter.