...
With an implementation based on the BoB specifications, the prerequisites are created for establishing an interoperable solution. But there is also a need for an agreement to be entered between interacting parties including business rules, clearing mechanisms, etc. in order to build a comprehensive solution that is interoperable.
Mobile Ticket Specifications (MTS)
The Mobile Ticket Specifications (MTS) describes the different components you need in your ticketing system to achieve interoperability according to the goals in the BoB-standard. They contains how to build a ticket (Mobile Ticket Bundle, MTB) so that it can be read, interpreted and validated mechanically. The Specifications enable the possibility to read and interpret tickets created in both your own system as well as tickets from other systems. The specifications also make it possible to have several suppliers in the same “system domain”. For example, it is possible to, within the same system, have several sales channels delivered by different suppliers.
...
Find and read more about the MTSs here.
Application Programming Interface (API)
APIs have been developed to describe how systems and system components exchange information between each other. The API with a number of endpoints cover the entire chain from where a sales system asks the cost of a ticket to how a ticket is validated. Even repurchase and other customer-related transactions can be carried out via these APIs.
...
Find and read more about the APIs here.
Schemas
A number of schema files and translation tables are also included which describe in detail how objects and data content are to be formatted. The translation tables contain, among other things, a common definition of how data fields can be abbreviated so that the size of MTB can be kept down. You can find the schemas in the MTSs.
...
BoB Tickets
...
Tickets are named Mobile Ticket Bundle (MTB) in the BoB standard. You can issue a ticket from only one participant or you can build tickets that combine tickets from several participants (you collect tickets from different participants ticket engines and bundle them together so that the customer perceives them as one ticket for the whole journey. Combined tickets requires that the fares, some of the business rules and the geography are coordinated between the participants. However, the product range and prices have no direct connection, so these can be set individually.
To make validation easy the ticket is divided into boxes. The validator finds the right box by the Participant Identifier (PID). Off course this is not how the ticket actually looks like. Read more about electronic tickets here.
...
BoB In Reality
Let’s go through some practical examples to make this less theoretical.
...
In this case the customer uses an app to search a ticket for the planned journey. The Sales Channel sends a request to the Price and Product in a Ticketing System and asks for suggestions. The Ticketing System finds two tickets that matches the journey in question. Sends over a manifest containing the information about the tickets. The app indicates those tickets that are possible to purchase based on the filtering options selected by the traveller from the Sales Channel app.
...
Buy ticket
The customer chooses one of the tickets that are offered and payment is made via the connection of the Sales Channel with the Payment Service Provider. An order is then sent to the Ticket Engine where the ticket information with its safety content is generated and returned to the app. This generates an Aztec code that contains the ticket information. A transaction is now created in the database linked to the Ticket Engine.
...
Validate ticket
The Aztec code that is shown in the App is displayed to a reader that translates the information in the code into a format that can be interpreted by the Validation Service. The ticket information that is obtained is then compared with the current time, place, etc. in order to check whether or not the ticket is valid, which is indicated to the customer. Information on the valid or invalid ticket is transferred to the transaction database in the Ticket Engine. Analysis tools can now collect information in order to create statistics, settlements, reports, etc.
...