Written by Yesterday marked the 10 year anniversary of Contactless on TfL buses; a new generation of fare collection was born that delivered convenience beyond anything that had gone before for customers and much needed cost savings for TfL. Consult Hyperion were engaged by TfL to figure out the means by which contactless could be accepted at the gate and on the buses, and in the first of a series of blogs, we revisit some of the work completed which led to the success of contactless in London and in other cities around the world.
One of the first challenges for the Consult Hyperion team, was to determine if a single reader could accept and process Contactless transactions as well as the existing Oyster transactions and ITSO, the national transit smart ticketing standard. While they were all based on the ISO/IEC 14443 standard, each were subtly different enough to make the process of accepting them a challenge.
Critical to TfL’s operation is getting fast transitions through the gates in often cramped stations. Anything more than 500ms could result in queues and safety issues of people leaving stations. Oyster cards were transacting in about 300-350ms, depending on what the transaction was and we knew that a contactless payment card just met the target on good silicon, but with additional reader processing time spent determining what type of card and checking for previously denied cards and ‘passback’, was 500ms possible?
So with that firm target, we set the challenge to our Hyperlab development team, who are masters at fast build prototypes to validate the aspirations of our clients, to build a demo reader on comparable hardware to the TfL reader to determine if it was possible. The team had considerable experience of developing the payment kernels given our expertise supporting the likes of American Express and Visa, and to this they added simulated processing for Oyster on Mifare Classic and ITSO on Mifare Classic, DESFire and Innovision Jewel. ITSO adds a significant challenge due to the number of media supported.
Our initial prototype was good, but missed the target for Contactless payment cards and some ITSO cards. The team set about optimizing the code, specifically the activation and detection steps of the reader to ensure there was a logical approach to determining which card was being presented to ensure the 14443 routines were repeated as minimally as possible. This meant, that there was no point checking for payment cards before checking for Oyster, because if it wasn’t a payment card, the field would need to drop and the selection process restarted. Oyster and ITSO cards that supported the lowest levels of 14443 needed to be checked first.
We also incorporated and prototyped the fast searching of large lists of tokenized card numbers to optimize deny list processing; necessary in the new transit transaction model.
The result was a success! We had proven it was possible for the one reader to accept and process Oyster, ITSO and Contactless payments on the same device and all within 500ms. This critical prototyping and optimization enabled the project to proceed, providing vital input to Cubic who were developing the production reader for TfL.
Next time, the search for the Transaction Model.
