Last year I blogged about how easy it would be to pay for parking via QR code. Now it looks like Islington Council have partnered with Verrus to make this a reality.

But is it any good? Well.... nearly. Let's take a look.

The Initial Impression

The QR code is fairly clear and I was able to scan it without issue underneath street lighting. Sadly, there is no call to action. What does scanning the code do? (My camera has somehow mangled the photo. Sorry!)

Code Density

They've used the highest level of error correction ("Q") which is a good idea. In an external environment codes can get damaged or dirty. The higher the EC, the more chance the code will be readable.

However, they've shot themselves in the foot by using an absurdly long URL for analytics purposes.

http://m.paybyphone.co.uk/?
   utm_source=islington&
   utm_medium=qrcode&
   utm_campaign=mweb

Surely this could be made more efficient?

http://m.paybyphone.co.uk/?s=islngtn&m=qr&c=2

Or even better

http://m.paybyphone.co.uk/123456&s=qr

Because, you see, the code only goes to the main payment site - leaving the user to type in the parking bay's ID number.

Code Destination

After scanning the code, this is what the first time user sees.

Annoyingly they've hardcoded the zoom - so users with impaired vision (or fat fingers) won't be able to use the site.

<meta name="viewport" content="width=320,
   target-densitydpi=160,
   maximum-scale=1.0" />

The site is a little bland - and the "sign up" button is hidden out of the way - but it's the functionality which concerns me the most.

Registering

If you've never used the system before, you need to register on this screen. While it's good that they'll take payment from international users, it's plain dumb to require someone to type in a credit card number.

What if there's a gang of vicious hoodies waiting to snatch credit cards from unsuspecting users? How fiddly is it to type out a 16 digit number when you're in a hurry to park? Who is going to remember yet another password or PIN?

(Incidentally, take a look at the above screenshot. Is their branding "paybyphone" or "PayByPhone"?)

Solutions?

Here's how I would set the scheme up...

1. URL in the QR code reflects the location it is in. E.G. http://m.paybyphone.co.uk/123456
2. User scans code, selects the amount of parking they want to pay for. Clicks "Pay".
3. A mobile payment solution charges the amount to the user's bill, or deducts it from their credit.
4. User walks away happy. No need to register or remember a Personal PIN Number for identifying herself.

Scan, select, click. No typing, no memorising, no hassle. Surely that's better than fiddling around with credit cards?

Overall

A little disappointing. A great first step, but it could be made so much easier with mobile payments.

Disclaimer:

I currently work for InMobi who have a product called SmartPay. There are several other cross-network payment solutions like Boku or Beem.

This blog is personal and does not represent my employers in any way.

You may have seen these Ringo.co.uk ticket machines. They are meant to be a convenient way to pay for parking tickets - but could QR codes make them more useful?

The user's action is: call, quote a number, their numberplate and then their credit card details. This is all done using speech recognition. Speech recognition can be handy - no fiddling about pushing numbers in on a tiny keypad with your frozen fingers - but on the noisy streets of London, its accuracy can be a bit hit-and-miss. You also run the risk of someone overhearing your credit card details.

So, how can QR codes make this easier for the customer and increase revenues for the vendor?

Click To Call

This is perhaps the easiest to implement. Prevent wrong numbers by creating a simple QR code to call the phone number.

We could also implement a pause, and then get the phone to dial the touch tone code for the ticket station the user is at. The RFC for the tel: specification indicates that "p" be used as a pause character. It seems that some phones accept only the "," character. I've found this difficult to work consistantly - although the worst-case scenario is that the phone number is dialled but no DTMF tones are passed.

Mobile Payments

Finally, rather than faff around with credit cards - why not use mobile payments? This code goes to an (as yet) non-existent mobile page. From here, the user can type in their vehicle's registration number and pay either using mobile payment, their credit card, Google Checkout, PayPal... whichever service RingGo wants to offer.

Other Considerations

In an environment like a city, it is quite likely that the QR code will get damaged, defaced or simply dirty. By increasing the error correction within the code, we can ensure the code is readable even after quite severe alteration.

There are four different levels of error correction. The greater the level, the smaller the individual pixels become - so there is also a small trade off in readability.

Low (7%)

Medium (15%)

Quarter (25%)

High (30%)

End Result

At the very least, this reduces the possibility of dialling an incorrect number. Used to its full potential, the user's journey is...

1. Scan Code
2. Enter vehicle's registration number
3. Single click on a payforit button and have the cost added to their phone bill.

Surely that's much better than messing about with creaky voice recognition while holding your credit card out for any passing ne'er do well to steal?