June 2026

Account-based QR ticketing is surprisingly challenging to implement.

The timing and throughput requirements of a mass transit system such as the LRT and MRT lines in Manila require an offline decision by the gate or validator. We also have to accept that delayed uploads and missing records cannot entirely be avoided.

As a result, the matching algorithm for entry and exit records gets riddled with exceptions. In fact, no matter how we design the system, a certain number of records will refuse any attempt of matching and fare calculation.

While I will focus on the matching of entry and exit records, a complete solution must also consider liability allocation and requires a certain amount of risk acceptance. Any attempt to make an QR account-based ticketing system fool prove with no chance of even the tiniest loss will fail!

I have gathered my thoughts on the topic, but I feel that there is a lot more to say. Please do not consider this little write-up the be-all and end-all on the subject.

I was asked recently how I would design an account-based QR code ticketing solution. That is a simple question. But it would require more than one article to even just scratch the surface.

It brought back memories of discussions about static offline authentication and other topics which I thought are buried and forgotten under the thousands of pages of EMV specification and the long-winded migration from magnetic stripe to chip cards.

But here we go again. The good old magnetic stripe swipe under the "modern" guise of a QR code scan.

Nevertheless, I am old enough to remember most of it and decided to take a quick shot in this article.

A message exchange on FaceBook prompted me to write a response to my friend Regie, which became so long that I turned it into an article.

I already talked about the risk of anonymous account-based transit cards in my previous article (1). In this piece I am adding a couple thoughts on the topic.