The Ticket Ticketing and Payment Standard BoB (Biljett- och Betalstandard) was developed by Samtrafiken i in cooperation with the Samtrafiken’s owners. The goal was to create a an open module based architecture and possibility create possibilities for interoperability between different ticket ticketing systems and sales clients. Another goal was to move towards a more uniform way for the traveler to manage managing machine-readable mobile tickets, which also includes combination tickets, meaning a traveler should be able . The standard also makes it possible to combine several tickets into one. This would enable a traveller to present a travel document containing multiple tickets from different transport companies.
...
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 ticketing system.
With an implementation based on the BoB specifications, the prerequisites are created for establishing an interoperable solution but one in which . But there is also a need for an agreement to be entered between the 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 Specifikations Specifications (MTS) describes the different components you need in your ticket ticketing system to achive achieve interoperability according to the standars goalthe 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 machanicallymechanically. The Specifications enable the possibility to read and interpret tickets created in both your own system as well as in others’ 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 solution to , have several sales channels delivered by different suppliers.
...
Describes how one or multiple tickets should be bundled and signed in a secure way (the structure of an MTB).
Describes how you conect connect 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) chip should work in an ID based system.
Describes the format of how to express time and date.
...
Application Programming Interface (API)
APIs have been developed that 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 the these 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, authenticates (allows) equipment and units to communicate with each other in accordance with clearly specified rules (Authentication + Authorisation)
Product, the Product Interface Interfaces to Price and Product Service, the product that delivers Services, they deliver 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, interface for modules with passenger accountinformation.
Booking, used for reserving and booking of demand responsive traveltravels.
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”
...
Tickets are named Mobile Ticket Bundle (MTB) in the BoB standard. You can issue a ticket with from only one participant and or you can issue build tickets that combine tickets from several participants . You (you collect tickets from the different participants ticket engines and bundle them together so that the customer get the feeling of having perceives them as one ticket for the whole journey. One ticket to keep track of the time limit, one ticket to validate. Combine 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.
...
BoB In Reality
Let’s go through some practical examples from reality to make this less theoretical.
...
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 the database linked to the Ticket Engine.
...