Spreedly’s Take on Apple Pay
For those of us in the payments industry, the announcement of Apple Pay in September was one of conflicting emotions. We found it both exciting and, yet, unfulfilling. Exciting in that it represented a compelling evolution of digital payments, but unfulfilling in that we had so many more questions than were answered in the initial announcement. How does it really work? How does it integrate with the existing card payment process? Can it be unlocked to work with any payment processor?
In the two months since that initial announcement, and the weeks since Apple Pay was actually released, Spreedly has learned a lot about Apple Pay. I’d like to give an update on our plans for supporting Apple Pay and why we’re excited about the opportunity.
How does Apple Pay work?
Much of Apple’s marketing around Apple Pay uses new or existing payment terms in non-standard ways. While this simplifies the consumer message, it makes it difficult to understand how the technology works. Now that we’ve had some time to dig deeper, we understand what’s going on beneath the covers and can talk in more detail about the process.
Apple Pay is unique to Apple and its devices. However, it is enabled by an existing payment specification called the EMV payment tokenization spec. This specification governs how real credit cards are turned into channel-specific alias numbers (PANs), which offer a greater level of fraud protection. Apple utilizes this tokenization process, while adding its own process for getting the alias PAN from the device to the merchant’s gateway.
You can visualize the payment flow, from when the card gets added to iOS’s Passbook through to the transaction hitting merchant account, as follows:
Please feel free to share this diagram
While Apple Pay represents a new, polished, consumer experience, it leans heavily on the existing EMV tokenization spec, which dictates how the alias credit card numbers are issued, identified and converted within the payment process. While it’s likely Apple had a hand in constructing this specification, it is not unique to Apple and can be used by other vendors.
What is unique to Apple Pay is how the payment token is constructed and the role of gateways in decrypting the payment token to expose the alias PAN. At the time of transaction, Apple uses the certificate provisioned by the merchant to encrypt the alias PAN and associated data. This encrypted token is then passed directly to a gateway that supports Apple Pay (and has the certificate’s private key) which knows how to decrypt and unpack the payment token. From this the gateway extracts the alias PAN, which looks just like a normal credit card number, and passes it off to the rest of the payment process for approval.
How will Spreedly support Apple Pay?
Spreedly is not a gateway. It is a credit card vault that integrates with dozens of gateways and other PCI-compliant APIs. So how can Spreedly play a role in the Apple Pay payment process?
If you’ll notice, the responsibilities of a gateway, as it relates to Apple Pay, are minimal. A gateway is really only doing two things: 1) Managing the private key associated with the iOS app’s certificate and 2) decrypting the payment token at transaction time to access the alias PAN. As it turns out, you don’t need to be a gateway to do those things.
If Spreedly assumes the role of the gateway solely in managing the Apple Pay certificate and decrypting the Apple Pay payment token, it can provide a single Apple Pay experience on top of any of the over 70 gateways we support. Additionally, because a payment token looks and acts like a real credit card number to the majority of the payment stack, it can be sent to non-gateway providers like ticketing, travel and other vertical APIs.
Notice how Spreedly’s support of Apple Pay differs only minimally from the conventional, gateway-specific, flow:
At Spreedly, we enable new payment technology across the widest range of payment targets possible, and that’s how we’re approaching Apple Pay.
When can I use Apple Pay on Spreedly?
For customers on one of our current pricing plans, we’re targeting a GA release in the first quarter of next year. We are already hard at work on it and have a few existing customers working with us as we move towards a private beta. If you would like to be included in the beta, please let us know. We’re always interested in understanding your specific use-case and hearing your feedback.