Skip to main content

The QCAT Standard: An Overview of the QR Code Specification



In this guide, we’ll explore the standardized format for encoding transport tickets as QR codes, designed to align with the EMV QR Code Specification for Payment Systems (EMV QRCPS), ensuring seamless integration and interoperability.

General Requirements and Features

The QR Code Standard meets the EMV QRCPS Consumer Presented Mode and includes several key features:

  • Base64 Encoded Payload: Ensures compatibility across various platforms.
  • BER-TLV Encoded Data: Facilitates efficient data transfer.
  • Mandatory EMV Data Elements: This includes:
    • Payload format indicator
    • At least one application template
    • Use of the EMV application-specific transparent template for ticket-specific data
  • Payload Limit: Maximum payload size of 512 bytes, adhering to EMVCo requirements.
  • EMVCo Processing Rules: Validation terminal QR Code readers must recognize codes that meet EMV specifications, ensuring security and reliability.

QR Ticket Format

QR Ticket Encoding

The QR Code is encoded according to ASN.1 and BER encoding rules, ensuring that data fields can be flexible in their order, presence, and quantity.

QR Code Fields

Mandatory Fields

  • Ticket Identifier
    • Tag: 1
    • Format: Unsigned Integer (32 bit)
    • Sample Value: 1250184
    • Sample TLV Value: 131388
    • Notes:
      • Must be a unique identifier
  • Ticket Creator Id
    • Tag: 2
    • Format: Unsigned Integer (16 bit)
    • Sample Value: 275
    • Sample TLV Value: 0113
  • Ticket Creation Time
    • Tag: 3
    • Format: Timestamp
    • Sample Value: 2019-09-11T19:38:30+08:00
    • Sample TLV Value: 5D78DCB6
  • Ticket Validity Period
    • Tag: 4
    • Format: Unsigned Integer (32 bit)
    • Sample Value: PT15M
    • Sample TLV Value: 0384
    • Notes:
      • Validate if expired using the following conditions
        • If Ticket Effective Time is present, Ticket Effective Time + Ticket Validity Period
        • Else, Ticket Creation Time + Ticket Validity Period

Optional Fields

  • Ticket Validity Domain
    • Tag: 5
    • Format: Unsigned Integer (16 bit)
    • Sample Value: 5
    • Sample TLV Value: 05
    • Notes:
      • Using a value of 0 means all domains
  • Transport Operator Id
    • Tag: 6
    • Format: Unsigned Integer (32 bit)
    • Sample Value: 23
    • Sample TLV Value: 17
    • Notes:
      • You can have multiple entry of this field
  • Ticket Effective Time
    • Tag: 7
    • Format: Timestamp
    • Sample Value: 2019-09-11T19:38:30+08:00
    • Sample TLV Value: 5D78DCB6
    • Notes:
      • Using a value of 0 means immediate
  • Refresh Time
    • Tag: 8
    • Format: Timestamp
    • Sample Value: 2019-09-11T19:39:00+08:00
    • Sample TLV Value: 5D78DCD4
    • Notes:
      • The QR is considered static using the following conditions
        • Using a value of 0
        • Excluding this field
  • Ticket Type
    • Tag: 9
    • Format: Unsigned Integer (16 bit)
    • Sample Value: 1
    • Sample TLV Value: 01
    • Notes:
      • Using a value of 1 means standard
  • Account Identifier
    • Tag: 10
    • Format: Unsigned Integer (16 bit)
    • Sample Value: 1234567890123456
    • Sample TLV Value: 31323334353637383930313233343536
  • Boarding Station
    • Tag: 11
    • Format: Unsigned Integer (32 bit)
    • Sample Value: 23
    • Sample TLV Value: 17
  • Destination Station
    • Tag: 12
    • Format: Unsigned Integer (32 bit)
    • Sample Value: 17
    • Sample TLV Value: 11
  • Vehicle Id
    • Tag: 13
    • Format: Unsigned Integer (32 bit)
    • Sample Value: 345
    • Sample TLV Value: 0159
  • Route Id
    • Tag: 14
    • Format: Unsigned Integer (32 bit)
    • Sample Value: 4
    • Sample TLV Value: 04
  • Seat Number
    • Tag: 15
    • Format: ASCII
    • Max Length: 5 Characters
    • Sample Value: 3D
    • Sample TLV Value: 3344
  • Seat Class
    • Tag: 16
    • Format: ASCII
    • Max Length: 5 Characters
    • Sample Value: ECO
    • Sample TLV Value: 45434F
  • Maximum Authorized Amount
    • Tag: 17
    • Format: Unsigned Integer (32 bit)
    • Sample Value: 30.00
    • Sample TLV Value: 0BB8
    • Notes:
      • This amount is in centavos
      • Using 0 as value means unlimited
  • Signature Key Identifier
    • Tag: 18
    • Format: ASCII
    • Sample Value: STAG-AFPI-V2
    • Sample TLV Value: 535441472D414650492D5632
    • Notes:
      • Used to distinguish multiple public key assigned to a single issuer
  • Terminal Identifier
    • Tag: 19
    • Format: ASCII
    • Sample Value: 1234567890
    • Sample TLV Value: 31323334353637383930
  • Funding Source Type
    • Tag: 20
    • Format: Unsigned Integer (32 bit)
    • Sample Value: 1
    • Sample TLV Value: 01
  • Funding Source Provider
    • Tag: 21
    • Format: ASCII
    • Sample Value: 1
    • Sample TLV Value: 31
  • Signature
    • Tag: 30
    • Format: Binary

Conclusion

The QR Code Standard for Transport Ticketing enhances efficiency and user experience in public transport systems. By adhering to strict guidelines, this standard ensures secure, reliable, and flexible ticketing solutions for various transport providers.

If you’d like to learn more or get involved in the QCAT ecosystem, feel free to check out my guides on QCAT specification below or check out AF Payments Inc.'s GitHub for the latest updates and contribution guidelines.

Don't forget to subscribe to my blog so you never miss out on my latest guides and content!

DISCLAIMER

The information provided in this article is for informational purposes only and does not constitute professional advice. While efforts have been made to ensure accuracy, AF Payments Inc. reserves the right to update or modify the QCAT standard and related materials at any time. Use of the QCAT standard is subject to the terms of its license agreement, and any implementation must adhere to AFPI's guidelines and licensing requirements. For the latest details and official documentation, please refer to AF Payments Inc.'s authorized channels.

Comments

Popular posts from this blog

Understanding Number Systems: Decimal, Binary, and Hexadecimal

In everyday life, we use numbers all the time, whether for counting, telling time, or handling money. The number system we’re most familiar with is the   decimal system , but computers use other systems, such as   binary   and   hexadecimal . Let’s break down these number systems to understand how they work. What is a Number System? A number system is a way of representing numbers using a set of symbols and rules. The most common number systems are: Decimal (Base 10) Binary (Base 2) Hexadecimal (Base 16) Each system has a different “base” that tells us how many unique digits (symbols) are used to represent numbers. Decimal Number System (Base 10) This is the system we use daily. It has  10 digits , ranging from  0 to 9 . Example: The number  529  in decimal means: 5 × 1⁰² + 2 × 1⁰¹ + 9 × 1⁰⁰ =  500 + 20 + 9 = 529 Each position represents a power of 10, starting from the rightmost digit. Why Base 10? Decimal is base 10 because it has 10 digits...

How to Monetize Your API as an Individual Developer While Hosting on Your Own Server?

In the API economy, cloud services like AWS, Google Cloud, and Azure offer many conveniences, such as scaling and infrastructure management. However, some developers prefer more control and autonomy, opting to host their APIs on personal servers. Whether for cost efficiency, data privacy, or customization, hosting your own API comes with both advantages and challenges. But, even without cloud platforms, there are effective ways to monetize your API. This guide will explore how individual developers can successfully monetize their APIs while hosting them on their own servers. Why Host Your API on Your Own Server? Hosting your own API gives you full control over the infrastructure and potentially lower long-term costs. Here’s why some developers choose this approach: Cost Control : Instead of paying ongoing cloud fees, you may opt for a one-time or lower-cost hosting solution that fits your budget and resource needs. Data Ownership : You have full control over data, which is critical if ...

The Weight of Responsibility: A Developer’s Journey to Balance Passion and Reality

For the past several years, Eddie has been on a steady climb in his career as a developer, but recently, he found himself at a crossroads — caught between the weight of his responsibilities and the desire to pursue his true passions. His journey began with a three-month internship as a web developer, which led to nearly four years in an application developer role. After that, he spent almost a year as a systems associate, managing tasks across systems analysis, quality assurance, and business analysis. Eventually, he returned to full-time software development for another two years before transitioning into more complex roles. For over a year, he worked as a multi-role software developer and database administrator before stepping into his current position as a senior software developer, database administrator, and cloud administrator — occasionally handling security tasks as well. Now, with over 8 years of professional experience, he also leads a small team of developers, which has been...

The Hidden Costs of Overdesign and Bad Practices in API Systems

In software development, simplicity and clarity are often sacrificed in favor of overly complex solutions. While it can be tempting to add more features and intricate designs to ensure robustness, overdesign and poor practices can have significant consequences. They frustrate developers, lead to inefficiencies, increase costs, and put unnecessary strain on system resources.  A recent example involving a team that has faced challenges with complexity highlights the pitfalls of such an approach. Overdesign: The Problem of Too Much Complexity Overdesign occurs when systems are built with more complexity than necessary. This might manifest in bloated APIs, convoluted data flows, or excessive checks and processes that don’t add substantial value. The goal is often to anticipate future problems, but this approach typically results in cumbersome systems that are difficult to maintain and scale. In one case, a company found itself paying a hefty price just to host two API services and a po...

Selenium for Beginners: What, Where, When, and Why to Use It in Automated Testing

In today’s software development landscape, automated testing has become essential for delivering robust applications efficiently. Among various automated testing tools,   Selenium   stands out as one of the most widely used and beginner-friendly options. As you embark on your journey into automated testing, it’s crucial to understand the   what, where, when, and why   of using Selenium. In this guide we will run through these essentials and help you decide if Selenium is the right tool for you. What is Selenium? Selenium  is an open-source framework used primarily for automating web browsers. It enables developers and testers to write scripts that interact with websites, simulating actions like clicking buttons, filling out forms, and navigating pages, which allows for comprehensive automated testing. Selenium supports multiple programming languages, including Python, Java, C#, and JavaScript, making it flexible for teams with different coding preferences. Key C...