It’s been a month since Apple announced Apple Pay and today the service went live. There’s been a lot of uncertainty about what this means for Flomio, our products and the NFC ecosystem at large. Simply put: Apple’s announcement has been awesome for Flomio and is the shot of adrenaline that NFC needed. It has rejuvenated a technology often referred to as “NFC – Nobody Freakin’ Cares” and once again developers along with enterprises are excited about integrating it into their offerings. They’re asking hard questions like, “how can I deliver a personalized experience to a customer with an iPhone6?”, “can I engage them using something other than expensive POS terminals?”, and “will I be able to trigger NFC actions like on Android devices?”. Flomio has answered these questions for industry leaders like Carnival and Texas Instruments and we can answer them for you.

Let’s break things down, literally. First off, the iPhone6 includes NFC hardware designed primarily for emulating tags. The coverage from their September event along with the teardown from iFixit shows the NFC loop antenna is placed on the upper edge of the device. This presents a limited scan surface of around 10mm² (shown below, more details here). This design means the device(s) can “act like” an NFC tag or contactless credit card but not effectively read them.

The 3 Modes of NFC

The NFC Forum (standards body that governs NFC) defines 3 modes for the interface to work: Discovery, Card-Emulation, and Peer-to-Peer. Discovery is the most basic function, and one that allows for a reader to interrogate to a tag. Card-Emulation lets a reader imitate a tag containing data often stored in a Secure Element. Peer-to-Peer let’s two readers establish an open serial link. When Android devices first came out with NFC they supported Discovery and Peer-to-Peer. They offered a flexible framework allowing developers to experiment with the technology using tags and apps. Apple has done it different, adding NFC hardware with only Card-Emulation support and offering little to no access for developers. Their design uses the AS3923 booster IC which is meant to amplify the signal from a reader. This is a clear indication that Apple’s solution is solely focused on payments and the enablement of Apple Pay.

Apple has done it different, adding NFC hardware with only Card-Emulation support and offering little to no access for developers.

Does that mean it’s impossible to do anything but payments with an iPhone6? Yeah, kinda. There’s a method we often use when UUIDs are static but in the case of Apple’s NFC implementation, they went with randomized UUIDs. Check out this video of a quick test I did with my neighbors’ phone:

Every NFC tag is required to have a UUID, or unique identifier, to avoid confusing NFC readers if other tags are close by. UUID’s are normally static but the specification allows for dynamic ones as well (for privacy purposes). Below is a scan report from a contactless credit card being read by a Nexus 7 tablet using NFC TagInfo, the same app I used in the video.

You’ll notice in the middle image that this tag’s UUID is 4 bytes long and set to 0x96591656 while the “Is random ID?” field is absent. This UUID is static and the same across scans. It’s unique from about 4 billion other possibilities. If Apple was setup this way, a developer could create an cloud-connected experience triggered by an iPhone6. Just by tying the UUID to a cloud data store with push notification support, an instrumented terminal could read the UUID and send a contextual notification to a preinstalled app. The diagram here details this approach in the blue line.

The NFC point of interaction starts with a FloBLE paired with a Host terminal. Once on iPhone6 is presented in the field, the UUID is captured and used to query on online data store. The web app is triggered to perform some response and sends a notification down to the iPhone6. The notification can be via text message or an in-app notification.

Another approach is necessary when the Host or User is out of cloud coverage and is shown in the red line. The FloBLE captures the iPhone6 UUID and sends it to a local data store for validation. This can reside on the Host Terminal itself or on a server connected through a local area network (LAN). Once the response is crafted, the Host Terminal can put the FloBLE into iBeacon mode and broadcast a notification over BLE to the iPhone6.

Both of these approaches rely on static UUIDs to work. Apple has said publicly that it doesn’t want to know “who you are, where you shop, or what you buy” so it’s not likely they will revert to static UUIDs any time soon. What they are more likely to do is allow developers put cryptographic profiles into the Secure Element by way of a reserved application identifier (AID). We’ll talk more about AIDs in a followup post, but it basically means the FloBLE would be able to select that particular profile during an iPhone6 interrogation. If the signed messages are validate, then the developer application on the reader side and iPhone6 side could be notified.

The benefit of the UUIDs over AIDs is a much faster user interaction even though it’s at the expense of privacy. It may appear we’re splitting hairs unnecessarily but for high traffic applications like transportation systems, AIDs can cause congestion. Because of payment security requirements, Apple Pay -at a contactless point of sale- needs you to keep the phone on the reader until the transaction is completed. Notice the user experience of this reporter trying out Apple Pay:

In a typical retail scenario it probably makes sense to stay at the cashier until the transaction is approved anyway but there are many other scenarios where the tap-and-go ability is compelling. Take a drive thru or food truck scenario where queues often form. Getting your order in and moving along while paying for it would be nice.

Digital Payments 101

For people in the payments space, Apple Pay has introduced a battle where consumers will ultimately decide the winner. It centers around the “card-present” (offline) payments experience rather than the “card-not-present” (online) equivalent. Rick Oglesby wrote an amazing article where he suggests Apple Pay as it stands won’t be enough to win at offline payments. Let’s cover some of the basics.

Apple now offers to take payments: 1) iTunes account-on-file, 2) Apple Pay via API, 3) Apple Pay via Contactless (NFC).

There are 3 methods that Apple now offers to take payments: 1) iTunes account-on-file, 2) Apple Pay via API, 3) Apple Pay via Contactless (NFC). The first method, account-on-file, has become a staple in online commerce and brought companies like PayPal and Stripe much success. Some have brought the concept into the brick-n-mortar space with success as well. For example, when a consumer uses a barcode application, like the Starbucks app, the transaction is considered card-not-present because the consumer’s card that’s linked to the barcode is not physically presented to complete the transaction.

Panera App

The second method, Apple Pay via API, is entirely novel since it effectively straddles the line between card-not-present (CNP) and card-present (CP). The consumer’s card is stored in the iPhone6 Secure Element. It’s like a little vault that only your fingerprint has the key to open. Through the PassKit Framework API, developers can easily request account information from the Secure Element. A couple examples shown last month were the remote ordering apps from Uber or Panera Bread. Now this method is no different than the third method, Apple Pay via Contactless (NFC), in terms of pulling the account information from the Secure Element. Yet payment gateways that support Apple Pay like FirstData and TSYS are still charging merchants double the fees (CNP vs CP). While it is still too early to know which innovative solutions will achieve widespread adoption, it is clear that many of these solutions blur the line between the current definitions of card-present and card-not-present transactions. The industry may ultimately have to reconsider the payment network acceptance, operating rules and transaction fees associated with these transactions.

An Easier Way to Pay

Apple Pay launched today.  If you have an iPhone6, check out how to set yourself up here. The twitter verse is filling up with posts about the experience on #ApplePay.. most seem positive so far: It’s exciting to watch a technology unfold like this over the years and we’re looking to empower developers to accept Apple Pay as soon as possible. The payments industry includes a dense set of certifications, PCI and EMV, that we’ll start breaking into in our next post. Until then, hit us up with any questions on our Forum.

– Richard and the Flomies.