From: johnl@iecc.com   
      
   >>That's how the Oyster system in London works.  When I was there last   
   >>year, I used my US issued Amex card to tap in and out, and it billed   
   >>me once a day for whatever I used.   
   >   
   >The important feature of the Phoenix system is that it billed passengers   
   >the lowest combination of fares, so that that the passenger didn't have   
   >to decide to purchase a pass. That's not what you're describing.   
      
   Oyster does indeed do day capping.  It'll never charge you more than   
   what you'd have paid for a day travelcard.  It does have its   
   limitations.  When I was in London last time, I realized as I bought a   
   train ticket on the day I left that I'm old enough for senior fares.   
   If I'd used my regular Oyster card, I could have asked a staff member   
   at a tube station to do something at a turnstile that permanently   
   flags the card so I get the senior fares but they can't do that for   
   credit cards.   
      
   Re the card reading terminals, since magstripes are pieces of magtape,   
   the readers are subject to physical wear as the cards are swiped or   
   dipped or whatever.  Sure, we have decades of experience keeping them   
   going, but compare the card reader on a MTA bus with a slot and a   
   motor and the one on a Muni bus, with no moving parts at all.   
      
      
   >As far as complex transactions, given that the stripes get written to,   
   >your position is unreasonable that any complex fare transaction couldn't   
   >be encoded.   
      
   Maybe, but I don't think I've ever seen a magstripe system that   
   handled anything more complex than passes for a single system.   
      
   >It's not actually necessary to write anything to fare media. These can   
   >all be handled with back office transactions, with the card itself   
   >used for nothing more than account ID.   
      
   As I understand it, that doesn't work for performance reasons.  A   
   turnstile can consult a server in the same station, but not the master   
   one somewhere else.  TfL says an Oyster transaction has to take no   
   more than 350ms, and they grudingly accepted 500ms for bank cards with   
   a promise from the banks that the next generation will be faster.   
      
   >>The MTA's RFP looks pretty sensible.  They want it to use regular bank   
   >>cards and NFC smartphones as well as MTA issued cards, they want a   
   >>central system that manages the fares connected by a private network   
   >>to all of the fare machines and gates, and as much as possible they   
   >>want to use stuff available off the shelf in the US.   
      
   >It sounds like it's based on Cubic's Ventra, which we have in Chicago.   
      
   Take a look at the RFP.  I can't tell whether they have a specific   
   vendor in mind or not.   
      
   >I don't understand why smart phones went with a different chip standard,   
   >considering they wanted to get into the payment business. I thought EMV   
   >was the older standard.   
      
   EMV was designed in the early 1990s, and needs to work on cards with   
   no internal power.  NFC is a decade newer and is a lot more flexible.   
   It can't be that hard to do both -- just about every contactless   
   point of sale terminal I try works with my NFC Android phone.   
      
   --- SoupGate/W32 v1.03   
    * Origin: LiveWire BBS -=*=- UseNet FTN Gateway (1:2320/1)