Evan Schuman's StorefrontBacktalk

Burger King has been doing its own mobile payment trial at about 50 stores near Salt Lake City in Utah. But the fast-food chain isn’t working with Google Wallet, ISIS, PayPal or any of the other major mobile players. Its approach is trying to avoid the political—and technological and security-related—friction associated with the more well-known strategies by using a Starbucks-style stored-value card, and then adding a heck of a lot of cloud.

Burger King’s method can work on any iPhone or Android, completely denies any payment-card data to the retailer (keeping the whole trial out of PCI scope), requires no hardware changes and is all based on a cheap printed QR code stuck on the back of the POS or on a drive-through window.

The trial—Burger King is working with vendor Firethorn Mobile—is fairly simple. The consumer downloads the app onto his or her iPhone or Android phone, and then uses a regular payment card to load money into the app. At this stage, it’s a stored value card—not meaningfully different from what Starbucks uses.

Once inside the store, the customer scans the QR code. Given that it’s a static printed QR code, it doesn’t represent the order. “It merely says, ‘You are in Store 2007 and at register 3,'” said Steve Statler, Firethorn’s senior director of strategy.

This is where the cloud kicks in. The associate keys into her POS that a mobile app customer is there and that information goes into the cloud, along with her restaurant and register number. When the consumer scans the QR code, that info also goes to the cloud. Once a match is made, the associate’s POS screen tells her to proceed and take the order. Once the order is complete, it goes back to the cloud, which then sends the order and the amount to the customer’s mobile screen with a request for payment authorization. Once approved—and once it’s been verified that the funds are truly there—the money is credited to that store’s Burger King account and the associate is told to serve the food.

“We’re opening a two-way dialogue with in-store systems and the customer’s phone,” Statler said.

From a PCI perspective, it’s out of scope, because the restaurant is never given any payment-card data. We’re not talking about a token or end-to-end encryption or anything else. The store never even sees the data, nor can it access that information.

The authentication with the Burger King trial is with a four-character PIN. But, Statler said, the authentication is decoupled, so a retailer could just as easily choose to use a retina scan.

“It’s like Starbucks, but without the hardware,” he said. “For a large national chain, doing an upgrade to optical scanners is very expensive.”

Future capabilities—which are not being tested in the Burger King trial—would be adding menus to the app, along with integrating CRM profiles.

One other way to avoid friction, in this case, involved Apple. As Apple moves into mobile payments—or at least gets very close—there are always concerns about getting mobile apps approved for Apple’s App Store. By having the app be a Burger King app (as opposed to a Firethorn app, which is how Firethorn used to do this), Apple is much more inclined to clear it through.

“The reality is that the people who have the power to make this mobile (effort) happen are the retailers,” Statler said. “It’s got to be their app.”