Tickets

The provider feature tickets allows users to purchase public transport tickets directly in ioki Passenger App and ioki Web Booking.

In contrast to the first implementation of ticketing, the ioki ticketing API now stands as a standalone feature, independent of ride creation and booking processes. While the option remains to link tickets with rides for seamless integration, ticketing operates as an entirely independent feature. Clients can develop applications solely dedicated to ticket purchase and management, with the ticket wallet serving as a primary entity within passenger clients.

Use cases of this feature

If a provider’s rides require a public transport ticket, this feature enhances the user experience by enabling in-app ticket sales. This eliminates the need for users to switch to a separate app to purchase public transport tickets.

Activate this feature

Roles: Super Admin

  1. Navigate to the management settings of the provider.
  2. Within the Provider features section, select the checkbox Tickets.
  3. Select Save.

Further configuration and development effort is necessary to enable this functionality. The setup has to be done by a platform developer.

Configure this feature

In the management settings of the provider, select the ticketing product index adapter name. In the tenant settings of the provider, it is possible to define an explanation test for ticketing.

Understanding physical and digital tickets

For those new to the realm of ticketing, grasping the legal and technical intricacies is crucial. Let’s challenge conventional notions of what constitutes a ticket.

Fundamentally, a transportation ticket represents a legal entitlement. Holding this entitlement grants the bearer the right to claim the transportation service, governed by the terms of service outlined in the ticket’s contract. It is important to recognize that the entity selling the ticket may differ from the one providing the service, and further still from the entity technically issuing the ticket.

Validation

Traditionally, non-digital tickets undergo a validation process (known as “Entwertung” in German), where a physical action like punching a hole or tearing the ticket indicates its consumption, preventing reuse for multiple claims of service. Nowadays, many paper tickets are validated simply by printing or writing the date and time of the ride on them. Upon purchase, you acquire the entitlement to transportation; by marking the ticket with the date, it becomes valid and eventually expires. At train stations, ticket vending machines often dispense pre-validated tickets, already imprinted with a timestamp, ready for immediate use.

Personalization

Additionally, the concept of personalized tickets aims to prevent unauthorized transfer by requiring varying levels of personal information, from full names to birthdates or gender information.

Most physical ticket machines at train stations issue unpersonalized but pre-validated tickets, making them transferable in practice, though adherence to terms of service regarding transferability isn’t always apparent from the ticket itself. Despite lacking personal data, the inclusion of date and time information validates the ticket and makes sure that it expires some time soon.

Rendering of digital tickets

Digital tickets have the same processes, but on top they often have an additional mechanisms regarding storage and rendering / visualization. Some vendors might try to put technical constraints on the process, like where the ticket data is allowed be be stored (e.g. only on one device), how it is retrieved and rendered (encrypted at rest, maybe with an SDK showing some dynamic / moving elements to prevent simply screenshots), how it is obtained (e.g. the ticket may already be “pre-validated”, but can not get fetched prematurely via API or may get fetched but not get fully rendered until the time has come). There might also be some sort of revocation mechanism in place.

The admin procedure for this feature is documented in Tickets in Control Center.