Apple iBeacon Payment Experience

14 May 2014

Last week I outlined what was coming out in the iPhone 6 from a capability/payment perspective. Today I will cover my best guess at the user experience, a 50% confidence guess…

Beacons

First a little about Beacons: Qualcomm is the technology behind Beacons and they just spun out Qualcomm Retail Solutions last week with external investors to form Gimbal. My bet is that Apple was in the mix, as Apple’s iBeacon is the brand and handset side of what QCOM developed and owns. Apple’s iBeacon appears to be dependent upon QCOM license (see Patently Apple). You can see the similarity in Apple’s patented logo with QCOM’s logo.

Think of beacons as proximity devices with context. From QCOM

Gimbal proximity beacons complement GPS by allowing devices and applications to derive their proximity to beacons at a micro-level not currently afforded by GPS technology on consumer devices. A user’s mobile app can be enabled to look for the beacon’s transmission. When it’s within physical proximity to the beacon and detects it, the app can notify the customer of location-relevant content, promotions, and offers.

Here is a fantastic blog by beekn outlining how beacons operate and the advantages of the QCOM Gimbal platform. Beacons only transmit…they do not listen. Beacons can operate in a private mode where the UUID is dynamic and resolvable only within the Gimbal cloud, be public (Static UUIDs) where any application can read them, or registered as iBeacons  (see Gimbals as iBeacons).

Apple Patents

In January, the USPTO published a new Apple patent application: Method to send payment data through various air interfaces without compromising user data (see Patently Apple). PCT/US2013/049622. US20140019367

[0002] Devices located in close proximity to each other can communicate directly using proximity technologies such as Near-Field Communications (NFC), Radio Frequency Identifier (RFID), and the like. These protocols can establish wireless communication links between devices quickly and conveniently, without, for example, performing setup and registration of the devices with a network provider. NFC can be used in electronic transactions, e.g., to securely send order and payment information for online purchases from a purchaser's mobile device to a seller's point of sale (POS) device.

[0003]Currently, payment information such as credit card data in mobile devices is sent directly from a secure element (SE) located in a device such as a mobile phone through proximity interfaces, such as near field communications (NFC), without an associated application processor (AP), such as an application program in the device, accessing the payment information. Preventing the AP from accessing the sensitive payment information is necessary because current payment schemes use real payment information (credit card number, expiration date, etc.) that can be used to make purchases through other means, include online and via the phone, and data in the AP can be intercepted and compromised by rogue applications.

[0004] Thus, there exists a need for a secure method of executing a commercial transaction that is both secure and user friendly.

I believe the patent above describes what Apple is going to market with this October. There are several potential payment experiences depending on the merchant integration and the consumer handset. Specifically the patent seems to be written broadly enough where NFC is NOT a requirement for the “secure commercial transaction” referred to as the second secure link. As I stated Payment via BLE/Beacons will Still Happen, the issues are around:

1. Issuer certification of tokens,
2. bluetooth as the transport in the new EMVCo spec
3. who will provide token assurance information and how will they be compensated, and to what degree will interchange be discouneted
4. Treatment of token in Card Not Present (interchange)
5. Merchant Adoption of NFC, Beacons and BLE

In the scenario of a new BLE capable point of sale, with a “second secure link” operating as BLE with the POS there is no need for a payment terminal at all.. and all iPhones with Bluetooth could interact directly with the POS (think Micros/Starbucks). Here is my short list of customer experience use cases

Optimal Payment Experience

Here is my best guess and what Apple would like to have happen:

Set up

• Consumer has BLE capable phone
• Consumer enables Apple wallet and permissions payment with physical merchant
• Banks have loaded tokens into Apple wallet for each registered card (see blog)
• Merchant installs iBeacons near multi lane checkout, and registers location with apple merchant application. Another option would be to allow payment terminals to broadcast MID/TID beacons.
• Merchant installs POS Bluetooth capability to receive consumer identifier and send total amount due, as well as eReciept.
• Merchant payment terminals are upgraded to receive tokens through Bluetooth or other “Air Interface”

Experience

1. Consumer walks up to cash register, beacons determine close proximity and wake up Apple payment application,
2. Consumer preferences are checked and approved merchants receive apple identifier, consumer loyalty card information, applicable discounts/coupons to the point of sale
3. Merchant scans goods for purchase and processes loyalty, coupon, discount information
4. Merchant POS (or payment terminal) sends total amount due to consumer phone directly via BLE based upon apple identifier
5. Consumer receives notice on phone “Pay $100 to Merchant? Please confirm with fingerprint”
6. Consumer validates transaction with fingerprint biometric
7. Phone submits Card token to Payment Terminal via Bluetooth (not happening in October.. it will be NFC)
8. Merchant processor routes token to payment network which translates and routes to bank for authorization
9. Payment is authorized (as happens today).

October Launch Experience

Since Banks won’t support tokens over Bluetooth, Apple is stuck with NFC. The process is very similar to above, but my guess is that merchants will not be prepared to support the exchange of consumer information.. so it is iBeacon plus NFC only.

1. Consumer walks up to cash register, a payment terminal beacon provides information to Apple payment application that it is close proximity to payment terminal ID xxxxx (TID),
2. Merchant scans goods for purchase. No mobile processing of loyalty, coupon, discount information
3. Merchant payment terminal cannot send total amount due since it does not have Apple handset information/UUID. So how will Apple do it? My guess is Apple will provide UUID to the Payment Terminal via BLE at application wake up to perform a “lite” checkin with payment terminal. Good news is that there would be no data connectivity requirements, but it requires a new payment terminal… For everyone else.. there is no total amount due (99% at launch).
4. Legacy NFC. At application wake up,  phone asks “pay merchant with Apple wallet”?
5. Consumer validates transaction with fingerprint biometric
6. Consumer taps phone (NFC) and Card token presented Payment Terminal via NFC Merchant processor routes token to payment network which translates and routes to bank for authorization
7. Payment is authorized (as happens today).

Apple’s biggest challenges?

1. Merchant NFC adoption. Much of it is caught up in the fact that there are no debit cards in the mobile wallets (see blog Forces against NFC)
2. Merchant adoption of Beacons and new payment terminals. No wonder Verifone is excited.. big merchants know this can all work without ANY payment terminal.. this is the big leap. The decision on payment terminal is now just nuts. EMV, EMV+PIN, EMV + PIN + BEACON, EMV+ PIN + BEACON + BLE…
3. No business case for Apple in payments. Perhaps one of the reasons they are struggling to get an exec to lead this over there. Apple’s product people should ensure that their Treasury guys aren’t going to kill this thing. Banks know if consumers can’t choose their payment product that wallets will die. Apple should be focused on getting every single one of their 800M cards on file into the wallet, and ensuring the debit cards are added. This is key to making this work
4. Organizational. No one leading
5. Bank certification of Tokens in a Bluetooth transfer
6. Token assurance information
7. Merchant POS integration (see the optimal example above)

 

That is how I see it… comments welcome

Another good article on the overall Beacon/Retail Experience.

http://www.pcmag.com/article2/0,2817,2425052,00.asp