I still am using a supply I got prior to the price rise earlier this mid year, and I note that a lot of people are still using Metro tickets.

I do note too, that now Coles Express ex Shell no longer sells bus/train ie, public transport tickets.

Has anyone seen a decrease in use of the Metro tickets _on the trains_, (not considering our "free riders"-less so as they may be these days).

Has anyone heard of a date when the orange/black tickets will no longer be available, I know they are starting to probably be less now, ...

I am more so a bus person, in the North Eastern suburbs, of course, no trains, except the OBahn.

I still am using a supply I got prior to the price rise earlier this mid year, and I note that a lot of people are still using Metro tickets.

I don't use public transport too often these days as I generally prefer the speed and reliability of my bicycle, but I don't see too many multitrip metrotickets remaining in use on the occasions I do. The paper single/day metrotickets are still fairly common for irregular users or those who forgot their Metrocard.

I suspect that the vast majority of regular users prefer the Metrocard now. The only reason I can see for sticking with the plastic multitrip metrotickets would be annoyance at the price hikes spiralling out of control, but the average person would be more likely to use that as a chance to consider a better form of transport than pay up-front for a whole bunch of tickets.

I do note too, that now Coles Express ex Shell no longer sells bus/train ie, public transport tickets.

That would have been a decision of the franchisee operating that particular outlet, not a top-down decision coming from Wesfarmers HQ. Many outlets of the franchised chains didn't sell tickets even before Metrocard came along, the commission earned being so small (not even enough to cover the transaction fee charged to the vendor for selling them via EFTPOS or credit card) that it was often more trouble than it was worth.

I used to work in a deli/cafe that sold metrotickets for a while when I was working there so I know how this worked - a rep would come to collect the unsold tickets, that total would be subtracted from the total number issued and an invoice sent for the difference. I expect it still works the same way for the few remaining vendors of single and day paper tickets as that was a system that works quite well for the department - so long as there are third-party vendors who would lube up, bend over and take it. I'd be interested to find out exactly how it works for Metrocard recharges, my guess is that it's effectively the same except for the machine phoning home at the end of each day to update the central record instead of a rep coming to recover the remaining tickets and count how many were sold.

For the record, we had a cash-only policy for metroticket purchases due to the commissions being too stingy to cover the cost of doing an EFTPOS/CC transaction. The owner would happily have changed that if only we were allowed to add a processing surcharge added on top or the commission was decent enough to make it worth our trouble, but obviously the department didn't really care that much about making their tickets accessible to everybody.

Has anyone heard of a date when the orange/black tickets will no longer be available, I know they are starting to probably be less now, ...

I expect that they have already been discontinued and that none have been printed with the new 2013-14 prices. Any remaining stocks of the 2012-13 priced multitrip tickets would have been recovered and destroyed by Adelaide Metro at the start of July, as they used to do every year with the remaining stocks from the previous year.

The way that metroticket sales worked for third-party vendors was that they would return the unsold stock and get sent a bill for the stock which was not returned (minus the commission). I suppose that a lunatic metroticket vendor could try to do the dodgy and hold on to a bunch of previous tickets, but it wouldn't be profitable and it wouldn't be worth the risk of getting caught defrauding the state by a revenue protection officer in plainclothes.

Multitrip tickets are gone, you will not get one anywhere now. The paper ones will be kept, for single and day trips for irregular users who don't want/have a metrocard.

Justapassenger is about right with the way the Metrocard system works, except it 'phones home' during every transaction in order to update the user balance instantly. Commission is still 4/5 of FA, which is why paying by CC at a third party vendor is rare.

Thanks Aaron.  Noted.

According to the lady at the Coles Express I normally go to to get my old style tix, AdMet came and took away the whole kit. folders and tixs.

Yes, I had prebought them before the price rise.

No more tricks of saving $ money come each end of the financial year with the orange & black tix.  Apart from prebuying Daytrips!

Okay, back to the daily grind.

According to the lady at the Coles Express I normally go to to get my old style tix, AdMet came and took away the whole kit. folders and tixs.

That would have been because the owner of that Coles Express franchise decided to withdraw from doing ticket sales at the time instead of carrying on with Metrocard recharges and/or single/day metrotickets.

As mentioned before, many Coles Express franchises made this move ages ago including back when they were just Shell franchises. My local Shell franchise ten years ago wasn't a Metroticket vendor, which was annoying when the only other vendors in the area were business hours only.

Justapassenger is about right with the way the Metrocard system works, except it 'phones home' during every transaction in order to update the user balance instantly.

That surprises me, I thought they would go through daily just like the online CC recharges do.

That surprises me, I thought they would go through daily just like the online CC recharges do.

I am fairly certain that's true, a friend's mum is a lavender lady and he and I tagged along to her training session on using the machines to see how it was all going to work ahead of the limited trial when the cards were first released. We were told that everything was updated instantly 'via the Internet'... A very exciting training session it wasn't, but the scones for afternoon tea were quite awesome.

It is not instant though here is a copy and paste from the Adelaide Metro FAQ section.


Your updated balance and transaction history statement may take up to 24-48 hours to appear on your online metrocard account.

Your updated balance and transaction history statement may take up to 24-48 hours to appear on your online metrocard account.

Key words: online Metrocard account.

As a software developer by trade (with quite a bit of experience with web front ends that access back end systems), it's common practice for web sites not to access the source system where data is stored.

One reason would be that the system that holds metrocard balances would be getting constant read/write requests from the recharge machines, and to reduce the system load, only the recharge machines can make direct connections.  There would probably be a batch job that runs a couple of times per day that copies Metrocard balances into a separate database that is accessible via the web.  This would account for the delay in showing your updated balance if you do so online.

Other reasons for doing this could be security related e.g. any vulnerabilities in the source system can't be exploited via the web, or access related e.g. if a catastrophic system failure occurred on the back end, users can still see their balance as at the last refresh date.

Me and a fellow developer had a look at the system when it was rolled out; without being privy to the ins and outs, my guess was that recharge machines dial home via 3G, and update some data on the card itself (hence the need to put it in the slot).   I'm not familiar with the tech used on the cards (though it was an interesting read) but I figure it has the smarts to be able to deduct 1 fare when a connection is made with a device (I'm guessing it uses NFC or something similar).  The validators would keep a record of the validation so that any subsequent attempts can give the 'transfer balance' message, and I am guessing the validator itself sends a batch of validations over a 3G connection whenever it can obtain one.  

All purely speculative on my part, of course

Today I asked at another Coles Express, and this time was told they are waiting "possibly" for more of the ticket machines so they (Coles Express) can start to have rechargeability.

Not sure if this was/is true or not, but just have to wait and see if they (the recharge system & hardware) do appear in Coles Express.

Only reason I used to buy my tickets from Coles Express was to earn FlyBuys.

So I have to now gravitate towards IGAFoodland to get tickets/recharge or newagents when I have cash in my pocket.  Otherwise recharge at Admet city centre outlet or at stations.

Key words: online Metrocard account.

As a software developer by trade (with quite a bit of experience with web front ends that access back end systems), it's common practice for web sites not to access the source system where data is stored.

One reason would be that the system that holds metrocard balances would be getting constant read/write requests from the recharge machines, and to reduce the system load, only the recharge machines can make direct connections.  There would probably be a batch job that runs a couple of times per day that copies Metrocard balances into a separate database that is accessible via the web.  This would account for the delay in showing your updated balance if you do so online.

Other reasons for doing this could be security related e.g. any vulnerabilities in the source system can't be exploited via the web, or access related e.g. if a catastrophic system failure occurred on the back end, users can still see their balance as at the last refresh date.

Me and a fellow developer had a look at the system when it was rolled out; without being privy to the ins and outs, my guess was that recharge machines dial home via 3G, and update some data on the card itself (hence the need to put it in the slot).   I'm not familiar with the tech used on the cards (though it was an interesting read) but I figure it has the smarts to be able to deduct 1 fare when a connection is made with a device (I'm guessing it uses NFC or something similar).  The validators would keep a record of the validation so that any subsequent attempts can give the 'transfer balance' message, and I am guessing the validator itself sends a batch of validations over a 3G connection whenever it can obtain one.  

All purely speculative on my part, of course

That's about exactly as it is. There is no info stored on the card other than the account number (for want of a better term).

The card carries no balance information, that is held in the back end of the system somewhere. When catching PT, you wave your card, the computer pulls your account number, fare type and time, checks for funds, deducts funds, updates the balance and returns such to the validator screen.

When adding your finances to the card it is only placed on the machine to pull your account number, the balance is updated by the back end.

The reason for the 'user' recharge machines requiring you to put your metrocard in the slot first and remove it last after you credit card is due to credit cards also featuring pay wave etc.

Metrocard in first to pull account details without CC interference. CC requested to perform payment transfer, CC to be removed so that balance update and confirmation can be conducted on Metrocard, without CC interference.

I see what you mean by them no longer being available, not only at ColesExpress/Shell, but no longer are the orange and black tickets on the AdMet website either.

Hopefully they won't pull a quickie and get the orange and black tickets invalid, I still have about a few more months supply of the $31.90 & less $17.50 ones left to use.

And thanks again to you all, for your feedback.

Just one last thing, (heh), my one last things never seem to stop, its a pity to see the orange and black tickets go off, they were a good gig to prebuy when prices were about to go up, ie, buy them in June to use in July & August, depending on how many are used per day/week.

Earning Flybuys as part of buying bus tickets was a good gig too...!

I do have a Metrocard, but as soon as the price rise is worked out, they can raise the fares straight on the first Sunday in July, so no more chances of prebuying to save a bit of $.

Anyways, March next year, is our chance to get rid of Jay, (I don't know if he knew what Admet/PTS were planning or doing)... he leads that party whose dept was doing it, so he has to take the blame.  

BUT changing the party will not change the people making the decisions at AdMet/PTS.

Yeah the multi trip tickets are well gone.

The cynics among us worked out the immediate price rise via Metrocard a while back. At the end of the day a few percent per trip is hardly worth getting too bothered about. One year I pre purchased $200 worth of multi trips ahead of the price rise, then I realised that I was earning nearly 10% interest on money I pulled to buy tickets to avoid a 3% ish increase in price... I never bothered after that.

I too am looking forward to what I am calling VJAY Day next March, but for different reason. I think the implementation of the Metrocard whilst some distance from perfect has been quite well done for the most part.

The problem with stocking up on multitrip tickets ahead of a price hike was that you only needed to misplace one of those tickets with a handful of trips left to make the whole effort in vain.

I think the vast majority of people who use public transport will be quite happy with Metrocard so far and the improvement it has been over the dodgy magnetic strips, those displeased will be a minority of a minority. If anything, it will probably only get a mention by Labor as something they'll point to as an example of their strength on essential public services. A fair chunk of those who aren't impressed will be due to the system not including a touch off routine with distance-based fares and discounted season tickets for regular commutes.

As for the state Liberals getting up in March, the only chance of that is if Labor get up this Saturday or if they can nicely ask Tony Abbott to not wreak too much destruction in the first six months. There is ample precedent in all states for frustrations with federal parties being taken out on their mostly decent state counterparts, and six months of bending over for Abbot would be enough to bring on a textbook example of that electoral behaviour.

That's about exactly as it is. There is no info stored on the card other than the account number (for want of a better term).

The card carries no balance information, that is held in the back end of the system somewhere. When catching PT, you wave your card, the computer pulls your account number, fare type and time, checks for funds, deducts funds, updates the balance and returns such to the validator screen.

When adding your finances to the card it is only placed on the machine to pull your account number, the balance is updated by the back end.

The reason for the 'user' recharge machines requiring you to put your metrocard in the slot first and remove it last after you credit card is due to credit cards also featuring pay wave etc.

Metrocard in first to pull account details without CC interference. CC requested to perform payment transfer, CC to be removed so that balance update and confirmation can be conducted on Metrocard, without CC interference.

I have a little experience with distributed transaction systems - but I have no knowledge of the Adelaide Metro system (beyond being a regular user)

I find it hard to believe the system doesn't store the current balance on the card.
I do know the cards are "Mifare DESFire EV1" smartcards, featuring optional AES encryption and 2, 4 or 8Kbytes of memory.

The AES encryption makes it hard to tamper with the system  - eg cards are encrypted with the Admet private key, any foreign cards wouldn't work - and 4K of memory is plenty of space to store the current balance as well as a recent transaction history (eg 1k could easily store 100 transactions or more.)
Melbourne's Myki cards use the older, less secure and slower to validate "Mifare" standard - they store the current card balance and at least the last 3 transactions.

Given the validators HAVE to work every time - assuming an undamaged card and validator -  and have to perform a validation within a second or so, and most of the validators are on moving vehicles, it's very unlikely the validators are pulling your balance from a central database somewhere, over a 3G connection. You couldn't guarantee blanket 3G coverage with sufficient speed and latency to do that with 100% reliability, under a second, every time.

Either every validator (or on-vehicle validation computer if there are multiple validators on the vehicle) has a local copy of the entire database, which is updated when the vehicle/validator is in radio contact with the backend, or - more likely - the balance is stored on the card, along with the last 10 or so transactions.

My guess is the card is the authoritative source of the "stored value" -
The recharge stations increase that value when the card is present, and store the transaction and the current card balance to update the backend database when available/in range.
The validators would reduce the card balance by the relevant fare, and store the transaction and the current card balance for database update.

So what about internet payments, or any balance increases where the card is not present?  
My guess is any internet payment transactions to a card would be uploaded to all validators and recharge stations in the network within 24 hours, so if a validator sees a card that hasn't had a specific transaction applied to it, it updates the balance and reports the transaction is now on the card back to the central database.
This would only work if the card stores the last couple of transactions - if another validator sees the card it would probably notice the transaction is already on the card, and not reapply the transaction.

Again, this is all speculation - but if it works like this, then the card would reliably validate every time, without a real-time connection from the validator to a central database.
It would mean the validators would have to talk to the database once a day at least, which is probably acceptable for a validator in a moving vehicle.

If you'd used the card, and uploaded via the Internet you'd know that your card balance is updated right away. Why? Because the balance is held in a database somewhere which is polled by the validatior when you waive your card with it's account number at the sensor. Unless your card could directly poll over 3G it could NEVER update the balance, how do we know it doesn't poll over 3G? Easy, there is no passive ability to communicate over 3G... Hence, it's impossible unless your card has a battery in it.

Does anyone really think their CC (or bank account) balance is stored on their card? Nope, the card stores your account identification in an encrypted form, nothing more, nothing less.

Sending a card number and retrieving a balance over 3G is trivial, even with a moving vehicle, it's a few bytes of information, nothing in the scheme of things when compared to voice conversations which occur day in, day out all over 3G. 3G is for (generally) at least 1 Mbps, even under a large encryption and 1/3 speed, a few dozen numbers would be transferred in nano to milli seconds, nothing like whole seconds.

Does anyone really think their CC (or bank account) balance is stored on their card? Nope, the card stores your account identification in an encrypted form, nothing more, nothing less.

I don't think this analogy is accurate - a credit card/bank card will only be used somewhere that is gauranteed to have a connection to some server - either the ATM network, EFTPOS, whatever...as payment information needs to be transmitted in real time.  Since the metrocards are stored value, as long as the delivery of each validation to the main server is guaranteed, instant verification/update is not as important.

What Fleepo and I were guessing is that since the requirement is that validators must work every time, in a matter of milliseconds, without fail, performance and reliability become issues.  Network latency could be an issue - whos 3G network is being used, and what happens when network problems start affecting performance? do we all just get free rides?

Also, like I said in my first post - if there are problems with the backend, then the more things trying to access it, the more of the system gets affected.  If it went down for say, 5 minutes at 5:00pm on a weekday - how many validations would be tried in that time? at the very least, I would suggest that if a validator loses its connection to the server, it batches up all validations to send at a point when a connection is available - which as Fleepo and I have said, suggests that the card serves as the source of truth when it comes to balances.

Does that mean that every machine stores EVERY balance for every SA card?

Or is there a server somewhere that every machine has to connect to, for every single card check?

The system has to work in areas of questionable 3G coverage, too.

Adelaide Hills routes readily come to mind.    Service at individual bus stops could be non-existant so an online validation is out of the question.

Halo - I would suggest a central server with some redundancies in the connection paths from the validators back to the server, and the data is probably stored on RAID disks, again for redundancy.

Does that mean that every machine stores EVERY balance for every SA card?

Or is there a server somewhere that every machine has to connect to, for every single card check?

With SA population of 1.65million (March 2012), if everyone had a card this info would be contained in less than 100MB of data. Update when possible to connect data service would take perhaps 2 or 3 seconds. No great struggle to keep all the info on the machines and updated balances in time for any transfers from vehicle to vehicle. Updates would only need to be done once a stop/station and would only need to be a few kB of data. Maybe every machine does have every balance stored.

My guess is that the card does have the balance and recent transactions stored as well as the central database, with the validators only holding online/phone recharges yet to be loaded onto cards and the data which they have gathered over the course of the day's work since the previous data dump back to base.

The first reason for this is the problem of what happens when a validator is 'offline' in an area with no network connection. There are spots on the Belair line where you'll see a 'comms error' message if you try to recharge using EFTPOS or a credit card on the vending machine, but the validators still work in those spots.

The second is actually the heritage of the system - it is all completely off the shelf and contains nothing innovative at all, indeed the sole reason it has worked so smoothly was that all the lessons had been learned previously. It therefore follows that it should have the card storing data just like all the other smartcard ticket systems around the world instead of something new being designed.

If you'd used the card, and uploaded via the Internet you'd know that your card balance is updated right away.

It does not work that way.

I think you will find that the card stores some info on it as if you are on a train and get your ticket checked they use a handheld instrument to check a ticket or a metrocard and if it has to retrieve all this info everytime they check a ticket or metro card it might take a bit longer to check tickets. Most single railcars are usually done in less than 5 minutes checking all tickets and metro cards. I would imagine it works the same as a ticket does it holds a certain amount of info on the card as some one said the last couple of trips or something. They are simply checking whether you have validated your ticket or metro card once on board so it must hold this info at least.

If you'd used the card, and uploaded via the Internet you'd know that your card balance is updated right away. Why? Because the balance is held in a database somewhere which is polled by the validatior when you waive your card with it's account number at the sensor. Unless your card could directly poll over 3G it could NEVER update the balance, how do we know it doesn't poll over 3G? Easy, there is no passive ability to communicate over 3G... Hence, it's impossible unless your card has a battery in it.

Does anyone really think their CC (or bank account) balance is stored on their card? Nope, the card stores your account identification in an encrypted form, nothing more, nothing less.

Sending a card number and retrieving a balance over 3G is trivial, even with a moving vehicle, it's a few bytes of information, nothing in the scheme of things when compared to voice conversations which occur day in, day out all over 3G. 3G is for (generally) at least 1 Mbps, even under a large encryption and 1/3 speed, a few dozen numbers would be transferred in nano to milli seconds, nothing like whole seconds.

Hi Aaron, yes, I was an early adopter of the card - and I've added credit via the internet. In my experience (as it says on the admet website) it's not instant - in my experience the additional credit wasn't available until the next day.  
Of course the card doesn't work over 3g - the cards are powered by the field generated by the validator. (the chip has enough computing power to decrypt the storage and present it to the validator.)  

You're correct, credit cards just have the card no and some other info - no balance. But when you do a credit or debit card transaction it takes seconds  - even with a 3g-enabled credit card terminal -  to check the balance of your card with your bank. That's just not fast enough for a transit validator - and there's no guarantee you have a 3g connection at, say kudla or in the belair tunnels (or in the Adelaide railway station, for that matter.)

So, the card and the validator have to be able to work without talking to a backend somewhere.
As you say, I'm sure the validators are in regular contact with the back end system during the day - but there's no guarantee of this.

Were I designing such a system my thoughts would be along the following lines:

The central system server needs to record against the card number

• User details
• Transaction list including
•   time of validation

•   place of validation
•   service where validated
•   amount deducted
• Account Balance

The card needs to store very little information:

• Card / Account Number
• Card type
• Balance
• Time last validated
• Service where last validated.

The latter two are for policing the use of the card by field inspectors.

The validator needs to

• check the card balance (to determine whether to accept or fail the transaction)
• determine the time and vehicle for the last validation (to ensure the card isn't being used twice for the same service)
• debit the card with the appropriate fare
• record the date and service on the card
• record the new balance on the card
• record the account number in a log
• record the date and service in the log against that account number
• record the new balance in the log against that account number
• communicate with the central server from time to time and upload its log to the server (note that this could be once a day in the depot or when ever there is a crew change)

I would be very worried about communications problems and probably not opt for real-time interaction between validators and servers.

Were I designing such a system my thoughts would be along the following lines:

The central system server needs to record against the card number

• User details
• Transaction list including
•   time of validation

•   place of validation
•   service where validated
•   amount deducted
• Account Balance

The card needs to store very little information:

• Card / Account Number
• Card type
• Balance
• Time last validated
• Service where last validated.

The latter two are for policing the use of the card by field inspectors.

The validator needs to

• check the card balance (to determine whether to accept or fail the transaction)
• determine the time and vehicle for the last validation (to ensure the card isn't being used twice for the same service)
• debit the card with the appropriate fare
• record the date and service on the card
• record the new balance on the card
• record the account number in a log
• record the date and service in the log against that account number
• record the new balance in the log against that account number
• communicate with the central server from time to time and upload its log to the server (note that this could be once a day in the depot or when ever there is a crew change)

I would be very worried about communications problems and probably not opt for real-time interaction between validators and servers.

Yep, that's pretty much how I'd do it too.

Because the information on the cards is encrypted, you can't tamper with the balance (or any other data) on the card - so the cards could be the "trusted" source of information - only equipment that's part of the system, like the validators and payment kiosks could decrypt the card and alter it's details. That's why you can't use a Myki card on the Adelaide system and vice versa.

The only addition to kipioneer's system I'd make would be to handle internet or phone payments -
When you make an internet payment your card balance is updated by a validator up to 24 hours later (a second light lights up on the validator when this happens).
I assume all validators would be regularly updated with a list of recent internet/phone payments, so they can update any presented cards appropriately.
You'd need a way to prevent the payment being applied by a second validator - so my guess is the internet payment transaction is stored on the card - if another validator sees that transaction ID is already on the card, it won't reapply it.

If you trust the card as the authoritative information source, then the validators / payment terminals only need to talk to the back end server one a day at the least, to dump validator transactions and get updated internet payment lists, etc.

This would reduce the system implementation costs as you could put wireless transmitters in spots your vehicles frequent, eg major stations, large bus terminals, depots, etc so the validators only communicate with the back end system when the vehicle is at at these locations, rather than needing blanket radio coverage across Adelaide. Eg, perhaps every train talks to the back-end when it's in Adelaide station only or when stabled, and buses/trams in Glenelg/Victoria square/Grenfell St/Marion/Noarlunga/TTP/West Lakes/bus depots. That's probably frequent enough!

Again I have no knowledge about how the MetroCard system actually works - this is all just a guess.

I think those guesses are pretty much correct, based on the higher level of detail known about some other systems such as Oyster (thanks to Freedom of Information working better in the UK) and this coming along more recently.

In my opinion the best time to upload a data dump from a vehicle would be when it is laid over at the end of a passenger service, and do it using just an encrypted signal over the commercial network from Telstra or whoever else won the tender if they could guarantee coverage at all route termini. For rail and tram it could be done over GSM-R if we adopt that standard as part of a shift to non-signal rail traffic control in the future.

If I was in charge I would also add the following points to that which has been listed above.

1. start working with my counterparts in the other four state capitals using smartcard ticketing to develop a second-generation card which would work on each system, using the same money balance with the appropriate local fare rules.

2. work with the three universities and DECS to get Metrocards embedded in student ID cards just like Seniors Card holders have.

3. take a leaf from the Oyster system and introduce a daily price cap that would allow unlimited travel while capping the amount payable in a single day at the price of a daytrip ticket.

4. add a "plus bike" button to the touch screens on trains to allow an additional concession fare to be purchased on the same Metrocard instead of forcing cyclists and surfers to use an extra concession Metrocard or a single ticket.

The card needs to store very little information:

• Card / Account Number
• Card type
• Balance
• Time last validated
• Service where last validated.

The latter two are for policing the use of the card by field inspectors.

These are also necessary for the use of our timed ticketing system which includes transfers. If and when we switch to a flagfall+distance system they would continue to be necessary to allow journeys including transfers.