Add cemv_support field in agency.txt and routes.txt

[Sergiodero]

Summary

This proposal introduces a new cemv_support field in agency.txt and routes.txt to indicate if riders can use cEMV (contactless Europay, Mastercard, and Visa) to access a transit service under a specific agency or route. Its use is independent of all other fare files and can be used separately.

Describe the Problem

The current implementation of GTFS Fare features is intended to display the correct price for a given trip included in the feed. Through the use of the fare_media.txt file transit agencies can specify their support for contactless payment methods also known as cEMV (contactless Europay, Mastercard and Visa).

However, to enable consumers to display the correct payment options for specific trips, fare rules must be fully defined.
There is currently no simple solution for producers who simply want to indicate that a contactless payment method is accepted for users to access a service.

Proposed Solution

This proposal introduces a new, optional cemv_support field in two existing and widely used files: agency.txt and routes.txt.

This new field is proposed as an Enum field type with the following options:

• 0 or empty: No cEMV information available for trips associated with this agency or route
• 1: Riders may use cEMVs as fare media for trips associated with this agency or route
• 2: cEMVs are not supported as fare media for trips associated with this agency or route

This allows producers to clearly indicate cEMV support at the agency and route levels without requiring a full definition of their fare system rules. In turn, this enables trip planners to inform users that contactless payment methods can be used for their trip without detailing the trip's exact price.

The use of this field is intended to be independent of all other fare files and can be used separately. If both agency.cemv_support and routes.cemv_support are provided for the same service, routes.cemv_support takes precedence.

It’s important to note that in this proposal, cEMV support specifically refers to its use as fare media to pay a transit fare. It does not cover using cEMV to purchase fare products or add value to other fare media (e.g., buying a paper ticket or loading credit onto a transit card).

Use Cases

Ottawa's OC Transpo allows users to pay a regular adult fare by tapping with debit cards, credit cards and mobile wallets at fare readers on buses and fare gates at O-Train stations. Under the current GTFS Fares features, OC Transpo would need to define full fare rules to indicate cEMV support.

By using the new cemv_support field in agency.txt or routes.txt, OC Transpo could easily indicate that cEMV payments are accepted across its services without requiring a full fare model.

Additional Information

We recommend a minimum discussion period of 2 weeks for this proposal. Previous discussions took place in the January and February 2025 Fares Working Group meetings, where alternative approaches were considered before settling on the current one. Review the working group meeting notes and the original proposal document for further reference.

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[miklcct]

I have some reservations on this proposal. What about paying cash instead? I think that we should, instead, have a way to specify which form(s) of payment method are accepted on board instead without defining a full fare model.

In short, this proposal doesn't scale at all.

[Sergiodero]

Hi @miklcct , thanks for the feedback! I’d like to clarify a few points about the intent of this proposal.

This feature is intentionally designed to be simple and easy to produce, lowering the access barrier for adoption. While different approaches were considered, the Fares working group ultimately decided to prioritize ease of implementation over completeness.

This feature is not specific to on-board payment. During these working group discussions, it was suggested and agreed that the focus should be on whether a rider can access a trip using cEMV, rather than specifying where or how payment is handled. Whether validation occurs on board or at a station was thought to be out of scope, thus we removed any language referencing on-board or in-station validation.

Both of these points were discussed in the January and February Fares working group meetings. If you're interested, you can check out the meeting notes here for more context.

Additionally, there seems to be a some demand for a lightweight way to indicate tap-to-ride availability without requiring a full fare model or necessarily expressing the trip price. This proposal aims to standardize that practice, rather than introduce a new layer of fare modeling.

That said, it would be good to hear from others who were involved in the working group meetings: @jll01 @skinkie @westontrillium @bdferris-v2 @evansiroky @halbertram

[miklcct]

Then how about specifying the ability to access a trip using cash as well?

[stevenmwhite]

I'll be upfront that I haven't followed the working group discussions about this and will dive in deeper before forming an opinion in support or against, but I will say that it seems very strange up front to put payment method information in a place that's very separate from the rest of the fare information.

I totally understand the goal of not needing to model a full fare structure in order to indicate how that fare can be paid... but at first glance it seems that would be more logically done somewhere closer to the rest of the fare info.

[westontrillium]

@stevenmwhite If it were closer to the rest of fare info, that would prevent it from being Fares version-agnostic, since we'd have to choose the structure it is closer to. Keeping its current design means that anyone can implement it—whether your GTFS has Fares v1, v2, or no fare info at all. Knowing if cEMV payment is supported is valuable by itself, so I think it's reasonable to have it reside in the category of "general information about the agency" (with the ability to specify for different routes if needed). There is also precedent for fare info to exist at the agency level (and route level, although that example is not self-contained).

@miklcct I think this extension has a more targeted goal: To allow trip planning apps to accurately show what is now a globally recognized symbol indicating that a specific technology (cEMV) is enabled for a transit service.

[miklcct]

@stevenmwhite If it were closer to the rest of fare info, that would prevent it from being Fares version-agnostic, since we'd have to choose the structure it is closer to. Keeping its current design means that anyone can implement it—whether your GTFS has Fares v1, v2, or no fare info at all. Knowing if cEMV payment is supported is valuable by itself, so I think it's reasonable to have it reside in the category of "general information about the agency" (with the ability to specify for different routes if needed). There is also precedent for fare info to exist at the agency level (and route level, although that example is not self-contained).

@miklcct I think this extension has a more targeted goal: To allow trip planning apps to accurately show what is now a globally recognized symbol indicating that a specific technology (cEMV) is enabled for a transit service.

I want to show different symbols (cash, contactless, phone, smart card, QR transport code, etc.,) and this proposal isn't scalable.

[Sergiodero]

@miklcct we actually considered an alternative approach (new separate file) during the early stages of the proposal which could potentially allow matching fare media to agency_id and route_id at the cost of being slightly more complex.

After some discussions with stakeholders in the fares working group, the current solution was preferred for being extremely simple to implement. That was the main goal, not to cover every payment method, but to provide a quick shortcut for contactless payments since their adoption has become especially relevant.

Still, your point is fair, and we believe it warrants further discussion. If it's okay with you, we would like to invite you to participate in the next Fares working group meeting on April 22nd, so we can revisit this topic and have a broader discussion with the rest of the participants.

You can sign up using the following link. Anyone else interested in this or any other Fares-related proposal is welcomed to join.

[miklcct]

@stevenmwhite If it were closer to the rest of fare info, that would prevent it from being Fares version-agnostic, since we'd have to choose the structure it is closer to. Keeping its current design means that anyone can implement it—whether your GTFS has Fares v1, v2, or no fare info at all. Knowing if cEMV payment is supported is valuable by itself, so I think it's reasonable to have it reside in the category of "general information about the agency" (with the ability to specify for different routes if needed). There is also precedent for fare info to exist at the agency level (and route level, although that example is not self-contained).

@miklcct I think this extension has a more targeted goal: To allow trip planning apps to accurately show what is now a globally recognized symbol indicating that a specific technology (cEMV) is enabled for a transit service.

I have given some thought in this proposal over the last week and I think this is an extremely poor proposal, as it is:

• meaningless: which kinds of cEMV are accepted. Does it accept American Express? Does it accept UnionPay? Does it accept JCB? ......
• ambiguous: what does it mean to "access a transit service"? cEMV on transit has multiple modes of operation. Does this field mean cEMV can be used to pay the fare directly without buying a ticket, or does it mean something else?
• non-scalable: if transit agency wants to promote that they accept / do not accept cash, SMS, or any other payment method, it will need to create another field, potentially adding another dozen of fields into agency.txt and routes.txt. This is also a concern I mentioned in Add cars_allowed field to trips.txt #547 as well, but at least, in my opionion, that proposal for car routing has well-defined semantics, is easy-to-implement with immediate real-world usage so I think it is a good compromise on the non-scalability.

For example, in the UK, some companies accept cEMV in terms of tap on tap off, but others still require the use of a ticket, that can be obtained on board using cEMV, while some companies require the use of a ticket, which must be bought beforehand (before boarding the vehicle) and can be done by cEMV. These are 3 very different uses of cEMV and this proposal do not well-define which it means. There are also other agencies in other countries implemented the use of preloading tickets into cEMV (not physically, but associating them with an account) as well.

I now think that a better idea is to link routes.txt or agency.txt with fare_media.txt, possibly with another optional intermediate file, freeing the agency's need to define the full fare rules for their services.

[timMillet]

IMHO, there are 2 issues with the current proposition:

1. Missing precedence rule

Although the proposition is agnostic between Fares v1 and Fares v2, it brings a way of defining cEMV support as Fares v2 already does. I don’t see a rule of precedence in case contradictory information is provided between agency.cemv_support and routes.cemv_support on one hand, and any Fares v2 rules in fares_media.txt on the other hand.

I strongly suggest that this proposition provides a rule of precedence (in any way) to prevent this conflict from happening. The information provided by the data producer must be as explicit as possible to reduce all possible data misinterpretations by any consumers.

2. Data modelling

I understand that this proposition was made to make cEMV support definition as simple as possible, and I’m entirely convinced that this is needed and meaningful, but not only for cEMV. IMHO, from the rider’s perspective, free fares are as important as cEMV fares, as there is no need to buy anything before boarding vehicles/entering stations. Also, transit agencies working with Transit generally like to promote their free routes. Providing a simple way of defining any payment forms (cEMV, none/free, physical paper ticket, physical transit card, mobile app, something else in the future?) is important.

In this way, I agree with @miklcct that this proposition doesn’t scale. I think there can be a better way of simply defining payment forms than potentially adding 5 new fields in both agency.txt and routes.txt, starting with cemv_support. At the same time, the suggested Option B is more complex than needed: it adds one new file specifically for cEMV support, and allows defining cEMV support per trip and stop.

There should be a solution between this current PR and option B. For example, and similarly to what was suggested in the comment above, it could be one new file simple_fares.txt (actual name TBD) with 3 fields agency_id, route_id, and fare_media_type; the last field enumerating the same options as fare_media.fare_media_type. Even though this file is inspired by fare_media.txt, it’d be Fares v1/v2 agnostic.

[Sergiodero]

Following the discussion held during the April 22, 2025 Fares Working Group meeting (see meeting notes here), we’ve made a few updates to this proposal to reflect the feedback shared and to clarify its intended scope. These changes are summarized below:

1. We clarified the purpose of this field making it a bit more explicit to reduce ambiguity following @miklcct comments:

• It now focuses on indicating whether riders can access a service by using a contactless EMV card or device as fare media, tapping on a fare validator.
• Included a reference to pay-as-you-go, open-loop systems as an example to help frame typical use cases and the intended use of these fields
• Specified that this is not meant to describe if cEMV can used to purchase fare products or load value onto other media

2. We added explicit text to handle potential data conflicts based on @timMillet feedback:

• Reaffirmed that routes.cemv_support overrides agency.cemv_support when both are present.
• Added clarification that, in the event of conflicting information, data in other fare-related files takes precedence over these new fields.

We also want to share some context from this last WG meeting:

• The group emphasized that this proposal is meant to serve as a simple and lightweight way for producers to indicate that contactless EMV payments are supported in some capacity.
• The aim is to enable consumers to display a basic message or icon (such as a “tap-to-ride” availability message) to inform riders that they may be able to access a service using a contactless credit or debit card and/or a mobile device.
• Regarding @miklcct and @timMillet feedback on scalability, the current approach is intentionally minimalistic to encourage broader adoption, particularly among producers who may not yet be ready to implement the full complexity of Fares v2.
• As noted during the conversation, once the need goes beyond showing an icon in a UI, it may make more sense to use Fares v2, which supports more detailed fare modeling.
• It was also acknowledged that consumers will typically be responsible for determining which specific cEMV cards or devices are accepted.
• As mentioned during the meeting, this field can be a signal to the consumer to go search for which cards are supported by the agency.
• This is not explicitly stated in the description at this moment, but it can be added if folks find it useful.

We hope these adjustments align with the discussion and help clarify the intent of the proposal. As always, feedback is welcome from everyone.

[jll01]

TTC just added the cemv_support field in agency.txt. See TTC GTFS data.

For TTC, the Transit app is now showing the Contactless information based on the presence of this new field, as seen on the screenshot below.

[Sergiodero]

Thanks @jll01, this confirm that first adopters have successfully implemented the proposed change, as required by the applicable Governance. Therefore, we are planing to initiate a vote on this PR next week, on Sep 15.

Producer: Toronto Transit Commission
Consumer: Transit App

[Sergiodero]

As mentioned in previous comment, I am officially calling a vote to adopt the proposed new cemv_support field in agency.txt and routes.txt. Voting will remain open until 2025-09-29 at 23:59:59 UTC.

[drewda]

+0 from @interline-io

We agree with @timMillet's comments earlier at #545 (comment) This addition is duplicative of existing Fares v2 capabilities, but it doesn't establish a new alternative pattern worth expanding over time.

[jll01]

+1 Transit

[M1LL3RD]

+1 Translink, Australia

[laurentg]

+0 from Mecatran.

We are a bit neutral on this, as none of the people we work with raised to us this need specifically. We acknowledge that this provide an easy solution to a specific need, but at the same time we are a bit dubious about the extensibility / adaptability of this approach in the long run.

[BodoMinea]

+1 FlashWeb IT / Bucharest (TPBI)

I would normally be against 2 ways of representing the same information (eg. fare_media_type = 3 does this exactly), but since the Fares V1 and V2 models already duplicate elements of each other, I believe this is beneficial in the short to medium term, with some notable consumers being slow to adopt the complexities of Fares V2.

We already have to manually enable contactless payment banners/badges with Google Transit for example, despite this information being present in our Fares V2 feeds. I would rather have this represented programatically for the time being.

I would also kindly suggest that if and when this will be added to the spec, there is clear wording around it being a solution to a legacy problem and the preferred method of communicating the availability of cEMV/tap and go type payments being a spec-compliant Fares V2 implementation.

[BKK-Budapest]

+1 from Budapest. Since we have a very difficult fare system, we have low chance to define it in fares.txt at least in an acceptable quality. We are at the first lesson about the contactless payment, we have two routes available for this method, so it would be great if we could easily define these routes as a contactless fare option.

[Sergiodero]

The vote passed on 2025-09-29 at 23:59:59 UTC.

4 votes in favour and no votes against (with two abstentions).

Votes came from:
@jll01 Transit
@M1LL3RD Translink (Australia)
@BodoMinea FlashWeb IT
@BKK-Budapest Centre for Budapest Transport

Thank you to everyone who participated!

[Sergiodero]

I would also kindly suggest that if and when this will be added to the spec, there is clear wording around it being a solution to a legacy problem and the preferred method of communicating the availability of cEMV/tap and go type payments being a spec-compliant Fares V2 implementation.

Hey @BodoMinea, thanks for this suggestion! We agree that it would be valuable to explicitly clarify the preferred use of other GTFS fare files (which was also our original intention for this mechanism).

Since the vote for this PR was already underway and close to completion, I think the best path forward is to open a new PR to add this clarification as a non-functional change. It might take a bit more time, but this approach will make sure the change is transparent and not rushed in at the last minute.

We’ll go ahead and merge this PR as-is for now, and work on the additional clarification in the coming days.