Minor updates and code changes occur every day. Only significant or noteworthy updates are shown here. Updates shown with a gold background are (or were at the time) only available to Advanced HOPS members.

You are NOT currently subscribed to HOPS compliance system updates. More info

You are NOT currently subscribed to HOPS retail system updates. More info

Search: Clear

Time Date	System Updates
Update 1364 31 December 2025	Ticket Email QR Scanning Updates The process around scanning QR codes to confirm validity has been overhauled. Note this only applies to scanning QR codes on emails by ticket inspectors, not scanning on the POS in order to recall an order / print tickets, which is unchanged. Part of the objective here is to increase ticket security, as requested by several clients, while maintaining the ability to process queues quickly. PERMISSIONS Ticket QR codes can now only be scanned by logged-in users. Previously anyone could scan a code. While there was no personal information shown, limiting the scan to logged-in users both reduces the ability for 'everyone' to see what the resultant page looks like, and also means all scans are 'official' scans, rather than the customer scanning it speculatively. LAYOUT The layout has been changed to group together tickets for the same event. Eg instead of showing: Sunday Lunch - Adult - 12:30 - 15:00 - Thursday 1 January 2026 - DATE OK Sunday Lunch - Child x2 - 12:30 - 15:00 - Thursday 1 January 2026 - DATE OK Sunday Lunch - Senior - 12:30 - 15:00 - Thursday 1 January 2026 - DATE OK Sunday Lunch - Dog - 12:30 - 15:00 - Thursday 1 January 2026 - DATE OK It now shows: Sunday Lunch - 12:30 - 15:00 - Thursday 1 January 2026 - DATE OK - Adult - Child x2 - Senior - Dog We hope this is more intuitive. Both the quantity of tickets and the number of seats is shown. For 'travel' it is not as easy to group tickets together (as there are so many fine details), but effort has been made to make it as quickly-readable as possible. ITEMS SHOWN Only event tickets and travels tickets are now shown. Seat reservations are not shown as lines in their own right - the seat reservation information is shown in the row for the ticket it applies to. Other items such as vouchers and stock products are not shown. TICKET DELIVERY The page also now highlights if the ticket is not an e-ticket. It is envisaged that the QR scanning method of checking tickets is only used for e-tickets. It works for all methods of ticket fulfilment, but non e-tickets are highlighted. TICKET FRAUD - PREVIOUS SCANS All previous scans are now shown. If the order or items have ANY previous scans [by logged-in users*] an orange banner will be shown at the top of the page. The ticket inspector can then examine the tables of previous scans to determine the situation. This does require some interpretation, eg as a user may have purchased tickets for two events in the same order: The order will have been scanned when they attended the first event, then on attending the second event the ticket inspector will see 'Already Scanned', but examination of the detail will reveal that this is a legitimate case. * - Although it is now only possible for a logged-in user to scan tickets, many previous scans were conducted by non-logged-in users. Only scans by logged-in staff are considered here. ORDER SCANS VS ITEM SCANS Note that it is possible to scan an ORDER confirmation email, or an ITEM details email ("Additional" email). 'Additional' emails can be configured in the ticket system settings for items that require a great deal of additional information, eg a Driver Experience might have many paragraphs of 'things to bring' and 'what to expect' etc. The scan page has tables for scans on the ORDER and scans on each ITEM, to give the maximum detail to the inspector if they are trying to resolve the circumstances and determine whether a customer is legitimate. It isn't possible to predict whether the customer will present their ORDER qr code or their ITEM qr code, so both must be considered. INTERPRETATION It is up to individual clients to determine a policy on interpretation of the scanning data. Eg if you know that you only ever scan customers once at your one-and-only entry gate to an event then you can be pretty sure that if someone has already been scanned then they are trying to get two people in on the same email. Whereas if you have several entry points, or are scanning tickets several times during the day then it might be entirely reasonable that a person is scanned more than once, so the examiner will interpret the data shown to determine whether the pattern is reasonable. TICKET FRAUD - FURTHER CONSIDERATIONS In addition to the risk of two visitors trying to gain access on the strength of the same email, an additional risk has been identified: It would be easy for a user to save a copy of the HOPS 'ticket valid' page onto their own site, and present the ticket inspector with a QR code to that site instead of the real QR code which leads to HOPS. To mitigate this, two additional items have been added to the page: - The name of the logged-in ticket inspector is shown at the top of the scanning page. A ticket inspector should expect to see their own name there every time. A visitor trying to defraud the company would need to know the name of the inspector in order to fake this. - A 'Code Word' has been added. This can be set in Ticket System Settings in HOPS. If set, it is shown after the name of the ticket inspector of the scanning page. A ticket inspector should expect to see same code word every time. Eg the code word of today could be 'CHOCOLATE', and then this would show on every scan. A visitor trying to defraud the company would need to find out the code word in order to fake this. The code word can be set/changed whenever required. This system is used by some 'main line' bus and tram operators. While neither of these are 100% fool-proof, they both introduce a further level of difficulty for a person attempting to illegitimately use a QR code. Like all systems, it can almost never be 100%, it just needs to be more hassle than it's worth for a bad actor. FUTURE It is our plan to further develop this facility to include a camera view on the page, to avoid the need to return to the native camera app after each customer. It is also intended to allow the user to state their role, so that further interpretation of the data can be made. Eg a Guard could state their role as '1030 Padd-Oxford' or '1D22' (to use a main line example) when they are operating that train, and then '1300 Oxford-Padd' on the way back. This would enable easy distinction between a passenger being scanned on their outward and return journey. When being scanned on the way back, the system would show 'Already Scanned', but the guard would see the first scan was on the 1030 Padd-Oxford, so the passenger is obviously now on their return journey. Whereas if they look at the first scan and find it's on the 0700 Oxford-Padd then it is possible the passenger is trying to make a second journey on the same ticket. Another example could be events where the visitor is allowed access to several attractions - eg 'Your day ticket includes a one brake van ride, one trip on the miniature railway, and one session on the ice rink'. If this were to be strictly access controlled, the ticket inspectors at each location could state their role as 'BV', 'Mini Railway', and 'Ice Rink' - it would then be possible to control the 'Already Scanned' alert to 'Already Scanned at this part of the event'. We will be interested to hear feedback from users on if/how useful this would be.
Update 1030 26 January 2024	Attaching files to HOPS Comms messages is now back. Permission 508 required. Please use it sparingly (eg only to managers), so that a - it doesn't fill up the HOPS server b - users don't use it for things that should really be files uploaded to the documents area of HOPS (eg WONs etc). We don't guarantee it will be available forever if it becomes too expensive. Thank you Danny S.