Skip to content
QR Public Transport Ticket Specification
CSS Makefile
Branch: master
Clone or download



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?

We are sure that QCAT is an acronym for something we had in mind when we wrote the first versions of the standard, but we have forgotten what it is. Unfortunately, by now too many documents use the acronym to change it.

How does the beep(tm) system relate to QCAT?

beep(tm) 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(tm) cards and QCAT tickets.

Under what terms does AFPI license the QCAT specification?

The specification is publicly available and free to study 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 jeopardizing interoperability (see What does Interoperability in the QCAT Ecosystem mean?).

Our license agreement would be based on 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

  1. cryptographic signatures and a common QCAT Certificate Authority.

  2. common identifiers managed by the QCAT Registrar

  3. 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.

What roles exist in the QCAT Ticketing Ecosystem?

QCAT Ticket Issuer

An entity who enters into a contract with a potential or current passenger, issues QCAT 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.


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 ho9using 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).

What is the role of AFPI in the QCAT Ticketing Ecosystem?

  1. AFPI owns, licenses and manages the QCAT specification and materials.

  2. 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.

  3. AFPI operates the QCAT Registrar for participants IDs of issuers of QCAT tickets and other identifiers used in QCAT tickets

  4. AFPI operates as one of the QCAT Ticket Issuers, QCAT Ticket Creators and QCAT Ticket Acceptors

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 a license agreement for commercial use and an agreement with AFPI that will govern the use of the QCAT Certificate Authority and the QCAT Registrar.

Companies who would like their QCAT tickets to be accepted in validation and inspection terminals managed and/or operated by other participants in the QCAT Ecosystem, or companies that 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:

  1. Prepaid QR Code tickets can be printed on paper or generated and displayed on the phone

  2. The passenger pays for the ticket before starting the journey. There are many possible payment scenarios, such as

    • 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

  3. The prepaid ticket may contain the price, the boarding station, the destination station, validity period and so forth.

  4. In all cases the passenger presents the prepaid ticket at the boarding gate or ticket validator

  5. The ticket validator verifies the validity of the ticket at the entry and possibly at the exit station

  6. 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:

  1. The QR issuer, at the request of the passenger, generates a QR code on the mobile phone that contains information about the account or identity of the passenger

  2. the QR issuer potentially earmarks a certain amount in the passenger’s account.

  3. The entry and exit validators verify the QR code and open the gate if the QR data is valid

  4. The QT validators send the QR validation records (entry and exit) to the AFCS provider as soon as possible

  5. The AFCS 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

The list in this FAQ may not be up-to-date!
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.


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 via e-mail.

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.

You can’t perform that action at this time.