Told off for trying to buy a ticket

[34D]

Since not all points where one might need to show a ticket have access to the internet, it makes it hard to verify that the ticket hasn't been used yesterday/twice/etc.

Existing e-tickets mostly avoid this by being valid on only one service, preventing reuse.

I see guards having a reader (which could well be a mobile phone) which scans tickets either using NFC to an itso card, or aztec code/qr scanned with the camera.

Periodically (either over 3g or over WiFi perhaps at each station) data is uploaded to a central server, specifically transmitting the pair of calling points in between which a ticket was checked.

Station barriers would be wired to the system all the time, obviously.

Given that hundreds of megs of data can be transferred within seconds now, a list of tickets started and completed could be transferred in reverse.

I suppose I'm saying that each ticket (whether paper, card or itso) has a unique number, and that it has the following states:

-not commenced
-started (denoted by an entry touch or the first grip, or an exit touch at an intermediate station)
-completed (either time expired, or an exit touch at the final possible station).

Am I talking complete rubbish?

 

[najaB]

Am I talking complete rubbish?

No. You've described a pretty simple, and potentially quite robust eTicketing system. A couple of points to note:

Realistically you're going to be talking 10's (if that) of megabits per second on 3G/LTE for the foreseeable future. So transmitting entire databases is probably out of the question.

The issue comes when there is a 'hit' on the database for a possible duplicate/counterfeit ticket number. If it occurs on the initial scan, not a problem the guard can deal with it there and then. What happens when there isn't a realtime connection and the 'hit' occurs later? Will the guard remember who it was that gave the invalid ticket? The reader could remember seat numbers, but the passenger could just move. Also, unless we have 100% barriers the passenger can just leave at an unbarriered station.

That's why I said that it's not a one size fits all solution - I can see eTickets working on routes that have a high-proportion of booked seat travel, and barriers at all stations.

 

[34D]

I suppose I'm saying that each ticket (whether paper, card or itso) has a unique number, and that it has the following states:

-not commenced
-started (denoted by an entry touch or the first grip, or an exit touch at an intermediate station)
-completed (either time expired, or an exit touch at the final possible station).

Am I talking complete rubbish?

Let me change this:

Entry/exit barriers either put a log on the ITSO card or encode a mag strip or put ink onto a piece of paper.

States are therefore:
-not commenced (applicable only at an unstaffed unmachined station)
-started (denoted by an entry touch or the first grip, or an exit touch at an intermediate station)
-definitely not valid (an advance on wrong train, or a ticket where sufficient logs are available to say beyond doubt that that bit of the journey has already been done)
-completed (either time expired, or an exit touch at the final possible station).

 

[Steveoh]

No

The issue comes when there is a 'hit' on the database for a possible duplicate/counterfeit ticket number. If it occurs on the initial scan, not a problem the guard can deal with it there and then. What happens when there isn't a realtime connection and the 'hit' occurs later? Will the guard remember who it was that gave the invalid ticket? The reader could remember seat numbers, but the passenger could just move. Also, unless we have 100% barriers the passenger can just leave at an unbarriered station.

Is it an issue? Surely there's a purchasing history with the ticket linked to the bank account. There would be an audit trail of who made the purchase.

 

[najaB]

There would be an audit trail of who made the purchase.

The person making the purchase isn't necessarily the person making the journey.

 

[island]

The person making the purchase isn't necessarily the person making the journey.

That, and it is non-trivial to obtain information about the cardholder from the card issuer.

 

[Steveoh]

That, and it is non-trivial to obtain information about the cardholder from the card issuer.

But not insurmountable surely? I'm not talking about this all being done in real time. It could be investigated later. If you're providing the account to buy the ticket you have an interest in it being used properly.

 

[takke]

I doubt that is true. Print-at-home issued in Germany, the Netherlands, Belgium and probably elsewhere are often "open" tickets valid on multiple trains.
Further measures could be taken to increase the chances of detection, even in these circumstances. When a connection is available, a list of used ticket numbers for tickets valid on that day could be downloaded by the inspectors' equipment. This would allow detection of a further significant proportion of reuse. The window available to use a ticket multiple times would become small - the time needed for a connection to become available and the data to be uploaded and downloaded again.

As I understand it, this is essentially the same as the system used on Oyster for lost Oyster cards or contactless payment cards which have an outstanding debt. The ticket barriers/buses are sent a list of barred cards daily and those cards are not allowed to be used. A similar approach could certainly work. As you say, nothing is perfect, but once you get to the point that you need to be travelling twice on the same journey in the same day to fare-evade, or have an accomplice travelling on the same train, it becomes too much effort for most people.

 

[34D]

or have an accomplice travelling on the same train

A simple 'passback' function on the local machine would cover this off.