QR Code Ticketing Standard

Overview

QR code (Quick Response Code) is a two-dimensional barcode that is used in the beep AFCS as medium for ticket creation and validation. Due to its flexibility and simplicity, QR codes can be applied to paper-based tickets as well mobile phone based ticket. Of course, QR codes are not “interactive” like contactless chip cards (such as the beep™ card), which means that additional steps are necessary to make a QR ticket transaction secure.

QR Ticketing

QR Ticketing refers to the creation, entry-validation, inspection and exit-validation of QR code based tickets. There are many ways to implement QR Ticketing, and we are constantly adding new functionality to our own solution. Currently our QR Code ticketing solution is comprised of a QR Issuance or ticket selling terminal and a QR Validator or ticket acceptance (i.e. validation) terminal. The QR Issuance terminal is used in selling the QR tickets. It supports fixed fare, multi-fare and discounted fare ticket types. This can be deployed at the

  1. ticket booth for use by the tellers,
  2. as unattended terminal for self-service use by commuters, and
  3. for ticket issuance on-board the transport vehicle – such as bus, PUV or Jeepney, e-trikes and ferries.

The QR Validation terminal is usually installed at the entry to the paid area (such as waiting area or platform), in front of the vehicle or within the vehicle. QR Validator terminals may validate QR tickets for boarding or for alighting passengers or both.

These QR Tickets will also be available as dynamic code for purchase and issuance with Smartphone applications, as well as from online booking and reservation systems.

QR Payment

QR Payment refers to the use of QR codes to initiate a payment transaction. In most cases QR payments are combined with QR ticketing to add validation, inspection capabilities and to add the necessary fare related data. The QR codes and systems used for QR payment are different and out of scope of the QCAT Ticketing Standard.

In addition to cash and beep™ cards, in the AFPI system, we now offer cashless payment via mobile phone based QR codes from GCash and we are working on adding the same functionality from other eWallet providers in the market.

The basic flow of QR payment using an eWallet includes the following steps:

  1. After selection of fare and ticket type, the passenger presents a customer generated QR with a Smartphone and scans it on the beep Issuance terminal for fare payment and purchase of a ticket.
  2. On payment approval by the mWallet gateway, a QR ticket is issued to the passenger.
  3. Once the QR Ticket is sold and issued to a passenger, it is then scanned with a QR validator for access to a paid area at the transport terminal or on boarding a vehicle.

The beep QR ecosystem

QCAT Ticket Issuer

An entity who enters into a contract with a potential or current passenger, issues QR tickets to the passenger, collects the ticket price from the passenger and settles the ticket price with the QCAT Ticket Acceptor.

QCAT Ticket Acceptor

An entity who operates a system that is capable of validating tickets and that settles the ticket price with the respective Transport Operator and the QCAT Ticket Issuer.

QCAT Ticket Creator

An entity authorized by the QCAT Ticket Issuer to generate and/or sell QCAT tickets. The liability for the settlement of ticket prices remains with the QCAT Ticket Issuer. The QCAT Registrar may issue a limited number of additional participant IDs to the QCAT Ticket Issuer to support the allocation of funds between QCAT Ticket Issuer and its QCAT Ticket Creators.

Passenger

A person buying and using a ticket for the purpose of using the services of a Public Transport Operator.

Public Transport Operator

An entity offering person transport services to the public (including defined groups such as residence of a housing estate or an industrial park)

QCAT Certificate Authority

An entity signing the Public Keys of QCAT Ticket Issuers, distributing the certificates to QCAT Acceptors and distribute certificate revocation lists to QCAT Acceptors

QCAT Registrar

An entity that maintenance a registry of reserved identifiers for use in QCAT tickets. Examples of reserved identifiers include Ticket Issuer Identifiers and Default Ticket Type Identifiers (e.g. Senior Citizen Ticket Type).

The specification is publicly available and free to use but requires a license agreement for
commercial and non-commercial purposes. Our aim is to make the QR Ticketing specifications as
freely available as possible without jeopardising interoperability (see below for an explanation of what Interoperability means the QCAT Ecosystem). The license to study the standard is available
on the QCAT Github repository.

Our license agreement would be based under the following principles:

  • software and applications using the ticketing standard carry this license language and use the
    term “QCAT QR Ticketing Standard” to refer to the standard.
  • the licensee does not use the standard to implement a proprietary, non-interoperable ticketing
    system, and
  • the licensee will use the AFPI QR Ticketing Signature Authority to generate certificates to be
    used in ticket validation terminals
  • the licensee does not offer or sell any product, system or solution that is based on the QCAT
    specification and the IP encapsulated in the QCAT specification to parties who have not accepted
    the QCAT specification license

What does Interoperability in the QCAT Ecosystem mean?

Interoperability means that all genuine tickets generated by participating QCAT Ticket Issuers will
be accepted in all QCAT validation terminals of all participating QCAT Acceptors.

Technically, interoperability is assured through

  • cryptographic signatures and a common QCAT Certificate Authority.
  • common identifiers managed by the QCAT Registrar
  • common standards for the content and encoding of data in the QCAT QR code

Commercially, QCAT Ticket Issuers and QCAT Acceptors must enter into commercial contracts
to ensure that the QCAT Acceptors get paid for all correctly accepted QCAT Tickets.

Operationally, interoperability is assured by common dispute resolution principles that define what “correctly accepted” means and who is liable for the value of an accepted ticket.

  • AFPI owns, licenses and manages the QCAT specification.
  • AFPI operates the QCAT Certificate Authority that signs QCAT Issuer signature keys and distributes public key certificates to QCAT Ticket Acceptors in the QR Ticketing Ecosystem.
  • AFPI operates the QCAT Registrar for participants IDs of issuers of QCAT tickets and other identifiers used in QCAT tickets
  • AFPI operates as a QCAT Ticket Issuer, QCAT ticket creator and QCAT Ticket Acceptor

QR Code Standards and Tools

The QCAT Standard and supporting documents are publicly available in a Github repository. On Github you can download the documents, see the revision history, make comments, suggest changes and even submit changes you have made yourself for inclusion in the standard. If you would like to do anything but viewing the documents, you must create an account which is free of charge. We will be more likely to respond to messages on Github if the account has a the full name, organisation and a picture.

FAQs

  • What is the QCAT Standard?

    The QCAT standard is a set of specification and documents that define a QR code based ticketing system for automated fare collection in public transport.

    The main part of the QCAT Standard is the QR code specification, which defines the content and format of the QR code payload of a ticket.

  • What is the QCAT Ecosystem

    The QCAT Ecosystem describes the technical, operational and legal framework and practice of an interoperable QR code based ticketing system in public transport.

  • What does QCAT stand for?

    QCAT stands for QR Code Acceptance in Transport.

  • How does the beep™ system relate to QCAT?

    beep™ cards use a different technology (NFC) and are not compatible with the QCAT standard. However, AFPI’s objective is for all acceptance systems to work with both beep™ cards and QCAT tickets.

  • How can my company participate in the QR Ticketing Ecosystem?

    QCAT Ticket Issuer

    Any organization willing to accept the terms of the QCAT License and that enters into commercial agreements with QCAT Acceptors may issue QR Tickets that are accepted in the QCAT Validation terminals of the QCAT Acceptors.

    Equipment Vendors

    Any company that develops software, hardware, systems or provides system integration services may use the QCAT specification to build compliant systems.

    QCAT Ticket Acceptor

    Any company that provides automated fare collection systems and/or services may use the specification to accept QCAT compliant tickets as long as the QCAT Ticket Acceptor accepts the terms of the QCAT license and enters into commercial agreements with QCAT Ticket Issuers.

    Transport Operators

    Any transport operator may participate as QCAT Ticket Acceptors and QCAT Ticket Issuers.

  • What do I need to do to become a participant in the QCAT Ecosystem?

    Using the QCAT specification to develop solutions and systems does not require any further agreement with AFPI.

    In order to use the QCAT based system in production, the QCAT Ticket Issuer or the QCAT Ticket Acceptor must enter into an agreement with AFPI that will govern the use of the QCAT Certificate Authority and the QCAT Registrar.

    If you would like your QCAT tickets to be accepted in validation and inspection terminals managed and/or operated by other participants in the QCAT Ecosystem, or if you would like to accept QCAT tickets generated by by other QCAT Ticket Issuers participating in the QCAT Ecosystem , contact AFPI for a QCAT License and Ticket Issuance and Acceptance Agreement.

  • What is the difference between QR Code Ticketing and QR Code Payment?

    In Automated Fare Collection, payment and ticketing are two distinct processes.

    The ticket is used with ticket validator terminals that validate a ticket on entry and/or exit or during an inspection.

    A ticket contains information for the validator or inspection terminal to decide whether the ticket holder is allowed to enter the vehicle or whether the ticket holder has paid the correct fare for the exit stop.

    Payment on the other hand is the process to pay for the ticket. The payment can be done using one of multiple payment instruments such as cash, eWallet, store value card and so forth.

    There are pre-paid tickets that have been paid for before the passenger starts their journey and post-paid tickets that are paid for after the passenger has left the public transport vehicle.

  • What is the Pre-paid QR Ticket Use Case?

    The use case for pre-paid tickets is defined as follows:

    • Prepaid QR Code tickets can be printed on paper or generated and displayed on the phone
    • The passenger pays for the ticket before starting the journey. There are many possible payment scenarios, such as
      • The passenger uses an application to generate a prepaid QR code ticket on the phone. The payment can be done through an electronic payment transaction from e-Wallets, bank accounts or card transactions
      • The passenger presents a QR code generated by an e-Wallet provider or a bank to a special unattended terminal, which will use the QR code to seek authorization for the fare amount and then prints a pre-paid ticket.
      • The passenger uses cash to buy a paper ticket at an attended ticketing booth
    • The prepaid ticket may contain the price, the boarding station, the destination station, validity period and so forth.
    • In all cases the passenger presents the prepaid ticket at the boarding gate or ticket validator
    • The ticket validator verifies the validity of the ticket at the entry and possibly at the exit station
    • The AFCS provider and the ticket seller will settle transactions based on ticket validation reports.
  • What is the Post-paid QR Ticket Use Case?

    The use case for post-paid tickets is defined as follows:

    • The QCAT issuer, at the request of the passenger, generates a QR code on the mobile phone. The QR code contains information about the account or identity of the passenger
    • the QCAT issuer potentially earmarks a certain amount in the passenger’s account.
    • The entry and exit validators verify the QR code and open the gate if the QR data is valid
    • The QR validators send the QR validation records (entry and exit) to the QCAT Acceptor as soon as possible
    • The QCAT Acceptor provider calculates the ticket price based on entry and exit station and generates a payment transaction including the amount and the QR code account or identify data. The payment transaction record is sent to the QR code issuer who debits the passenger’s account based on the data included in the payment transaction record.
  • What Data does the QCAT QR Code contain?

    Please check the specification for the data elements defined for the QCAT QR code: [QCAT specification](https://github.com/afpayments/QCAT_QR_TICKETING_STANDARD).

    Table 1. Mandatory Data Elements

    Data Element Explanation
    Ticket Identifier A number that is unique in combination with the time of creation and the ticket issuer id or with the identifier of the issuing terminal.
    Ticket Creator ID The ticket creator is the organization that is authorized to create tickets and that will be liable for the fare amount when the ticket is accepted by an AFCS provider. IDs are allocated by AFPI.
    Time of ticket creation Time at which the ticket was created. The ticket validity and QR refreshment periods are always interpreted with this time as the base.
    Ticket Validity Period Time period in seconds from the time of ticket creation after which the ticket is not valid anymore.

    Table 2. Optional Data Elements

    Data Element Explanation
    Ticket Validity Domain Identifies the public transport facility on which the ticket is valid. Ticket domain identifiers are assigned by the ticket issuer and are unique only in combination with the ticket creator ID
    Transport Operator Id The identifier of transport operator for which the ticket is valid. There could be more than one operator ID in the QR code. Operators can be grouped and assigned a Ticket Validity Domain to avoid including too many operator IDs.
    Ticket Effective Time Time after which the ticket is valid. Default is the ticket creation time.
    Refresh Time Time after which the ticket need to be refreshed with a new refresh time and signature. A value of 0 or if the field is not included means that the QR ticket is static.
    Ticket Type Indicates a special processing rule that will be applied when calculating the fare.
    Account identifier The account identifier provides information about the passenger’s account with the funding provider. This account will be debited according to the fare table and ticketing rules. The account number may be created dynamically as a token that is valid only for a certain time or for a certain transaction. Backend system should therefore not rely on this identifier to group transactions. Must be present in post-paid tickets.
    Boarding Station The identifier of the boarding station or stop.
    Destination Station The identifier of the destination station or stop.
    Vehicle Id The identifier of the vehicle for the ticket is valid (e.g bus number).
    Route Id The id of the route for which the ticket is valid (e.g bus number).
    Seat Number The identifier for a particular seat that has been reserved for the passenger presenting this ticket. The format and meaning is operator or AFCS provider specific.
    Seat Class The identifier for a particular seat class. The format and meaning is operator or AFCS provider specific.
    Maximum Authorized Amount Amount in Centavos. If the fare amount is known when the passenger starts the trip, this field will be checked and the QR code rejected if the fare is higher than the maximum authorized amount. If the fare is not known at boarding time, the maximum remaining fare on the trip must be lower than the amount in this field. The funding provider may earmark this amount in the passengers account and release the unused funds when the correct fare amount is provided by the AFCS provider.
    Signature Key Identifier The key identifier is used to distinguish multiple public key certificates assigned to a single QR Issuer. It corresponds to the Common Name (CN) in the Issuer’s certificate. If present, the value in this field and the CN of the issuer certificate that is used to validate the signature must match. If this field is not present, the terminal will ignore the CN and use any certificate with the Ticket Creator’s ID.
    Terminal Identifier The terminal identifier identifies the device that “produced” the QR ticket. Validation terminals should always check the terminal ID, if present, together with the ticket ID and creation time to ensure that the same ticket is not used twice. The terminal ID should be unique in the ticket creator fleet of devices to the extend that the validation terminal is able to distinguish between two tickets with the same ticket identifier.
    Signature The signature proves that the the QR code was indeed created by the ticket issuer. The signature is calculated according to the algorithm that is described in this specification. The first byte contains a version number and the remaining bytes contain the signature value. Version numbers from 0x00 …​ 0x7F are reserved for this specification. Version number 0x80 …​ 0xFF can be used for proprietary algorithms. The default version number for the algorithm described in the specification is 0x01, which stands for SHA512 with RSA.

     

  • Does AFPI offer test and certification services?

    AFPI is leasing or selling validation terminals and test keys that can be used to verify the accuracy of generated QCAT tickets. AFPI can also validate a limited number of QCAT tickets that are sent to the following address …

    Based on separate commercial agreement, AFPI can also provide test services for validation and inspection terminals. Contact AFPI for details.

    AFPI also provides consulting services for any organization who develops or uses or plans to use or develop QCAT based systems.