Mercator Blog

Why Apple Pay Will End Card-Not-Present Rates for In-App Purchases
Date: September 16, 2014
Research Team
Earlier this year, my colleague Michael Misasi made a prescient observation about the near future of interchange pricing for merchants accepting card payments in the United States (see Credit Interchange Under Pressure from Industry Trends). He said:

In the near term, merchants, not regulators, will likely exert the greatest influence over interchange pricing. Indeed merchants now have many tools at their disposal including payment steering rights (e.g., surcharging), opportunities to collaborate with each other to develop a merchant-oriented payment system (e.g., MCX), an ever expanding array of alternative, low-cost payment types (e.g., Bitcoin), and direct negotiation of rates with card networks.

While network-branded credit and debit cards remain the dominant forms of payment for e-commerce transactions, the last few years have seen the introduction of a host of new options for consumers to pay with and merchants to accept. These range from digital wallet solutions such as PayPal and Google Wallet to Coinbase, a Bitcoin wallet and transaction gateway.

The latest entrant into this crowded space is Apple Pay. Most of the commentary on Apple’s entry into the payments space has focused on the NFC-enabled “tap and pay” capabilities of the new iPhone 6 and Apple Watch. During his presentation on Apple Pay at the Apple keynote, Eddy Cue, SVP of Internet Software and Services, mentioned another potentially game-changing capability of Apple Pay—its ability to facilitate in-app purchases by iPhone users. Cue went on to specifically identify apps like Uber and OpenTable as early adopters of this technology. No longer would iPhone users have to store their card on file separately with each app they do business with. Instead, Apple Pay would securely deliver tokenized payment credentials to the app in question, which could then use the token to complete the payment through its merchant acquirer. All Apple Pay transactions are verified by Touch ID, ensuring proper user authentication and adding a further layer of security for the consumer and potentially limiting the merchant’s exposure to fraud.

In our recent Mercator Advisory Group Viewpoint examining the implications of Apple Pay for the payments ecosystem (see A Sleeping Giant Awakes: How Apple Pay Work and What it Means for Payments), we cited credible reports suggesting that Apple seems to have negotiated with card issuers for discounts worth 15–25 basis points on each Apple Pay transaction in exchange for the reduced fraud levels ensured by Touch ID. Furthermore, a recent report from Bank Innovation which quotes John Lambert, group executive of digital channels at MasterCard, suggests that networks have agreed to process all in-store Apple Pay transactions initiated via Near Field Communication technology on the new iPhone 6 at “card-present” rates. In-app purchases made through Apple Pay, however, will continue to be processed at “card-not-present” rates. This is despite the fact that from a technical perspective, very little that is different is happening in either case. For an in-app purchase, once the consumer authenticates the transaction with Touch ID, Apple Pay delivers tokenized payment credentials from the phone’s secure element to the app on the cloud via the phone’s data connection.

From the perspective of the merchant or the app developer, this difference can add up to a pretty penny. A back-of-the-envelope calculation illustrates this point fairly well. Stripe, a popular payment gateway services provider that has announced support for Apple Pay, currently charges merchants/developers 2.9% and 30 cents for each successful transaction it processes. Card-present rates for in-store credit card transactions, on the other hand, cost merchants about 2.10% and 10 cents per transaction—a difference of more than 80 basis points. For a hypothetical merchant that does business worth $10 million annually through a mobile app with an average ticket size of $50, this difference in payment taxonomy could mean as much as $120,000 in lost profits for the year.

Merchants will inevitably voice their discontent against this archaic distinction that technology has today made redundant. When that day comes, the question is who Apple will side with. The developers who build the apps that make the iOS ecosystem attractive to consumers? Or the card networks and issuers whose support Apple needs to ensure the continued success and adoption of Apple Pay? My bet would be the former, especially given the variety of payment technology alternatives available to merchants and consumers today, many of which bypass the traditional card network rails altogether.