News   Jul 19, 2024
 628     0 
News   Jul 19, 2024
 3K     6 
News   Jul 19, 2024
 941     2 

Metrolinx: Presto Fare Card

I'm not sure how they do that without creating extra processing costs - I'd have to think they'd be able to offer better pricing for those using Presto, than those using VISA or Interac. Though I guess that doesn't preclude them doing that ... after all, if you make a 12- month commitment now, you get about 10% off what you pay buying monthly.

The "solution" is to not process the transactions until the end of the day. Just record the credit card number and then let the system sort out the charges later, with daily capping or whatnot. Because the number is recorded, the credit card could be used as a unique identifier rather than a PRESTO card.

This does require an overhaul of how the system functions, and there are issues with mobile payment systems like Apple Pay that may generate multiple different numbers.
 
The "solution" is to not process the transactions until the end of the day. Just record the credit card number and then let the system sort out the charges later, with daily capping or whatnot. Because the number is recorded, the credit card could be used as a unique identifier rather than a PRESTO card.

Kinda. They can still put a hold on the card for some amount (say $20) which verifies the card is real and has funds available, then process all transactions at a later time.

My preferred option would be a 7 day hold and a single charge for all activities during that period, including a 7-day price cap around $35. Dump the monthly pass.

Holds work for debit cards too.
 
Holds work for debit cards too.

With Interac, holds are placed as actual charges. Unless something has changed in the past month or two, there is no traditional "hold" possible on Canadian debit cards. A $20 "hold" would immediately remove $20 from the bank account linked to that card.
 
With Interac, holds are placed as actual charges. Unless something has changed in the past month or two, there is no traditional "hold" possible on Canadian debit cards. A $20 "hold" would immediately remove $20 from the bank account linked to that card.

I didn't know. 99% of the finance work I've done has been with US or South American banks (a decade ago now).

An authorization hold *should* leave the money in the account but count against the daily transaction limit and reduce the "available balance" the customer can withdrawal from their account. That is, the balance doesn't decrease but everything else acts as if the money was removed. This is almost exactly the opposite of an overdraft limit which increases the "available balance" but doesn't increase the actual balance. Most banks Canadian banks expose both values online and you can see their impact when cashing cheques then immediately withdrawing/moving that amount, since the bank gives you a bridge loan between the withdrawal and when the cheque actually clears (days, and very rarely months later).

What you describe really sucks for the very poor would have those funds locked-up for the week in a TTC billing system, but so does pre-loading a Bank of Presto account.
 
Last edited:
Here's another example of a streetcar>subway>streetcar scenario. Based on @Megaton327's trip I thought I'd get the last leg counted a transfer, but unfortunately not.

I wonder if PRESTO knew that I was travelling WB, because I tapped on the east side of Yonge rather than the west, and applied the fare policy of not allowing trips that double back. Or am I wrong and can this be argued as one continuous trip?

504 EB, transfer SB on line 1 around the loop and up to King station, then a 504 WB.

23vxh8z.jpg

Can you use a transfer from either King or St. Andrew to board the king car? At least that would be my think as to why it charges a second time, if it's not possible to do with paper transfer why should it be with Presto?
 
Here's another example of a streetcar>subway>streetcar scenario. Based on @Megaton327's trip I thought I'd get the last leg counted a transfer, but unfortunately not.

I wonder if PRESTO knew that I was travelling WB, because I tapped on the east side of Yonge rather than the west, and applied the fare policy of not allowing trips that double back. Or am I wrong and can this be argued as one continuous trip?

504 EB, transfer SB on line 1 around the loop and up to King station, then a 504 WB.

23vxh8z.jpg

System charged you correctly. Why not continue your trip EB on King to Bay St? One stop WB of King Station is Bay St. Your pretty much back tracking in this case. If not, your not taking the "most direct" route. I think that's one of their conditions.s
 
Last edited:
Kinda. They can still put a hold on the card for some amount (say $20) which verifies the card is real and has funds available, then process all transactions at a later time.

My preferred option would be a 7 day hold and a single charge for all activities during that period, including a 7-day price cap around $35. Dump the monthly pass.

Holds work for debit cards too.

This is only possible if you can do it quick enough (<300ms for current reads) on a reader connected to the internet, which most PRESTO readers currently aren't.

If the system works on an assumption that the card is valid, you can test that theory as soon as the data is uploaded, and if the card is invalid, blacklist it.

I'd like to know more about how London has their system setup, because it uses debit/credit with readers not connected in realtime, as far as I am aware. An interesting side effect is that the daily cap on a credit card may be different than the cap value on an Oyster card. The Oyster cap is processed in realtime, making assumptions, while the credit card cap is worked out knowing all of the trips taken in that day/week.
 
Can you use a transfer from either King or St. Andrew to board the king car? At least that would be my think as to why it charges a second time, if it's not possible to do with paper transfer why should it be with Presto?

I wanted to see if tapping would produce the same results. Otherwise yes, I would've taken a transfer at St. Andrew and used that to board the streetcar at King/Yonge.
 
I wanted to see if tapping would produce the same results. Otherwise yes, I would've taken a transfer at St. Andrew and used that to board the streetcar at King/Yonge.
Wouldn't the second 504 trip be a different trip?

It's not like one would travel from Strachan to (say Jarvis) and use the 504 twice, with a subway leg in between.

It's interesting to see the data though!

I'm still trying to figure out how it all works. Check out this trip:

upload_2016-2-13_13-46-39.png


Looks simple enough. But the first leg was starting at Main on a 506. But the second was the return trip on a 506, tapping on at Gerrard and Ashdale.

It appears though, that the location was off, and it thought it was due south on Queen and Connaught. Done this frequently, but every other time it's a new fare, starting at Gerrard/Ashdale, rather than transfer this time (free trip!)

Okay, but we keep thinking that the transfers are route-based not location based. But unless this 506 thought it was a 501 or something (that might explain the location mapping), it's taking location into account.

It's a shame that the summary didn't show the route number - that would help reverse engineer how this is working.
 

Attachments

  • upload_2016-2-13_13-46-39.png
    upload_2016-2-13_13-46-39.png
    27.2 KB · Views: 516
Last edited:
Though this has been noted before, I find it very confusing that when there is a transfer and a zero charge in the Amount 'box' the Balance 'box' also reads $0.00. In the example above it should, in my opinion, read $43.59
 
Wouldn't the second 504 trip be a different trip?

It's not like one would travel from Strachan to (say Jarvis) and use the 504 twice, with a subway leg in between.

By all means it definitely was a 2nd trip for me. However, looking back at Megaton's post a few pages back, his 3rd and 4th leg was definitely part of a 2nd trip (even backtracked fully!) but the system gave him transfers instead of charging. This is why I was curious to see if my 504 WB trip back would count as a transfer or a fare would be deducted and whether the location of the stop determined if I was going east or west.

In your example of going to Jarvis, it's definitely a ridiculous route, but technically it's a valid continuous trip. Wonder how PRESTO would charge that.
 
This is only possible if you can do it quick enough (<300ms for current reads) on a reader connected to the internet, which most PRESTO readers currently aren't.

If you insist on a real-time charge authorization, yes.

It has been found practical for some low-value high-volume locations to perform an asynchronous authorization of the card. Take the data, (let the customer go), and authorize after the fact. If it's good great; job done. If it's not good, they can a) retry the charge later and b) push the card number out to all readers in a reject list. Give customer service a mechanism for clearing the reject list (after the customer pay owing fares).

With that type of mechanism the TTC potentially gives out one free ride to each card accepted as valid, and the transaction (from a customer perspective) takes closer to 5msm(verify the card was originally created correctly in real-time and is something the backend can normally charge, not the current balance or account). The mechanism would be fast enough to deny transfers or tap-out at the subway station exit but I'm not sure I would tend to give out a complete trip and catch them next time.

Once you accept that simply avoiding POP staff, jumping fare gates, or entering through a bus-bay is the easiest fare evasion mechanism, you can ignore that zero balance pre-paid cards (remember, only 1 "free" trip per card) and other complicated tricks simply aren't worth while for most customers; and POP staff would catch them too as they could know whether the charge really completed or not (demanding alternative payment and catching recurring abusers).
 
Last edited:
If you insist on a real-time charge authorization, yes.

It has been found practical for some low-value high-volume locations to perform an asynchronous authorization of the card. Take the data, (let the customer go), and authorize after the fact. If it's good great; job done. If it's not good, they can a) retry the charge later and b) push the card number out to all readers in a reject list. Give customer service a mechanism for clearing the reject list (after the customer pay owing fares).

With that type of mechanism the TTC potentially gives out one free ride to each card accepted as valid, and the transaction (from a customer perspective) takes closer to 5msm(verify the card was originally created correctly in real-time and is something the backend can normally charge, not the current balance or account). The mechanism would be fast enough to deny transfers or tap-out at the subway station exit but I'm not sure I would tend to give out a complete trip and catch them next time.

Once you accept that simply avoiding POP staff, jumping fare gates, or entering through a bus-bay is the easiest fare evasion mechanism, you can ignore that zero balance pre-paid cards (remember, only 1 "free" trip per card) and other complicated tricks simply aren't worth while for most customers; and POP staff would catch them too as they could know whether the charge really completed or not (demanding alternative payment and catching recurring abusers).

That's exactly the concept I was referring to when I said

"If the system works on an assumption that the card is valid, you can test that theory as soon as the data is uploaded, and if the card is invalid, blacklist it."

Most vehicles should be able to connect to the network every few minutes, or hourly at least, like Ottawa now does. Only in a case of equipment failure would a bus have to wait until the end of day to process transactions.
 
  • Like
Reactions: rbt

Back
Top