In July of 2017, TriMet, along with C-TRAN and Portland Streetcar, launched HOP Fastpass as the Portland region’s fare payment system. Hop is an account-based regional fare system with a number of industry-leading features including:
- Application Programming Interfaces (APIs) for integrating software and components from various vendors
- Virtualized Fare cards (“mobile wallets”)
- Fare Capping
The open architecture of the Hop system create the potential for future payment integration with TriMet’s Shared-Use Mobility OpenTripPlanner project (in-progress update to the multimodal maps.trimet.org), 3rd party mobile apps and with other mobility providers’ services, such as the regional bikeshare system.
Hop’s open architecture is unique and offers useful lessons and examples for the transit industry. TriMet’s Tim McHugh (CTO) and Rhyan Schaub (Director of Fare Revenue) were kind enough to share notes from the Hop implementation story in an interview.
Here are a few quick links to particular themes below:
- Planning Process and Goals
- Institutional management
- Opportunities to Analyze Traveler Needs
- Account-Based Approach
- Procurement Approach
- System Architecture and Components
- Retail Network
- Future Standardization
- Future Partnerships
Planning Process and Goals
Aaron Antrim: Can you talk about the planning process for Hop? Why did the project come about? What were the priorities and how were those priorities determined for the project?
Rhyan Schaub: In about 2010, the agency was faced with a decision to either spend $50 million to $60 million upgrading our existing fare collection infrastructure or to spend a fraction of that refurbishing it and then focus our primary capital outlay on a new next generation fare collection system. We chose to go with the latter primarily because it offered more convenience for our customers and less operating costs in terms of equipment maintenance. A lot of our old equipment had numerous mechanical parts that could break and had to be replaced. All of the next generation equipment is more software-focused, with much fewer moving parts that can break. The other piece of it was reducing cash in the system and all of the costs associated with managing cash.
Aaron: From where did TriMet draw some initial lessons?
Rhyan: We polled several agencies that had done similar things or even different things, asking about the pros and cons of the decisions they had made, what they could do or would do if they were doing it all over again, and what plans they had for future fare collection strategies. We then picked the best elements from all of that research and we wrote our own white paper, and that became the foundation of what would become Hop.
There was also quite a bit of work done on fare policy. What we are doing is unique. The only other system I am aware of that is offering fare capping on a large scale is Transport for London [TfL], and our system does that. It’s a great equity benefit to customers. It allows anyone, most importantly, our low income riders, to get the benefit of a monthly pass, but pay as they go. In the paper world, you had to walk in with one hundred dollars in hand to buy your monthly pass on the beginning of the month. Now, you can load five dollars every day, tap your card, and we will never charge you more than the value of that monthly pass that you would have purchased. So it allows you to increment your way to the monthly pass value without having that initial outlay. It also changes the mindset of the consumer from having to consider, “Am I going on vacation this month? Am I going to be sick? How many times am I actually going to ride transit? Does a monthly pass make sense?” This gives you that flexibility to buy transit fare like you would anything else. You don’t buy a monthly pass for your coffee at the beginning of the month. You buy your coffee as you consume it, and this allows the customer to think about transit in that same way. It makes it a more desirable mode of transportation.
Aaron: I’m hearing that the main priorities for the next generation fare system were equity and making the system attractive through fare capping or convenience. Also reducing the cost and hassle of cash processing. Is that a correct summary?
Tim McHugh: Yeah, and I’d add simpler. We really wanted to simplify things: from the fare policy perspective as Rhyan mentioned.— which is we got rid of all the zones and went to a single fare.; also making it so the card is all you need. You don’t need to consider the multiple types of passes.
Aaron: Electronic fare card systems can speed up boarding, and that can improve operating speeds. Was that one of TriMet’s goals, and is that something that you’re tracking and is it a benefit you expect?
Rhyan: Yes, yes, and yes. We wrote into our specifications that our tap time needed to be less than a second. That includes from the time that the tap occurred, to the communication to the backend, to the signal back to the onboard validator [card reader] that gives the customer a green checkmark or red “X”.
Aaron: Got it. And of course, it’s still much faster than cash payment, even at 750 milliseconds, right?
Aaron: So TriMet operates the Hop system, right? Was there a discussion about that in the planning process? Because I think that there are some regions where there is an institution set up just for a regional fare card system.
Tim: We talked theoretically about those sorts of things when we were developing it, but for the way that the project was run, TriMet was the core. We were going to move ahead with the project to meet our own goals, regardless of partner agencies. It was an opt-in from C-TRAN and Streetcar where they were free to participate as much or as little as they wanted. Then there was figuring out how the financial arrangements worked.
Rhyan: Right. Our backend has a revenue sharing process. The revenue that’s shared in the backend is all calculated automatically based on taps.
Aaron: So I’m imagining that Streetcar and C-TRAN were probably delighted to have TriMet take care of this difficult technical problem for them.
Rhyan: Yes, I think they were. I also think it’s important that TriMet not only manage the design, development, and implementation of the project, but now we’re managing the operations of it as we get more into this mobility-as-a-service concept. I think it’s more and more important that the public sector remain in control of these systems to ensure that access to them is delivered in an equitable fashion. This is not something we can necessarily cede over to private company. You have to maintain that oversight.
Aaron: It’s really startling how long it takes to transition to new fare payment technologies for every transit agency that undertakes such a project. What expectations do you have on how many years this transition will take?
Rhyan: We started in 2017. We should be primarily done transitioning customers by the end of 2018, with the one exception being our institutional customers and maybe also our paratransit customers. Those integrations will take a bit longer. I should mention that we don’t currently have any plans to stop accepting cash at TVMs and on busses. But we should be transitioned off of paper fare media for individual customers by the end of 2018.
Opportunities to Analyze Traveler Needs
Aaron: What are you expecting to be able to learn and accomplish through the analysis of customer behaviors with the new fare card system?
Rhyan: I would say there are definitely some insights in service planning. We do tap-on only. We don’t tap-off. So it limits the richness of our data somewhat, but it still is a much more rich dataset than anything we were ever able to use before when we were just using our passenger counters and onboard survey results. Tim, you might have some more insight into that.
Tim: Ideally, we could restructure the entire service around how people really move, in ways that are less influenced by where our buses are. That would be the ideal goal. We are looking to combine the tap data we are getting with other data in the region outside of TriMet (city data, ODOT data) under another project.
Aaron: And Hop has the capability of being extended to other modes eventually, which would mean that it would be possible to get a bigger view of multimodal customer traveler behavior, right?
Tim: Hop gives us the mechanism to tie together multiple modes from the payment perspective. That ties into what happens in a truly multimodal transportation experience, where you’re looking at the mobility-as-a-service type of environment. Hop is a component of that environment, but I don’t think it’s necessarily the center. You could think of it as your transit or transportation wallet, where you can fund and run all of the reciprocal arrangements for the multiple parties who are playing in that environment. Hop can be an engine for that.
Aaron: Tim, let’s turn to talk about the application architecture, the approach that you used to procure the components, and what kinds of opportunities are open in the future.
Tim: Sure. As Rhyan mentioned, the base was to have a core backend that was fully functional. There was a lot of making sure that the financial management pieces were in place. In the past, fare systems would have their own account tracking mechanisms that really didn’t fit the needs for the accounting department and all the reporting that needed to take place.
Aaron: When you talk about the core backend, I’m imagining that as the system of accounts, right?
Tim: Right. So the structure in the backend is centered around the customer. Customers have accounts to log into the Hop website and mobile app, and within that account, they have what’s referred to as a transit account, which is tied to the individual person who will be using it. There is a 1-to-1 association between the “transit account” and a “Fare Media Account.” Because of fare capping, only one individual should use a farecard, as opposed to sharing cards for a family. In that case, one Customer Account would be used to manage separate transit accounts for all family members.. Then, there are Agency Accounts, like TriMet and C-TRAN, so that providers can be paid for rides taken.
The fact that it’s an account-based system as opposed to the old smart card where the value is on the card is an important differentiation because of our ability to do everything in near real-time. For example, when a customer gets that card from a retail outlet and they load value. Before they walk to the bus stop, the value has to be there in the backend so when they tap the bus they get a green check.
Aaron: After the priorities were determined, how did you set the requirements for vendors? What were the requirements? Were there a few more steps involved before it got to the requirement setting phase?
Rhyan: We did a request for information as well. We not only surveyed other transit agencies, but we surveyed the vendors themselves. Then we compiled the responses with feedback from Q&A sessions with internal stakeholders. This informed a list of requirements that eventually made their way into our RFP and technical specification document. One of the most interesting things that we did was use a system integrator model based on open architecture. Which means that we hired a vendor, INIT, to write and design our backend account system and all of the APIs that could make that system available to other software and hardware. But we did not necessarily hire that vendor to do everything else. The typical transit model is you hire one vendor to provide the hardware, the software, and everything in between. We wanted to be able to choose the best in industry providers for each component. So, we hired a separate mobile app developer and a separate website developer. We hired people that really specialize in delivering a product to that specific customer. The open architecture means that we can marry any piece of hardware or software with our backend, as long as both parties are willing to use the same API. That was really the fundamental sea change for how we approached this project.
In a couple months, Scheidt & Bachmann will get ticket vending machines talking to an INIT backend. These are two German firms that have historically been quiet proprietary. Our requirements forced them to open up and play together. This encourages more competition from a procurement standpoint. And because we’re using a vendor that specializes in customer interface and a different vendor that specializes in a backend, we also come out with a better product in the end.
Aaron: Right. And does that mean that there were separate procurement instruments or separate requests for proposals released for different systems?
Rhyan: There were. We had roughly 9 or 10.
System Architecture and Components
Aaron: Could you give a review of how you arrived at the different components, and then when you procured them how you ensured that they would work together? How were different procurement instruments set up to purchase each of the components?
Tim: Yeah, we focused on what the different endpoints are and what we would want to potentially replace down the road with something else. We didn’t want to get into this big monolithic system where you’re beholden to whatever device that the vendor wants. So our components consist of the mobile app, the website, and the validators. The validators are supplied by the same company that does the backend, but that doesn’t mean we can’t swap it out. In fact, we have had our own point of sale system at the ticket office downtown for a number of years, which is an open-source system that is highly customized. That was our proof-of-concept with the APIs. We really needed to make sure that we had working open APIs, not just hypothetical openness or lip-service. TriMet staff actually did the development against all of the APIs as kind of “eating our own dog food” concept that we can keep the vendor honest. A really important part of the negotiation with the backend developer was that we can bring on another system without talking to them. There isn’t an additional license fee. There isn’t an additional anything if we want to add another interface to it. We have the documentation to the APIs. We can just develop it. That was an important consideration for us.
Aaron: Were other vendors successfully able to interact with the backend account system?
Was moovel able to use that system?
Tim: Yes, they all do. moovel has interfaced with it for creating the app. They also provide the devices for the fare inspectors to go out there and tap a card. It’s been very successful.
In terms of project implementation, enforcing a complete, functional, and well-documented API has probably been the most difficult part. Had we to do it over again, we probably would have adjusted the schedule and gotten all that ironed out without having the other vendors trying to do development at the same time. So there were some bumps in terms of getting those APIs working well for all of the different players.
Aaron: And I would imagine that there was a fair amount to think about in terms of security ,too — making sure that all applications are authorized to access those accounts.
Tim: Yeah, those APIs are all protected through security. Security is a big part of this system.
Aaron: Is INIT planning to offer this system, or similar open architecture systems, to other transit agencies? Or are other transit agencies asking for this?
Tim: Yeah, they definitely are. Whether it be INIT or others. I think the model of account-based systems is what everybody else is moving to. Everybody is moving this way.
Aaron: Are there any other components that you think need to be talked about? Any crucial choices that were made during procurement, etc?
Tim: The virtual card is a big deal. It’s a card that is in the Google Pay wallet so that you don’t need that physical card. Physical cards are a big thing to manage. The extent that you can limit the need to manage them is much better for everybody.
Aaron: So how does that work? Do I buy a virtual fare card and load it on my phone? Or do I create a digital alias of my existing physical fare card? Do I use the moovel app? I haven’t used this myself so I’m curious how it works.
Tim: There’s multiple ways you can enact it. Through the moovel app is one way. But think of it in the same way that you would add your airline boarding pass to your mobile wallet. It’s a similar type of thing.
Aaron: Will it essentially work like a physical card? Does that mean that I just put my Android phone over the sensor?
Aaron: Do I have to have an app open or anything to make that payment work?
Tim: No. Using the card is app-less. It’s a part of the native Android. Google is doing this. This is the first time in the world that they’ve done this. You do need an app to get the card, but once it’s in the wallet, its app-less.
Rhyan: In addition to all of the components that we just discussed, one other important component is our retail network. That is actually one of the most exciting pieces, especially for the other Oregon transit agencies. We partnered with Ready Credit, who manages a network of gift card providers. So riders can buy a Hop card at any of the major grocery stores or convenience stores in the Portland region. Riders can then go back into these stores and load value to that card just like you would a Starbucks card, a McDonalds card, etc. That has really been the gateway to get cash-paying customers into Hop. We started with 150 different retail store locations, and we are almost at 500 different locations now. This is something we are so excited about because, though right now it is just the Portland region, it would be very easy to expand this since we have partners like Fred Meyer, Safeway, 7-Eleven and Plaid Pantry. It would be relatively easy to make this Portland regional system a statewide system.
Aaron: I imagine that the retail network provides greater convenience and access and also is meant to serve the equity goal of making this fare payment system available to all users. Right? Has that been successful? It sounds like you have tremendous uptake in the retail network. Is that translating to uptake by customers from all demographic groups?
Rhyan: Fare capping and the expanded retail network does provide increased equity and access for our customers. I think it’s been challenging because our larger retailers still carry paper. But we’ll transition our retail network off of paper towards the end of summer.
Aaron: Is the documentation for the backend interfaces available anywhere? Do you think that could or will become the basis for future standardization of electronic fare payment?
Tim: I think it definitely could. It’s certainly a start. I think we need to look at what the other modes and methods of interfacing with those APIs are, as well as standardization between all APIs. Uber, Lyft, TriMet: how are all those APIs laid out? Those are different payment models too. TriMet is loading funds upfront and then decrementing those funds as the customer boards and taps, whereas Uber or Lyft receive payment at the end of a trip. How does that work seamlessly for the customer when they use these services in combination? And of course, subscription models for those modes are beginning to be available as well. The backend systems need to be able to handle all of those different variations in making requests and transferring funds.
Aaron: And there are systems like paratransit or car-share where you might be reserving service, purchasing a specific trip, or requesting access to a vehicle in advance…
Tim: Yeah. Hop is really kind of an engine on the backend that enables all of that. One of the real strengths with the INIT backend is tracking all of the complexities of the reciprocal arrangements. Reconciling all of the taps and who gets what is quite complicated, and that’s with our simplified fares. Some other cities would have even more.
Aaron: You talk about the work you’ve done to tokenize customers and fare instruments. Is there an opportunity somewhere to be able to issue digital tickets that can be exchanged amongst people — a sort of digital currency that’s good for travel? I see the opportunity there as enabling the involvements of additional kinds of resellers, retailers, and aggregators, so that a TriMet ticket or access to carshare could be bundled in a travel package.
Tim: Yes, you can use Hop as a foundation for enabling those types of opportunities We have the capability there for packages that get funded in different ways and to be used for specific kinds of trips. There’s nothing preventing extending it to digitally fund other uses such as parking, bikeshare, getting coffee, or whatever you want.
Aaron: What’s next on the horizon?
Rhyan: We are really interested in partnering with agencies like ODOT and with other transit properties.
Aaron: Cool, and what about car-share, like car2go and ReachNow, and bike-share?
Rhyan: Yeah, bike-share is definitely on the list, as are those others.
Aaron: I think the virtual card is a great example of people using their phone to understand and then actually use transit. Do you see a trajectory further in that direction, where there will be interoperability between a trip planner [such as TriMet’s Shared-Use Mobility OpenTripPlanner project, the planned update to maps.trimet.org] or another customer information app and a ticketing app? At some point in the future would I be able to plan a trip in Google Maps or the Transit app and then tap “Buy” to load a ticket right into my phone’s wallet?
Tim: That definitely is the intent. Obviously, a lot of things have to happen between now and then. But, yes — the vision is that the traveler can plan their trip, book and pay for it, and then track vehicles over the course of the trip.
Aaron: And to get into some of the technical practicalities and possibilities — Do the secure APIs for your backend system provide a mechanism where there could be other client applications, like a generic third-party transit app that’s able to make a transit purchase on behalf of the end user?
Tim: Yes. The key to all that is just identifying who you are. In my view, it’s coming up with a universal identifier, so that no matter where you go, that tokenized representation of yourself is used to identify you to the different payment apps. So you could go through a different transit app and say, “This is who I am.” The most mind-boggling part of this whole project has been the multiple tokenized IDs. We have to have all systems agree that a tokenized ID represents the same person. Solving that technical hurdle, we definitely can open up the API to anybody who wants to transfer funds.
Aaron: Have you had discussions about this with any of the third party app providers?
Tim: We haven’t involved third-party transit information apps in the payment pieces.
Aaron: Have any companies come to you interested in that, saying “We’d like to look into in that in the future?”
Tim: Yes, definitely!