The fundamental problem facing Apple Pay

With Apple’s recent announcement to offer Apple Pay checkout on Safari, much has been said about the game changing impact this will have on online payments. In almost all the publicity this move by Apple has garnered, very little attention has been paid to the potential challenges of merchant adoption. Indeed, most commentators have fallen for the typical ‘cult of Apple’ argument: “Of course all merchants will adopt this new wonderful Apple solution”.

I believe this is a naive argument. I also envisage that this will be one of Apple’s hardest sells, based on the adoption struggles faced by the other big digital wallets, Visa Checkout and MasterPass, which have not been embraced by the leading online retailers and service providers.

What the big players are doing — or not doing — is important. When speaking with smaller online retailers, I often hear a similar story: “We are always watching Amazon, etc., and following their lead wherever possible”.

In a previous version of this post, I highlighted Amazon, Uber, and Bonobos as examples of service providers without Apple Pay integration. I incorrectly added Uber to that list. After a more detailed analysis of the lay of the land, my research revealed that only 2 of the top 9 online vendors offer Apple Pay as a payment option. Read about it here.

Bonobos as an example

I have had the opportunity to meet with some of the Bonobos team and have a lot of respect for the company’s co-founder and CEO, Andy Dunn. Bonobos has always been passionate about putting customer experience and product quality first. Every business decision is rigorously analysed and scrutinised. I would argue that Bonobos is the bellwether of e-commerce 2.0 (if there is such a thing).

Of course, besides PayPal, Bonobos offers no other digital wallet / payment processors.

Why are digital wallets MIA?

Clearly, adoption of payment wallets amongst the leading online retailers and service providers has been poor at best. If they aren’t all jumping on the bandwagon, why should anyone else?

Let’s take a step back and put ourselves in the average e-commerce merchant’s shoes. Having been an iOS app developer dealing with the Apple App Store, this is not standard practice for Apple, especially when it first launches a new service.

The advice online retailers need vs. the advice online retailers are getting

To be successful, e-commerce merchants typically need to do the following well:

1. Stock desirable products (and present them well — everyone likes pretty pictures)
2. Deliver those products at a reasonable price
3. Let everyone know they exist

I always watch with interest the advice pitched at merchants that ignores these essential ingredients. Instead, merchants are encouraged to focus on conversion rates, cart abandonment rates, etc. The objective of this advice is typically to sell a new technology or service. It’s as if improving checkout by 1% will make or break a business. Being Captain Obvious for a second, whether someone wants to buy your products will make or break your business.

This is a case of the tail wagging the dog. That is, in e-commerce, a lot of people selling to e-commerce merchants equate ‘improving’ and ‘succeeding’ with their ability to adopt and adapt to this or that new technology. This is essentially a reactive, rather than proactive approach, as the new technology starts dictating the merchants’ behaviour — rather than the other way around.

When technology becomes a burden

Let’s dive a little deeper into the average e-commerce merchant’s situation. They are typically supporting a cumbersome stack of technology, including:

1. One or many servers (virtual or otherwise)
2. The OS of those servers (e.g. Linux)
3. HTTP management (typically Apache)
4. A development language operating package (e.g. Rails)
5. The database management system (e.g. PostgreSQL)
6. A deployment service (e.g. Jenkins)
7. A checkout functionality (e.g. Magento)
8. A front end (could be Magento, could be something different, but needs to deal with mobile and desktop views well)
9. Something to track your customers (e.g. Salesforce)
10. Something to track your inventory (which hopefully deals with returns well)
11. Shipping integration (you can pick Temando … or 2 or 3 others)
12. Something to process payment
13. A payment gateway (yep, it’s often different to the processor)
14. Accounting package (e.g. Xero)
15. A customer support function (likely a version of livechat)
16. Analytics tracking (say Google Analytics, but others are out there)
17. Channel promotions (something to engage with marketing channels seamlessly so you can run promotions without changing code)

In most cases, an e-commerce stores needs all of the above, if not more. This creates two significant issues that are very often overlooked:

1. Each of these technologies needs to be updated regularly. Let’s say an update comes through quarterly for each. That means, as a company, you need to assess and potentially update software 68 times throughout the year.

2. None of the above platforms work in isolation, and this can be problematic. An update to your payment gateway, for example, can affect all the other platforms you rely on to keep your online store up and running (yup, you might need a different server from a payment gateway change given the requirements when it comes to how the gateway communicates, etc., etc.). That means, the potential consequences of each of the 68 updates throughout the year needs to be assessed against the entire stack.

To make matters even worse, it is rare that two stacks of technology for any two e-commerce sites are identical. As a result, while testing might take place against reference stacks, it will be fairly unreliable, as the reference stack is almost guaranteed to be different to yours.

From a time perspective, even if it does only take half a day to update your technology, having to check 68 releases becomes a tremendous blackhole. Adding additional services to each platform on the aforementioned technology stack not only increases the number of releases that need to be reviewed, but also the time it takes to review them — as they need to be tested against more and more platforms.

“Just wait for the major releases”

This is what I tend to refer to as ‘the head in the sand’ argument. And it is often advocated by those I tend to call ‘hoarders of technical debt’.

What happens when a given service provider chooses to drop support for the antiquated release an e-commerce merchant is relying on? Before they even get to the position where they can begin a tortuous upgrade that likely requires major outages, they have to find the ‘path’ to upgrade. Their 2.0.1 version of x service isn’t compatible with the 3.1.2 version of service that is required for the 1.4.7 version of the service they need to upgrade to in order to avoid the imminent end of life of the earlier version.

If you think the above is a joke, I have personal experience of two core operating systems by the same company without a supported upgrade path at the end of life of one system version. If a single company can’t get this right, what hope is there for the other service providers of offering an even basic coherent upgrade path?

Checkout optimisation

Even if we assume that an e-commerce merchant wants to adopt and support another technology, the question remains: are they happy for someone to take over their checkout flow and lose the opportunity to upsell, etc.? In most cases, once you hand over to PayPal or another wallet (e.g. Apple Pay), you lose any opportunity to further engage with your customers.

So what does this all mean?

Most e-commerce merchants want to reduce the number of platforms and technologies they use to run their online stores. That’s why packages such as Docker that can run anywhere and reduce the complexity of deployment are so popular. That’s also why DemandWare has a huge and devoted following; sure it’s a closed ecosystem, but so many factors just work well together.

Ultimately, adding another service (that takes away additional revenue opportunities) requires a substantial investment on behalf of the merchant. It means additional costs for site support, while taking their attention away from their core business: selling things.

No wonder adoption is low.

What would make Apple Pay worthwhile?

The big promise of Apple Pay is a reduced cart abandonment rate. The argument is that making payment easier on mobile devices will result in significantly less cart abandonment. Since the introduction of Apple Pay, Visa Checkout and MasterPass, I haven’t seen any published data to back this up.

Nevertheless, let’s see if it’s worth it.

What we know:

• Safari mobile browser penetration: 18% (Source)
• Overall cart abandonment: 72% (Source)
• Mobile cart abandonment: 97% (Source)
• Average transaction: $122 (Source)
• Traffic split between desktop and mobile: 67%/33% (Source)

Now let’s look at a store with $5m in transactions annually, and a net revenue per transaction of 30%. This works out to be an average of 41,000 transactions a year, or 112 a day.

First, let’s understand how much traffic we can expect on mobile Safari, working backwards from transactions. Out of 112 total transactions, 37 will be mobile transactions, and 7 will be on Safari.

Taking into account a 97% abandonment rate, it will have taken 233 checkout journeys to achieve these 7 transactions.

Moving the needle

It is very difficult to make any real assumptions on the improvement of Apple Pay to mobile cart abandonment. It’s not as straightforward as assuming a faster checkout process will move the needle on cart abandonment. Indeed, the desktop cart abandonment rate provides a cap on the amount of improvement you can make (97%-72% = 25%). However, that doesn’t take into account valid use cases of shoppers doing a price check of an item (calculating shipping and therefore going through to checkout) while shopping offline and checking the price they are about to pay.

Nevermind that the online shopping experience often starts on a mobile and then the transaction takes place on desktop in a later session.

I’ve created a table to illustrate my point:

These numbers help us understand why the market is moving the way it is (i.e. not adopting Apple Pay en masse). Clearly, if Apple Pay was a magic bullet that immediately brought mobile cart abandonment up to desktop levels, we would see every retailer integrating the service, especially the largest vendors; if average sales are in the tens of millions, the additional net revenue would increase in line with this example. Simply, if Apple Pay resulted in a 1% mobile cart abandonment drop for a 1 billion dollar annual retailer (your Amazons), it’s highly unlikely they’d leave the $5million on the table.

However, most e-commerce merchants are looking at the numbers above and seeing that, in reality, Apple needs to move the needle a lot to make it viable. As shown in the analysis above on costs of incorporating and servicing a new integration, an improvement in cart abandonment rates of more than 3% would be necessary. This means doubling this sales channel.

E-commerce merchants aren’t dumb. In fact, like Andy Dunn and the team at Bonobos, they are data obsessed and looking at these numbers every day.

So what’s the moral of the story? Apple Pay has a long way to go.

— — — — —

Note: this post was amended due to feedback on the incorrect inclusion of Uber in a list of companies whose apps do not offer Apple Pay. As mentioned above, I have addressed this error in depth in this response.