New Fare Payment Systems and Payment Technology Fare Background: Systems, Payments, and Policies

Deployment of a non-cash, technology-based fare system requires understanding the three key fare components: system, payments, and policies (Figure 1). The fare system is the ecosystem to calculate, verify, and collect the payment of fares. Fare systems can be procured through vendors who provide services and features to meet the fare needs of transit agencies and provide the technology platform. Fare payments are the mechanisms to pay the fare. The fare payment mechanisms discussed in this guidebook include contactless bank cards – Europay, Mastercard, and Visa (EMV) secure payment technology, smart cards, and mobile ticketing. Identifying the features that work best for a transit agency requires understanding the available technologies and the integration capabilities with the agency’s fare structure and policies. The fare structure is the system set up to calculate how much to charge a passenger at any given time.

To take advantage of technology-driven fare systems, transit agencies can contract with vendors such as fare systems providers, financial institutions, or credit card companies to provide the fare system or payments that allows riders to utilize fares other than cash.

To procure a fare system, typically, a transit agency must develop a Request for Proposal (RFP) document with requirements, specifications, and/or features they want to be included in the fare system, then the agency must issue RFP through a formal bidding process to procure services via a vendor. Upon identifying qualified vendors and procurement of services, the agency must install validators, if applicable, train and educate staff and operators, market services to the public, and initiate deployment. See the Best Practices and Recommendations section for more information on deploying a technology-based fare system.

Features of fare systems vary by vendor and can include, but are not limited to, the following:

Open-loop vs. Closed Loop Systems

Open-loop systems leverage existing open ‘tokens’ or unique identifiers typically associated with a smart card, student ID, or contactless bank card. ‘Tokens’ are randomly generated unique IDs assigned to EMV cards/devices that replace the account number (the 8-19 digit number that appears on a card), providing enhanced data security. Open ‘tokens’ are not proprietary to the transportation system but are part of the payment chain industry. This allows for flexibility in fare media because riders can use existing ‘tokens’ provided by an entity like a bank or university. Smartphones, wearables, and contactless credit cards are the most common devices suited to function in an open system; these devices allow for communication with fare system equipment via NFC or Bluetooth. Open-loop systems come with micropayments (small transaction amounts ranging from less than one cent to several dollars) because the processing fees associated with the card-based transaction, which the agency must pay, are high. To alleviate some of the cost, systems can implement fare aggregation where they aggregate transactions daily, so there are fewer small transactions. Open-loop systems are typically paired with an account-based back office system to calculate fares and authenticate that riders have the appropriate funds for their journey, in turn reducing the cost associated with issuing and managing fares for the transit agency.

Closed-loop systems are more traditional for fare payment systems, where only fare media issued by the transit agency can be used for fare payment. Smart cards issued by the transit agency or magnetic stripe tickets encoded with transit agency data are common ‘tokens’ used in closed-loop systems. Unlike open-loop systems, these types of fare media cannot be used by riders to pay for other goods or services outside the transit agency and are exclusive to transit. Closed-loop systems work offline and rely on stored-value, card-centric systems to process fares. All front-end equipment in a card-centric system must be able to update travel records and/or perform fare calculations directly to the card each time it is presented, including checking that the card is authentic, the right values are present, and the data on the card is updated at the time of transaction.

Fare Payment as a Service (FPaaS) vs. Bespoke Automated Fare Collection (AFC)

Many transit agencies may have a traditional bespoke, automated fare collection (AFC) system, which was developed specifically for their usage. Bespoke AFC systems are an end-to-end solution for collecting fare payments by digitalizing the issuance of tickets; however, they rely on farebox infrastructure using software and hardware designed with specific specifications. Bespoke systems can be expensive to build, maintain, and update and tend to be closed in nature with the inability to integrate with new systems.

Compared to bespoke AFC systems, transit agencies may look to utilize cloud-based subscription systems such as Fare Payments as a Service (FPaaS) systems. Subscription-based models are often referred to as Software as a Service (or SaaS) because every system utilizes the same platform and can vary by software complexity from straightforward to complex. Straightforward software includes a base level of software required to accept fare payment. Comparatively, a more complex SaaS may include a more detailed software whose features allow for open integrations to link to other platforms, mobility as a service (MaaS), and digitalization of fare payments. Vendors can also provide hybrid SaaS offerings by providing a cloud-based service that allows for some level of integration with other platforms but is straightforward to select and purchase passes.

FPaaS allows agencies to procure a fare payment platform at a much lower cost of entry because the vendor charges a monthly fee (or takes a percentage of fare revenue collected) instead of charging initial high upfront capital costs. By utilizing FPaaS, transit agencies can implement the latest and greatest fare technologies with automatic firmware/software updates that the vendor can deploy to the transit agency as updates are available. By using the SaaS platform as a baseline, each transit agency can use the same FPaaS platform that is then configured specifically to that agency’s needs. FPaaS also utilizes open-loop infrastructure, allowing systems to seamlessly integrate with other technology.

Fare Payments

Transit agencies have a range of fare payment options available to choose from for their riders. Fare payments are defined as the mechanism to pay a transit fare. Historically, transit agencies may have allowed fare payments in cash or exact change onboard the bus, paper passes, or physical tickets provided by the bus driver or generated by ticket vending machines or electronic fare boxes.  Now, transit agencies can utilize technology-driven fare payment solutions to offer added convenience, flexibility, and access to riders.

This section describes three fare payment types: contactless cards enabled with EMV technology, smart cards, and mobile ticketing. Fare payments are a crucial component of a fare payment ecosystem, including the technology needed to process fare payment types. Transit agencies should consider the associated capital and operating costs, hardware requirements, and level of complexity to integrate the fare payment. Additional consideration should be given to the utilization of the fare payment and equitable access for riders.

Contactless Cards (EMV)

Contactless enabled bank cards, or EMV, are a global standard for cards equipped with computer chips and the technology used to authenticate chip-card transactions. EMV technology can enhance security between merchants and customers by securing banking data. As of 2021, 78 percent[1] of U.S. card issuers have migrated to EMV technology for debit and credit cards. The EMV technology allows users to tap-and-go with their card to access open-payment systems. For transit, passengers can use their bank-issued contactless credit or debit card to tap a payment reader to validate the fare and access transit services.

The first time a card/device is tapped within the transit system, the reader sends a request to authorize the transaction to the merchant (transit agency), which forwards it to a financial institution (the bank that issued the card). The financial institution performs a series of checks and either authorizes or denies the transaction. This is all done offline so as not to slow down the boarding process. If the financial institution denies the card, this information is sent back to the payment processor (software on the validators), and the card is put on the ‘bad’ list. It will be immediately rejected upon the next tap on the validator. For the initial transaction with an EMV card, first ride risk occurs, in which the payment authorization could be declined following the initial tap transaction, which could mean no fare is collected. The financial institution often carries the first ride risk, but a transit agency may also be accountable if not detailed in vendor contracts. Financial institutions also carry the Payment Card Industry (PCI) Data Security Standard (DSS) or set of requirements intended to ensure that all companies that process, store, or transmit credit card information maintain secure information.

[1] https://www.emvco.com/about/deployment-statistics/

Debit and credit cards enabled with EMV technology can be stored in a digital wallet on a smartphone, computer, wearable, or tablet. The data can be transmitted to other devices using wireless technologies (NFC or Bluetooth) to make payments. Popular mobile wallets include Apple Pay, Google Pay, and Samsung Pay. The payment card data is scanned or manually entered into the application and sent for validation to the payment network. At the end of this process, the user can make payments on the accepted terminals using their mobile device instead of a physical debit or credit card. The payment card data is never shared with a merchant when making payments or stored on the device; instead, a security feature called tokenization is used. Tokenization is the process of replacing confidential data with non-confidential data called a ‘token.’ Mobile payment applications, including popular mobile payment services such as Venmo and Cash App, utilize payment ‘tokens’ to secure data and allow users to access open payment systems.

Smart Cards

Smart cards are cards approximately the same size as credit or debit cards that are typically issued by transit operators to be used within their private ticketing system. There are three models for Smart cards: contactless, magnetic stripe, and virtual. Contactless smart cards function similarly to contactless EMV cards. They are enabled with a microchip or radio frequency identification (RFID) technology that allows users to tap the card on a reader. Smart card systems can be either account-based or card-centric, but in both cases, the transit system has its own fare media and accounting network for the card. Users must load funds onto the card, and it can only be used for that network. A debit/credit card can be linked to a smart card, and funds are automatically withdrawn from the account with each transaction.

Smart cards can work with card-centric systems or with ABT by acting as an identifier to log a passenger’s access to the transit system. For card-centric systems, smart cards interact offline, without internet or cellular connectivity, with onboard vehicle devices. For ABT, smart cards act as ‘tokens’ working in tandem with a back-office via an internet or cellular connection. Contact smart cards have magnetic stripes the user must swipe through a reader. Special smart card readers are required onboard each vehicle and are typically part of a larger electronic farebox system to process fares for both card types. Virtual smart cards can be emulated on mobile devices if the agency elects to have this feature and are typically used for ABT.

Transit agencies may elect to utilize a retail partnership network to offer equitable solutions for transit riders to load value onto their smart card. For example, InComm Payments provides prepaid products, services, and transaction technologies for retailers, brands, and consumers. Transit users who may be unbanked or do not use a financial institution can load cash onto compatible smart cards through local InComm Payment retailers, such as gas stations, grocery stores, or other locations where gift cards are typically sold. The smart cards, now loaded with a stored value, can be used to access transit services.

Mobile Ticketing

Mobile ticketing is the process in which passengers can select a fare type, pay for the fare, and display the mobile ticket onboard vehicles using their mobile phone. Mobile ticketing is the key feature of mobility apps designed to increase rider convenience replacing the face-to-face interactions previously required to purchase fares. Mobile tickets are a form of ABT in which a rider needs to have an account, often tied to a phone number or email address, to purchase fares. The types of mobile tickets offered should mirror existing transit agency fare structures, including the fare type (e.g., single-ride tickets or monthly passes). Riders can purchase fares by linking a debit/credit card or by adding cash to their account at approved retail locations, similar to how a rider may load a smart card. Upon boarding the bus, riders activate the mobile ticket and either validate the ticket by showing the bus operator or scanning it on a validator.

The mobile ticketing applications can be configured to offer reduced fares and confirm eligibility. Examples of reduced fares include senior fares, disabled fares, and fares for institutional partners such as employers or universities. Mobile ticketing can accommodate requirements by transit agencies to verify eligibility for reduced fares in two ways. First, mobile ticketing apps may prompt passengers who are purchasing reduced fares that they will be required to show proper proof of identification, as aligned with the existing agency fare policy, to the driver upon boarding. Second, some mobile ticketing apps allow eligibility to be verified through the device. For example, mobile ticketing apps can be configured to allow an authorized agency, in addition to the transit agency, such as the Department of Motor Vehicles or Department of Veterans Affairs, to verify eligibility status, including age, disability, or veteran designation. Employers and educational institutions can work with transit agencies to be set up as third-party authorized users to manage users and link accounts to reduced fare types. For example, a local university student can link their mobile devices to their school email address, designated and approved by the university, as a third-party authorized user. As a result, when the student activates the mobile ticket via their email address linked account, it is already pre-designated as a reduced fare.

Fare Policies

Identifying the fare systems and fare payment methods that work best for a transit agency requires understanding the available technologies and its integration capabilities with the agency’s fare structure and fare policies. Fare policy decisions are made at the agency level and can include fare-free, the decision not to collect fares, or going cashless and requiring riders to use non-cash methods. Regardless of the decision on whether or not to go cashless, all agencies that charge fares can take advantage of fare capping and its integration with fare technology to ensure financial incentives can benefit all riders.