A QR Specification For Mobile Payments

BitCoin and other crypto-currencies are gaining popularity at the moment - but I remain firmly convinced that they're too hard for the average person to use. I have, however, watched with interest as an ecosystem grows around them.

In particular, I like the way The Pirate Bay (and others) have used QR codes to facilitate easy payments and donations.
PirateBay BitCoin QR-fs8
The QR codes contain only three variables - the payment method (BitCoin), the destination, and a message. As this is a donation there is no value set. There is a full specification for a BitCoin URI scheme which I think is fairly well designed.

I envisage a day when, on asking for the bill at a restaurant, I am presented with a paper slip totting up my purchases with a neat QR code printed at the bottom. Scanning the code will pull up my banking or credit card app and allow me to make a payment. A verifiable receipt is either shown on screen or sent directly to the restaurant.

For example:
QR Payment

 WHO:Pizza Palace

That's enough human readable information - and machine data - to ensure the correct payment gets from one person to another. I'm sure there are some other fields which may be advantageous to add; tax rate, specific location, etc. But it certainly all fit within a QR code.

QR codes can easily be printed out using the current infrastructure of mobile POS terminals. Those terminals already have mobile network access so can be alerted in real-time when the payment is made. IBAN means we have an easy(ish) way to uniquely identify payment destinations. And, in the UK at least, we have a fairly rapid payments infrastructure.

What's needed is a simple standard and mobile banking and credit card apps to support it.


4 thoughts on “A QR Specification For Mobile Payments

  1. Neil says:

    Interesting post Terrance and definitely a genuinely useful application of QR codes. Have you come across Paddle before? http://www.usepaddle.com/ It's integrating QR codes in to online and mobile check out processes in order to do exactly what you're talking about. Making it fast and simple. Just for clarity sake, Paddle are a client of mine, but even if they weren't i'd still be talking about them 🙂

    1. Hey Nial,

      The problem with services like Paddle is that they're proprietary. They only way they succeed is if everyone in the world uses Paddle. That's fine if you want to try to be the next PayPal or Google Checkout - but I think that's far too limited. If anyone wants to use Paddle, then the Paddle team are a bottleneck. What if they reject me? What if they don't support my country? What if there's no BlackBerry app - etc.

      A simple standard means your bank, credit card, wallet provider can create an app and transfer money without having to ask anyone's permission to be allowed to exist.

      Paddle - while very neat - is the equivalent of saying "I'll only take money from you if it comes from a Gucci purse."


      1. Neil says:

        Sorry about the misspelling Terence and interesting points about it being a bottleneck and in terms of complete standardisation and no barrier to entry. Perhaps if i can scan a QR code and then have something like pay to mobile/direct to bill it gets a bit more straight forward - but then again does that still work the same way if i'm a PAYG customer? And then how much of a slice is my MNO going to take out of that from the merchant? Historically it's always been too much.

        1. 🙂
          It could go via a mobile operator, but equally it could go via an app. Either from Paddle or direct from my bank.
          Don't forget, regular credit cards already take a ~2.5% slice. Usually straight from the merchant.

Leave a Reply

Your email address will not be published. Required fields are marked *