The Ticket and Payment Standard BoB was developed by Samtrafiken i cooperation with the owners. The goal was to create a module based architecture and possibility for interoperability between different ticket systems. Another goal was to move towards a more uniform way for the traveler to manage machine-readable mobile tickets, which also includes combination tickets, meaning a traveler should be able to present a travel document containing multiple tickets from different transport companies.
The standard has a module based approach. The traditional ticketing system is broken down into individual modules that should work independently as described in the architectural picture below. The standard describes how to create a ticket so that it can be searched, sold, read, interpreted, validated digitally, repurchased and blocked. It describes how the communication is supposed to work between the various services in the architecture and how you do all this in a secure way. It does not explain exactly how you should build your services. It is done this way so that you can keep your business rules, your fare system, your customized app for selling tickets and your way of handling reporting.
Read more about the architecture here.
The BoB Standard contains of three parts:
Mobile Ticket Specifikations (MTS)
Application Programming Interface (API)
Schemas
The MTS's, API's and Schemas together with the architecture formulates the basis, components and interfaces, for a participant to build their own BoB-compliant ticket system.
With an implementation based on the BoB specifications, the prerequisites are created for establishing an interoperable solution but one in which there is also a need for an agreement to be entered between the parties, business rules, clearing, etc. in order to build a comprehensive solution that is interoperable.
Mobile Ticket Specifikations (MTS)
The Mobile Ticket Specifikations (MTS) describes the different components you need in your ticket system to achive interoperability according to the standars goal. They contains how to build a ticket (Mobile Ticket Bundle, MTB) so that it can be read, interpreted and validated machanically. The Specifications enable the possibility to read and interpret tickets created in both your own system as well as in others’ systems. The specifications also make it possible to have several suppliers in the same “system domain”. For example, it is possible within the same system solution to have several sales channels delivered by different suppliers.
There are 8 MTSs:
Describes how one or multiple tickets should be bundled and signed in a secure way (the structure of an MTB).
Describes how you conect the ticket and the carrier in a secure way.
Describes how to structure the ticket information (the content of the MTB).
Describes coordination and key management between participants and the administrative body (Samtrafiken).
Describes how you should do to identify yourself.
Describes the language, Tickle, that is used to express ticket validity and how to keep the size of the ticket down.
Describes how a card (or other carrier) should work in an ID based system.
Describes the format of how to express time and date.
Find and read more about the MTSs here.
Application Programming Interface (API)
APIs have been developed that 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 the APIs.
Exactly which endpoints to use depends on how the cooperation between the different parties is intended to work. As a lowest common denominator however you need to be able to handle:
Authentication
Product
Ticket
ParticipantMetadata
Device
Validation
API endpoints are described briefly below:
Authentication, authenticates (allows) equipment and units to communicate with each other in accordance with clearly specified rules (Authentication + Authorisation)
Product, the Product Interface to Price and Product Service, the product that delivers information on available products and prices to the Sales Channels
Ticket, the Ticket Interface for “Ticketing Service”, the service that receives orders for tickets and creates an MTB with information and guarantees the validity by means of electronic signatures.
ParticipantMetadata, the interface for processing and updating the central information at AB.
Device, provides KDK and device key for copying protection. Device Signature
Validation, "Validation Service" back end interface that a validation device uses to submit completed validations or if validation takes place online where the actual validation is made.
Inspection, equivalent to Validation but for inspection equipment.
Traveller, passenger account.
Booking, used for reserving and booking of demand responsive travel.
Token, used for registration of tokens and to tie them to tickets for ID-based travel.
Account*, reserved for future use.
*Initial idea: account management functions for ID-based Travel.
Resource**, reserved for future use.
**Initial idea: seat booking component in Price and Product Service”
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 with only one participant and you can issue tickets that combine several participants. You collect tickets from the different participants ticket engines and bundle them together so that the customer get the feeling of having one ticket for the whole journey. One ticket to keep track of the time limit, one ticket to validate. Combine 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 examples from reality to make this less theoretical.
Search a ticket
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.
