Introducing Clover Mobile

Clover Mobile, the world's first mobile, integrated POS device with EMV chip card,
NFC contactless, and on-screen PIN entry. 

Clover’s mission is to put an API on every store on the planet. This was born out of the frustrations that we as app developers targeting merchants had: it was difficult to impossible to build and distribute our innovations to small- and medium-business. We've made great strides over the past year, having sold nearly 30,000 Clover Stations through our parent company, First Data, and their merchant acquiring partners such as Bank of America, Wells Fargo, PNC, and SunTrust. We've launch the Clover App Market, where many apps are now live and many are in development.

Today we take a giant leap forward in achieving our mission: we’re proud to introduce Clover Mobile, the world’s first integrated, open, mobile POS system with all modern payment interfaces: EMV chip card reader, NFC reader, magnetic stripe reader, on-screen PIN entry, and 1D/2D barcode scanner. We believe Clover Mobile will become the “swiss-army knife” computing device in stores, and we're inviting you to develop apps for it.

A Better Terminal

The humble single-function payment terminal is the most ubiquitous device in real-world commerce. There are 17 million payment terminals sold every year worldwide. Clover Mobile may be used only as a payment terminal at a shop on day 1, but on days 2, 3, and 4 it will be used for loyalty programs, CRM, voucher and coupon redemption, employee time cards/scheduling/management/payroll, physical+mobile gift cards, inventory management, alternative payments, customer membership programs, and the full integrated POS system over time. We find that many of these apps either have payments somewhere in their flows, or are better because of the integration in some key way. We’re not picking the winners and are not so arrogant we think we can do everything ourselves: this is why we have an open API both on the device side (where you can write Android apps) and on the cloud (with our REST-ful web APIs).

Design Thinking & Technical Details

Clover Mobile is a modern tablet augmented with payment superpowers:

• Quad-core Tegra 4 SoC
• Clover’s hardened version of Android (AOSP) 4.4
• 7" 1280x800 display
• Dedicated secure processor for payment interfaces
• EMV chip card reader, NFC reader, MSR reader
• On-screen PIN entry (w/ solution for the visually impaired)
• World-class 1D/2D trigger-activated barcode scanner
• LSR rubber bezel and handle base for soft landings
• Charging base
• WiFi, Bluetooth (w/ Bluetooth LE/Smart), and optional 3G
• Bluetooth+BLE thermal receipt printer

Clover Mobile has a rather distinct feature for a tablet: a handle. We wanted to build an industrial-class device without appearing industrial. The handle makes the device easy to carry all day long while scanning barcodes, inserting chip cards, and swiping. It also provides an integrated stand for presenting the device to customers.

Start Developing Now

We'll be providing a developer hardware program soon (sign up here if you're interested). Until then, get started at www.clover.com/developers. The Android and Web APIs that exist for Clover Station all work on Clover Mobile, and there will be a number of APIs specific to Clover Mobile's unique features, primarily around secure payments. You can build any app you want, using our secure payment application.

Order and Pay from Table at Bierhaus, powered by Apple Pay, Clover, and Estimote's iBeacon

Update: The Bierhaus app is now live in the App Store! Come play with it at Bierhaus in Mountain View, CA.

Background: Clover and First Data (our parent company) have been working with Apple to prepare for the launch of Apple Pay. Clover is enabling our cloud-based point-of-sale platform to accept Apple Pay In-App payments. Here's a sneak preview of what we did with Bierhaus, a beer garden in Mountain View, CA. We'll be open sourcing most of the Bierhaus app in the coming weeks. You can read more about how Apple Pay works from my first blog post. 

When I look outside the window from the Clover office, I often see a line outside Bierha.us. Here's the line as I write this post on Friday evening.

Bierhaus, with its ever-present line, shot from my window.

Now, I'm someone who hates waiting in lines, particularly if I'm going for a quick happy hour break at work. I'd like to just sit down, order from phone, and have my beer magically appear. So we built an app for that.

There are several key components to making the Bierhaus app work:

• Apple Pay. Users can download the Bierhaus app and order and pay without typing in a credit card number or creating a user account. This is a leap forward in convenience and usability.
• Clover. Clover is a cloud-based point-of-sale platform. POS systems are the central nervous systems of restaurants and retailers. We built Clover to be hackable (in the positive sense) to enable app developers to build new apps that use menu/inventory data, submit orders/tickets, make payments, print to kitchen printers, etc.
• Estimote. We use Bluetooth Low Energy beacons to know the user is in the store.

The Bierhaus app for iPhone 6 lets you order:

And pay:

We have several Estimote Beacons placed around Bierhaus. Right now, this is mostly to restrict people from ordering beer when they're not at Bierhaus. In the future, you could do much more interesting things, such as automatically determining the table number (e.g. see Downtown) or creating a real-time map of where your customers are and doing path planning for delivery.

Thanks to the beacons and the Estimote SDK, I get this handy lock screen app:

Where to from here?

Clover has thousands of merchants on its platform, and is growing at thousands of merchants per month. Over the coming weeks and months, we'll be enabling developers to build a raft of experiences: self-checkout, order ahead, pay at table, and order+pay at table. We expect that most apps targeting small and medium businesses will act as aggregators serving many merchants, not a single merchant like the Bierhaus app does.

We'll be open sourcing some apps and experiences we've been developing. Our goal is not to be a consumer-facing brand, but we need to develop these apps to prove out our platform quickly and iteratively. We welcome developers to pick up where we've left off and commercialize these experiences.

Other Wallets and Android

Any wallet that simply provides a credit card number can be used with Clover. For example, Google Wallet Instant Buy is Google's analog to Apple Pay In-App payments. Instead of using network-level tokenization like Apple Pay does, they instead use a proxy card with single-use tokens. Different design, but similar end result from an end-user, merchant, and developer perspective.

John Beatty is co-founder and head of engineering at Clover. Follow him at @beatty.

Clover is hiring! We're looking for world-class engineers and designs to join our team to fulfill our vision of putting an API on every store on the planet.

How Apple Pay works and why it matters for developers

Update: If you'd like to learn more, come to Clover's Apple Pay developer event in Mountain View on Wed, Oct 8: http://www.eventbrite.com/e/apple-pay-deep-dive-how-it-works-and-what-it-means-tickets-13394038931?aff=blog

Background: Clover and First Data (our parent company) have been working with Apple to prepare for the launch of Apple Pay to support developers, merchant acquirers, and issuing banks (see First Data's press release). Clover is enabling all merchants to accept In-App payments, and will be In-Person/NFC enabling all merchants as well (see https://www.clover.com/features/iphone). Here's a bit of how it works from a developer's perspective, and why it matters.

Apple Pay marks the first time a popular operating system is making payments a platform service for real-world, non-digital-good transactions, in a broad, inclusive manner that is compatible with the mainstream payments processing industry. At Clover we're particularly excited because we believe it opens up lightweight apps that can interact and transact with small-and-medium brick-and-mortar restaurants. By lightweight, I mean that these apps won't need to maintain a user database, require user logins, worry about getting cards on file, or being an unwilling payment aggregator. i.e., it will be at least 10x easier. I expect a huge amount of innovation in real-world mobile commerce as a result over the coming years because of the revolution that Apple Pay is starting.

Network-Level Tokenization

"All problems in computer science can be solved by another level of indirection". -- David Wheeler

The first and most important thing to know about is tokenization.

The payment networks (Visa, MasterCard, Amex, etc.) have been very busy building something called tokenization. I call this network-level tokenization to distinguish it from the more familiar forms of tokenization, which is typically performed at either the gateway (such as the Braintree card vault) or the acquiring platform (such as First Data's TransArmor).

E-commerce developers should be quite familiar with the concept of credit card vaults, which take in the PAN and give you back a token to use in its stead. These vaults are typically provided by e-commerce payment gateways, such as Braintree or Stripe, and let you put credit cards on file for your users. I call this gateway-side tokenization. The defining characteristic of these tokens is that they're scoped to a single merchant. They're useful for a developer who wants to keep a credit card on file (to enable low-friction transactions) but without the burden of securing (and associated compliance) of maintaining a database of PANs.

Here's the authorization flow when a gateway-side token is used:

Gateway-side tokenization

The payment networks are proposing something very different: network-side tokenization. These tokens are very different. They are essentially aliases for PANs that are exchanged during an authorization by the network. These tokens are provisioned (see below) into the secure element on the iPhone 6 and used in authorization flows (further protected with 3-D Secure -- see below).

Here's the authorization flow when a network-side token is used:

Network-side tokenization

There are several important things about these network-side tokens:

• They look like standard PANs -- e.g. they're 16 digits. They're mostly compatible with the existing payment processing infrastructure.
• The tokens are issued within a special BIN in the network's routing tables that flag it as a token rather than standard PAN.
• They are exchanged via the network by Token Service Providers, a new role in the ecosystem.
• They are provisioned via a Token into a secure element of a mobile device or some other "secure enough" storage (perhaps Android HCE), facilitated by the issuing bank.

Most developers reading this have likely never read an EMVCo specification, but this one is worth a read: EMV Payment Tokenisation Specification – Technical Framework.

This is the typical way that a developer would provision a token:

Token provisioning

EMV token provisioning is entirely different -- it's between the issuer, the wallet, and the Token Service Provider:

Network-side tokenization

The end result is a token that can be used across merchants and both online (In-App) and offline (NFC, In-Person).

User Logins

After thinking about it a second, you might realize "why do I need my user to create an account with an email address and password at all?" A primary driver (though not only) was to have an account to associate the gateway-side token with. This is no longer strictly necessary: A consumer could simply download an app that connects them with a local merchant, browse the menu, and buy something from their table. This is really important when it comes to apps for small- and medium-sized businesses (local merchants).

Accidental Merchant Aggregators

Many mobile wallets and online-to-offline services have become merchant aggregators, where the company becomes the merchant-of-record for many submerchants.

Say you're an order-ahead app enabling consumers to buy food and pick it up later. You really don't want to be in the payments business, but how else do you collect money from the consumer and to the restaurant? There's so much friction in the system that the typical way is to become the merchant-of-record, which is a position you accept begrudingly. Chargebacks and disputes? It's your problem now.

Network-level tokenization, and iPhone in particular, will radically change this dynamic. Commerce apps won't be forced to become aggregators any longer -- they simply need to use the iOS payment SDKs, and the SDK from the merchant acquirer, to process the payment.

Clover is making this even easier -- all Clover merchants will be enabled for In-App payments, which will give developers instant access to many thousands of merchants through our APIs (for submitting and reading orders, reading and updating menus and retail inventory, receipt printing, etc.). We're selling Clover Station to thousands of merchants a month, enabling developers to reach these merchants through the Clover App Market.

iOS Payments SDKs

Developing an iOS app that uses Apple Pay In-App payments is quite simple. You will use two different APIs:

1. iOS In-App payments API, for interacting with the user and getting a payment token.
2. Your merchant acquirer's API, for processing the transaction with said token.

Check out First Data's Payeezy SDK (even more so if you're a Clover developer). In the future all Clover merchants who desire it will automatically be able to accept In-App payments.

3-D Secure

3-D Secure, known commonly as Verified by Visa and MasterCard SecureCode has been largely ignored in the U.S. This is a crude analogy, but 3-D Secure is the e-commerce analog to EMV (which authenticates a cardholder via cryptograms coming from the card). It provides authentication from the issuing bank to use the token that has been provisioned onto the iPhone.

Developers working on iPhone In-App payments don't need to know the details of 3-D Secure when they use Payeezy, but I find it interesting (and you'll find some references to 3-D Secure in the Payeezy SDK).

Here's what a transaction message to a gateway looks like before 3-D Secure (from the Payeezy API docs):

{
    "merchant_ref": "Astonishing-Sale",
    "transaction_type": "purchase",
    "method": "credit_card",
    "amount": "1299",
    "currency_code": "USD",
    "credit_card": {
        "type": "visa",
        "cardholder_name": "John Smith",
        "card_number": "4788250000028291",
        "exp_date": "1014",
        "cvv": "123"
    }
}

And after 3-D Secure (also from the Payeezy API docs):

{
  "merchant_ref":"merchant-specific-info (This is optional)",
  "transaction_type": "purchase",
  "method": "3DS",
  "3DS":  {
    "type": "A",
    "version": "EC_v1",
    "merchantIdentifier": "mock-1",
    "applicationData": "VGhpcyBpcyBzb21lIHRlc3QgZGF0YS4gIDAxMjM0NTY3ODk=",
    "data": "v6cqGDrjcJUCLdpRkSQIt...",
    "signature": "AKCAMIIBoTCCAUgCAQEwCQYHTBFMQswCQYDVQQGEwJVUzE...",
 "header":  {
      "applicationDataHash": "4b5745dd55d72886c06a2c65bb05...",
      "ephemeralPublicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0D...",
      "publicKeyHash": "YmSWN7lj4+A6fVJVPicP8TgS7gI7oug...",
      "transactionId": "34303833303938"
    }
  }

Apple Pay NFC Payments

NFC has been derided for years in the U.S. (though my coworker's 65-year-old mother arrived from Australia a couple days ago complaining bitterly that merchants here can't take tap payments). It's a really great technology that's just been waiting for a tipping point. That point is here.

Apple Pay uses industry-standard EMV contactless protocols over NFC (and MSD contactless for backward compatibility). This makes it compatible with a wide range of contactless payment terminals in deployment today. Clover is NFC-enabling all current and future Clover products.

About the author: John Beatty is co-founder and President of Engineering at Clover. Follow him at http://twitter.com/beatty. Follow Clover Engineering at http://twitter.com/CloverEng. Press can be reached at press@clover.com.

SmartTables is the Disrupt SF 2014 Clover Sponsor winner!

Congratulations to SmartTables, winners of the $5,000 Clover sponsor prize for the TechCrunch Disrupt 2014! Ray Ho and Mark Watson combined iBeacons with a restaurant mobile app to seamlessly mark a table as occupied when patrons arrive and pay for their bill when they leave. Customers can also order food from the app to speed up service even more.

Congrats to SmartTables creators @rayho and @Mark_Kettner! They're the winners of Clover $5K prize at #HackDisrupt pic.twitter.com/rtGRWRMF6l
— Clover Engineering (@CloverEng) September 7, 2014

See a full writeup and the SmartTables demo on TechCrunch.

This was one of a number of great teams that hacked on Clover. Given 24 hours to hack on Clover's RESTful web API and Android SDK, teams came up with smart coupons, getting change back in Bitcoin, grocery shopping by recipe, and more.

We're excited to see how much innovation one weekend can bring to small and medium businesses. Being an open platform means that is hacking on Clover is a year-round event! Learn how to publish your app in the Clover App Market at https://www.clover.com/developers.

Techcrunch Disrupt 2014 Hackathon Fun

How Clover became an open platform

You have an amazing idea for a restaurant you frequently visit.  When you finish eating, diners can just get up and walk out.  Their account will be charged.  You even know how you want to pitch it to investors.  It's going to be the Uber for Restaurants.  You are a good programmer so you start building it.  It looks really good.  Time to test it out.

INSERT INTO awesome_solution
VALUES(closed system, impossible sales challenge);

You can't hook it up to the card terminal, no terminal maker wants you messing around with card data.  You can't plug it into a PC point of sale system, they don't want you breaking something and then causing the restaurant to call their support line.  Worse, you realize that even if you do figure out a way to MacGyver the solution, you now have to go door to door trying to sell your solution.

We faced the same challenge.  So we decided to blow up the closed world of point of sale.  We broke the monolithic POS into lots of apps.  We connected these together with APIs and exposed our web services to everyone.

INSERT INTO awesome_solution
VALUES(open system);

Then we found First Data.  First Data processes $2 trillion every year.  Not a typo.  Capital T.  And they were determined to replace the terminals of their six million merchants with this open platform.  They retrained thousands of salespeople and started to spread Clover everywhere.

INSERT INTO awesome_solution
VALUES(distribution, distribution, distribution);

That's it.  So go build your awesome solution.  Raise lots of VC money.  Go public.  Live the dream.

Meet our Developers: Charity Checkout

Discover how one of our earliest developers, Charity Checkout, integrated with Clover.