As you probably heard, we announced a very cool piece of hardware today called PayPal Beacon. As a geek, of course I wanted to find out how exactly it works and what this means as a developer.
First, it is important to understand how PayPal check-in works and then we can delve into how Beacon fits in. If you have the new PayPal app, you will notice that there is a “Shop” tab that allows you to find stores nearby that accept PayPal. Once you have found a location, you can check in by swiping the button fromleft to right.
The merchant makes a call every so often from their point-of-sale system (it could be PayPal Here or one of our partners like MICROS, NCR, ShopKeep, Vend, etc.). This call asks “who is in my store?” and returns the ID and photo of consumers that are present. These are displayed on the POS, ready for use by the merchant when you enter the store.
When the merchant wishes to bill you, she selects your name and photo. The POS makes a call to PayPal requesting money from your user ID and the transactions occurs. So, how does Beacon change this? Basically it makes it even easier for anyone with a cell that supports BLE (Bluetooth Low Energy). Just entering the store activates the PayPal app on a consumer’s cellphone and checks them in automatically. There’s no need for them to take their phone out of their pocket or purse. If this is their first visit, the app will ask them if they want to check in. If they decline, or ignore the prompt altogether, their information is never shared with PayPal or the merchant.
Let’s dig deeper into how BLE actually works in this model. A BLE connection consists of a central device and a peripheral device. A common example is a heart rate monitor (peripheral) sending pulse readings to the phone (central) during exercise. BLE assumes that the central device is likely to be more sophisticated and have more batterythan a peripheral device. In the case of PayPal Beacon, the phone is the central, and our beacon is the peripheral. The peripheral sends out advertising beacons on a regular basis that embed a service UUID as well as a few bytes of advertising data. The central device observes these services and can then establish a connection if it understands the UUID. The peripheral then exposes an attribute dictionary, the central can read and write to this dictionary, as well as subscribe to be notified of any changes. In the typical use case, the peripheral would be observing some activity and reporting results to the central.
In our case, we expose a more generic set of request/response values in the dictionary. When the phone wants to make a request, it writes to the request entry; responses are notified through the response entry. PayPal Beacon, rather than observing local events, either handles requests directly or passes them on to the PayPal servers. The server provides a response to be sent back through the response entry. In short, the Beacon acts as a communication bridge for requests that it cannot service itself. This allows PayPal Beacon to handle sophisticated queries from the phone—fetching information about a particular location, making requests to check in, getting a check-in response, or receiving a payment notification.
When the consumer comes in range of a Beacon, the PayPal app wakes up, connects to the Beacon, and requests a Beacon token. The Beacon selects an unused Beacon token from its cache, and sends across a cryptographic nonce, some metadata, and a cryptographic signature. The phone verifies the signature with a public key embedded in the app, and then makes a check-in decision based on the metadata. If the phone has never seen this location or merchant before, the app asks the consumer whether they’d like to check in, and whether they’d like to check in automatically in the future.
The app then encrypts some data, for the Beacon to forward on, uninterpreted, to the PayPal servers. The server decrypts the data and checks in the consumer. The server then returns an encrypted message back to the Beacon, which forwards it back to the app. The app decrypts and verifies the response and disconnects from the Beacon.
If, on the other hand, the consumer decided not to check in, the app simply disconnects from the beacon. The initial interaction was completely anonymous; it cannot even be detected whether the same phone had made a request before. This means that neither PayPal nor the merchant can track or identify the consumer unless they actively opt in. The final exciting thing about this design is that PayPal Beacon still works in places that where cell phones have no network or wireless coverage. This is common in many stores around the world as consumers are usually indoors.
As a developer working with the mobile in-store API, you will do many of the same things as I mentioned at the beginning of the blog. You make a call that asks “who is at my location?” and then a follow-on call to charge this individual.
I’m sure your brain is now spinning with ways you could use Beacon. If you want to be one of the luckypeople to get one of our early release devices and access to the API, please go to www.paypal.com/beacon and tell us what you would build. We will pick the winners and be in touch.
- New REST API Feature: Setting a Receiver for Payments
- PayPal is Now Available Through WooCommerce 2.6 Onboarding Wizard
- Adaptive Payments is Moving to Limited Release – What you Need to Know
- Building the Next Step in Payment Tutorials with Stack Overflow Docs
Connect with us!
- January 2017
- December 2016
- October 2016
- September 2016
- July 2016
- May 2016
- March 2016
- November 2015
- September 2015
- August 2015
- June 2015
- April 2015
- March 2015
- November 2014
- October 2014
- August 2014
- July 2014
- March 2014
- February 2014
- January 2014
- December 2013
- October 2013
- September 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013