If you're like most of us, you probably have a personal fitness tracker. Basically, these trackers are full blown computational platforms supporting Bluetooth connections and communications with cloud-based services accessible via RESTful APIs.
Capabilities vary by manufacturer - some platforms allow developers to write application logic that runs directly on the tracker, while others allow you to interact with the cloud ecosystem around the tracker.
In a recent Hackathon challenge, Vantiv's Dan Ourada, payments guru, gentleman farmer, and all around payments geek postulated an interesting challenge - leverage APIs from one of the more popular fitness bands to devise a new commerce model where people rent shoes and pay by the step as measured by telemetry gathered from a Fitbit tracker.
We appreciate there are a few holes in this potential business model, so please suspend your disbelief for just a moment. We're thinking like developers and asking you entrepreneurs in the crowd to "get this idea in shape" and evolve it into a workable payments solution.
- Rental Program
- Imagine a gym membership or bike membership where you pay based on the amount of time or distance that the equipment was used.
- Rewards Program
- How about a membership discount based on the number of steps taken.
Ex. 15,000 steps—best in day—15% off purchase.
- Donation Program
- A walk-for-cause. Next time you join a charitable walk or race imagine paying for your entry-fee and showing the number of steps, time, and/or distance that you contributed to show your support all in one.
Now that I have all of this data what can we do with it? That brings us to the Vantiv API challenge. How can we simplify commerce and/or enable commerce with this type of data? For this use case we are going to use a recent theme in unused capacity, the sharing economy, and attempt to build a product around shoes. A shoe sharing product that pays based on the number of steps taken with the shoes. Hmmmmm…nah, who wants to wear someone else’s smelly shoes? How about this, a new business model for selling shoes? Instead of purchasing shoes outright we’re going to “rent” shoes to consumers and charge a fee based on the number of steps they take as long as they provide us access to their daily Fitbit data and as long as they take at least 5000 steps a day. Now being hackers we are already thinking about how to game this proposal but let’s run with it and see what happens.
How would we go about building something like this and integrating to the Vantiv API. The perfect solution is a website that captures the user’s initial information: Fitbit account, billing/shipping info, shoe size, one or two selected models, and credit card information. We will then use Vantiv’s API via Hosted Checkout to perform a ZeroAuth to verify the card and receive a token which we will then use for subsequent monthly billing transactions. The total cost of the monthly fee will be determined based on accessing the user’s Fitbit data via the Fitbit API. You can browse the API here: https://dev.Fitbit.com/. You will need to sign up for the Fitbit API and register an application.
The data collection portion and initial auth, in this case a ZeroAuth which means we do not charge the card we simply validate that it is a real card, is fairly simple. Navigate over to: https://github.com/MercuryPay/HostedCheckout.MVC.CSharp where you will find a c# integration to our Hosted Checkout API. Using this template we can easily capture the token we will need to store for later use and tweak the template to save the other information suggested above. We're not going to actually implement that logic as it should be fairly straightforward. In addition to the c# example feel free to browse around on the mercurypay GitHub site where you will find PHP, vb6, and Objective C integrations to the Hosted Checkout API.
Assuming we have a token, representing the customer's credit card, and some personal information it's time to charge the monthly rental fee based on steps taken so let's determine how to get the number of steps taken per month from a user's Fitbit account.
To get things started register your application at Fitbit. Here you include various information about your application and type of authentication method you will use. I decided to use OAuth 2.0 server authentication which allows the user to provide this invoicing app permission to access his/her data, the Fitbit API then returns a code that I use to retrieve an access and refresh token. Finally whenever the app makes an API call to Fitbit it passes the access token along to authorize.
The authorization portion was the most difficult to implement however, there are OAuth 2.0 libraries floating around that might make this easier. You can see the implementation in the code. As with the Raspberry Pi repo the code is pretty ugly but in a state that it should be fairly easy to follow.
Fitbit, Fitbit Surge, iPhone, and iOS are registered or unregistered marks belonging to their respective owners who are unaffiliated with and do not endorse or sponsor Vantiv, and Vantiv likewise does not endorse or sponsor Fitbit, Fitbit Surge, iPhone, or iOS.