Grand River Transit

[danbrotherston]

GRT emailed all us farecard beta testers today and had us fill out an experience survey.

Included in the email, if anyone had questions or doubts:

Keep in mind that when the beta test ends, your EasyGO fare card is yours to keep. Any fare products left on the card after the beta test ends are yours to use. The only thing that will change is that you'll no longer receive the 20% discount when you reload your card.

That's great they confirm that, perhaps they are listening to us on the forum .

In other news, my parents are moving back to London ON.  When they left about two years ago, I recall that the London Transit Commission (LTC) was in the midst of a smart payment fare card rollout.  Upon returning, I find that they are still in the midst of a smart card fare card rollout...it's a scary prospect, I do hope ours is going more smoothly.

[chutten]

I get the occasional media read error, but "smoothly" is the closest adverb to how the beta test is going from my experience.

Now if they'd open up online pay and auto-recharge, I would remove any remaining reservations I had about it. Not looking forward to trekking to a terminal to recharge.

[KevinL]

Now if they'd open up online pay and auto-recharge, I would remove any remaining reservations I had about it. Not looking forward to trekking to a terminal to recharge.

I was sure to make comments in this regard on my survey response.

[Canard]

Is the reader technology compatible with smartphones?

What I mean: why not have an easyGo card in your iPhone Wallet, so you can just tap your phone.

[KevinT]

Is the reader technology compatible with smartphones?

What I mean: why not have an easyGo card in your iPhone Wallet, so you can just tap your phone.

Apple are very developer-unfriendly when it comes to NFC.  It's only in the latest-and-greatest iOS version that there are any developer APIs for it at all, and those only allow for the phone to read other things, not to emulate the things being read.  Unless the region could somehow get Apple to code it into Apple Pay, from which Apple always gets a percentage of every transaction, there's just no way.

Android allows full 'Host Card Emulation', which in theory can do the job, but depending on how GRT's fare system works that may not be a magic bullet either.

If you look at Presto for example, the card stores the value and the history of recent transactions so that the next reader tapped can examine previous taps to figure out if any transfer or discount applies.  This is great because it allows the readers to work 'offline', without communications delays or blockages to worry about when figuring out go/no-go on any given tap.  But when you load value onto your Presto card online, EVERY machine in the system has to be updated (which for buses and streetcars is only when they're back in the garage) with a leger of outstanding loads, so that the next time you tap your card the 'reader' can write the value back onto it to complete the load.

Why is that an issue for Android?  Because the mobile would have to emulate a card of its own, with a unique identity, stored value, and transaction history that's completely independent of your physical Presto card.  You couldn't start a trip on one and then continue with the other.

If GRT's system works like Presto with 'stored value' on the cards themselves, then similar limitations will apply to the mobile use case, even on Android with those wonderful card emulation APIs for the developers to use at no charge.

[KevinL]

I've seen Apple technology used for fare payment; you can use an iPhone or Apple Watch instead of an Oyster in London, for example. (Oyster also accepts credit and debit tap cards.)

[Canard]

Thank you (as always) for the detailed explanation!

[tomh009]

I've seen Apple technology used for fare payment; you can use an iPhone or Apple Watch instead of an Oyster in London, for example. (Oyster also accepts credit and debit tap cards.)

Same for Suica/PASMO in Japan. It's only iPhone 8 and X, though, not the earlier models.

[danbrotherston]

I've seen Apple technology used for fare payment; you can use an iPhone or Apple Watch instead of an Oyster in London, for example. (Oyster also accepts credit and debit tap cards.)

Same for Suica/PASMO in Japan. It's only iPhone 8 and X, though, not the earlier models.

As KevinT provided in a great explanation, the fundamental payment technology is different.  Oyster terminals also accept Visa cards, which means, so far as I understand, that every single payment terminal must have a continuous internet connection.  Offline payments are not possible.

Offline payment is possible with Presto, and I believe GRT has gone with the same underlying technology.  Moreover, they are unlikely to ever allow Android phones (or any non-GRT secured hardware) to communicate with the payment terminal.  Because your card stores the account value, if you can access the hardware (and by hardware, I mean the chip that is embedded in the card), you could program in a balance which doesn't exist.  Moreover, you certainly cannot transfer a card to your phone, because in doing so you'd be able to rewrite the balance.

[KevinL]

Would it be possible to have, say, an expanded EasyGo app on an Android that is linked to an account that serves like a card - the balance would be managed by the (proprietary, encrypted-data-using) app and not the phone hardware itself?

[danbrotherston]

Would it be possible to have, say, an expanded EasyGo app on an Android that is linked to an account that serves like a card - the balance would be managed by the (proprietary, encrypted-data-using) app and not the phone hardware itself?

It *might* be possible.  But its certainly a challenge.  Technically there's probably a way to build a secure system, given the phone wouldn't have to store the secret.  The biggest issue I see with that is a huge increase in latency.  I'm not convinced that GRT or their contractors would be able to get network response times down to a level where it would be reasonable for tap payment, especially over a mobile network. But hey, if they were that would be awesome.

[megabytephreak]

All the new phones with NFC also have a secure element, a separate processor which is supposed to be able to store this kind of info on a user device, without them being able to alter it. This include an ability to load "apps" which are also secure from each other. This emulates the behavior of the processors in the DESfire cards. One of the applications is (eventually) to replace SIM cards with an eSIM functionality, which I understand has similar security requirements to something like a fare card. So from a technical perspective it is supposed to be possible to do the stored value thing securely. I'm not sure how far along the phone vendors are on exposing this functionality though.

Perhaps the bigger issue is that given the locally stored value model, there would need to be a mechanism to move the info from a card to phone, or from phone to phone (i.e. if getting a new phone). And if your phone died, anything stored on it (passes, value) would not be able to be recovered without risk of duplication (how do you prove it it dead). Some sort of revocation mechanism might be possible though, similar to what I think is supposed to be available if you lose your card and it is registered.

[chutten]

As KevinT provided in a great explanation, the fundamental payment technology is different.  Oyster terminals also accept Visa cards, which means, so far as I understand, that every single payment terminal must have a continuous internet connection.  Offline payments are not possible.

Not necessarily. Credit card companies are only too happy to wait for a vendor to clear transactions a day or more later. (An extreme example: you can still use a physical carbon-paper credit-card payment device these days. The ones that go "ka-chunk ka-chunk")

In fact, Transport for London's implementation wouldn't work without post-facto clearing. It requires you to use your credit card at tap-in -and- tap-out (and whenever a ticket inspector comes along). At the end of the day (or whenever they reconcile all of their data inputs in their system) they determine which cards tapped in, which cards tapped out, and which cards were inspected. If you've been inspected without tapping-in and out, you are penalized. If you've tapped-in without tapping-out, you pay the maximum fare. You also have per-day and per-week capping so that they only charge your credit card for the minimum of the sum of your individual trips, or the value of a daily or weekly pass over that period.

They can do this through <technical details elided> ... basically they use crypto verify the card hasn't been tampered with, and then read the card number off of it. At the end of the day they gather all the timestamped and location-tagged actions per card and reconcile what to do with them (given the prior travel history of that card in the TfL system in the preceding six days)

Offline payment is possible with Presto, and I believe GRT has gone with the same underlying technology.  Moreover, they are unlikely to ever allow Android phones (or any non-GRT secured hardware) to communicate with the payment terminal.  Because your card stores the account value, if you can access the hardware (and by hardware, I mean the chip that is embedded in the card), you could program in a balance which doesn't exist.  Moreover, you certainly cannot transfer a card to your phone, because in doing so you'd be able to rewrite the balance.

To my knowledge there is no technical reason you can't put a stored-value card like easyGO Fare Card on Apple/Android Pay. (search words: "secure element" "NFC") There are lots of political reasons not to.

I'd see it far more likely that they'd furnish Apple/Android Pay with the device-specific card number and treat it like a credit card. Record the transactions, reconcile at day's end (but instead of reconciling against credit card companies, it would be against a centralized stored value balance). To be clear, I don't see this as at all likely, just _more_ likely.

[danbrotherston]

As KevinT provided in a great explanation, the fundamental payment technology is different.  Oyster terminals also accept Visa cards, which means, so far as I understand, that every single payment terminal must have a continuous internet connection.  Offline payments are not possible.

Not necessarily. Credit card companies are only too happy to wait for a vendor to clear transactions a day or more later. (An extreme example: you can still use a physical carbon-paper credit-card payment device these days. The ones that go "ka-chunk ka-chunk")

In fact, Transport for London's implementation wouldn't work without post-facto clearing. It requires you to use your credit card at tap-in -and- tap-out (and whenever a ticket inspector comes along). At the end of the day (or whenever they reconcile all of their data inputs in their system) they determine which cards tapped in, which cards tapped out, and which cards were inspected. If you've been inspected without tapping-in and out, you are penalized. If you've tapped-in without tapping-out, you pay the maximum fare. You also have per-day and per-week capping so that they only charge your credit card for the minimum of the sum of your individual trips, or the value of a daily or weekly pass over that period.

They can do this through <technical details elided> ... basically they use crypto verify the card hasn't been tampered with, and then read the card number off of it. At the end of the day they gather all the timestamped and location-tagged actions per card and reconcile what to do with them (given the prior travel history of that card in the TfL system in the preceding six days)

Possibly, I don't know the implementation details of Oyster, but at least here, card processors have moved to online processors. All the payment terminals we have are online.

Historically they used the offline terminals (the paper ones), but even then you were required to check other ID or even call the Card Issuer under certain circumstances. It's all about risk of fraud. Processors can charge more for riskier transactions. Which is why there is a limit on how much you can tap to pay.

To my knowledge there is no technical reason you can't put a stored-value card like easyGO Fare Card on Apple/Android Pay. (search words: "secure element" "NFC") There are lots of political reasons not to.

I'd see it far more likely that they'd furnish Apple/Android Pay with the device-specific card number and treat it like a credit card. Record the transactions, reconcile at day's end (but instead of reconciling against credit card companies, it would be against a centralized stored value balance). To be clear, I don't see this as at all likely, just _more_ likely.

It may be technically possible to implement stored value cards using the secure element on most modern phones, but now they're trusting a third, open ecosystem, as a trusted secure store of value. That simply isn't going to happen.

I don't see them implementing a non-stored value option, given that they've gone through a lot of technical hoops to achieve stored value. But that could be done securely with phones given that the NFC wouldn't be storing anything. I also have no idea if the payment terminals are capable of this.

One thing of note, there is a reason for stored value cards over account backed cards, and that's one of anonymity. While I don't personally use this, many people do feel it is important to be able to travel without being tracked. This wouldn't be possible without stored value cards.

[danbrotherston]

All the new phones with NFC also have a secure element, a separate processor which is supposed to be able to store this kind of info on a user device, without them being able to alter it. This include an ability to load "apps" which are also secure from each other. This emulates the behavior of the processors in the DESfire cards. One of the applications is (eventually) to replace SIM cards with an eSIM functionality, which I understand has similar security requirements to something like a fare card. So from a technical perspective it is supposed to be possible to do the stored value thing securely. I'm not sure how far along the phone vendors are on exposing this functionality though.

Perhaps the bigger issue is that given the locally stored value model, there would need to be a mechanism to move the info from a card to phone, or from phone to phone (i.e. if getting a new phone). And if your phone died, anything stored on it (passes, value) would not be able to be recovered without risk of duplication (how do you prove it it dead). Some sort of revocation mechanism might be possible though, similar to what I think is supposed to be available if you lose your card and it is registered.

*supposed to* being the key here.  GRT is unlikely to trust a third party open ecosystem to store value.  If there was a bug found in Android's implementation (or any Android phone vendor, there are hundreds), anyone could get free rides, there's nothing GRT could do to stop it, besides stop accepting that form of payment, which is much harder to do than simply not starting.

But I don't make GRT policy, I guess it's possible they'll surprise us one day.