DOI: 10.5061/dryad.9p8cz8wnv
title: Transit agencies want open payments but there are challenges

description: This study explores interest in, and the challenges faced by transit
 agencies and operators in the adoption of open-loop payment systems. The
 research team focuses in particular on the ways that agencies view
 passenger needs in the context of adopting open payments. Challenges with
 cash payments, an increasingly cashless society, and the expanding
 offerings of digital payment options have spurred increased interest in
 open-loop payments among transit operators. Paying for transit with cash
 can require additional time at boarding, add extra steps for passengers
 who must pay with exact fare, and result in service inefficiencies. It
 presents security concerns for drivers, and administrative burdens for
 agencies. While the full costs of cash handling vary per agency the cost
 of handling and moving cash may be considerable. Pioneering transit
 agencies are adopting open payment systems that accept credit cards, debit
 cards, and smartphone/watch-based transactions. However, there is a huge
 diversity among transit agencies and as such, agencies face different
 challenges and to different degrees, when considering the adoption of open
 payment systems. Challenges can include financial barriers, capacity
 limitations, technological challenges, the duration of existing contracts,
 competing needs, and a number of passenger challenges such as lack of
 credit cards or smartphones. This study uses data collected from
 California transit agencies in the fall of 2022 that gathered information
 about agency perceptions of open-loop payments and the challenges with
 adopting open fare collection systems, and whether assistance programs
 would benefit transit agencies interested in adopting open-loop payments.
 Even before the pandemic prompted agencies to consider open and
 contactless payments, many agencies were exploring this option. Results of
 the present study indicate that the majority of agencies are considering
 or have considered implementing open payment systems, but agencies are not
 fully aware of the assistance available from the California Integrated
 Travel Program to help in the transition to digital and open payment
 systems. Key challenges include the cost, as well as the technical needs
 to implement open payments. Agencies also cited passenger familiarity with
 technology and ability to have a bank account as potential hurdles. This
 study sheds light on the challenges facing small to medium transit
 agencies in the transition of California’s transit systems to open-loop
 payment systems.
description: This data was collected through an online survye of transit
 agencies; the survey was administered using Qualtrics and the data was
 downloaded from the Qualtrics platform as a .csv file.
 The full question text as it appeared in the survey is included
 in the Codebook. Additional questions containing
 identifying information or information that has not yet been analyzed was
 removed from the data prior to publishing. 
description: This README Open loop payments for transit.txt file was generated on
 2023-8-14 by Susan Pike GENERAL INFORMATION 1. Title of Dataset: Open loop
 payments for transit 2. Author Information A. Principal Investigator
 Contact Information Name: Susan Pike Institution: University of
 California, Davis Email: scpike@ucdavis.edu 3. Date of data collection:
 October and November 2022 4. Geographic location of data collection:
 Davis, California through online survey of California transit agencies 5.
 Funding sources that supported the collection of the data: National Center
 for Sustainable Transportation through the University of California, Davis
 SHARING/ACCESS INFORMATION 1. Licenses/restrictions placed on the data:
 none 2. Links to publications that cite or use the data: none as of August
 2023 3. Recommended citation for this dataset: Pike, Susan (2023), Open
 loop payments for transit, Dryad, Dataset DATA & FILE OVERVIEW 1.
 File List: Open loop payments for transit.csv Codebook Open loop payments
 for transit.csv 2. Additional related data collected that was not included
 in the current data package: the survey included information that is not
 included here covering transit agency discounts and use of GTFS, the
 Global Transit Feed Specification. This data will be made publicly
 available once it has been analyzed and the results published 3. There are
 not multiple versions of this dataset. METHODOLOGICAL INFORMATION 1.
 Description of methods used for collection/generation of data: This data
 was collected through an online survye of transit agencies; the survey was
 administered using Qualtrics and the data was downloaded from the
 Qualtrics platform as a .csv file. The full question text as it appeared
 in the survey is included in the Codebook. 2. Methods for processing the
 data: The data was minimally processed prior to publishing. String values
 have not been recoded into numeric values, except for in "check all
 that apply" survey responses, which were coded automatically, as
 follows: the response item that was checked is in the data as the text
 appeard in the survey.For example, if the question asked what types of
 services does your agency operate (check all that apply). For the variable
 agency.mode.bus, an entry of "Bus" indicates the agency operates
 bus, and an entry of "0" indicates they do not. This is true for
 all variables in the dataset that are derived from select all that apply
 type survey questions. Where questions were skipped an NA is entered. NA
 is different from "0". NA means the question was skipped and is
 a true missing value. A "0" corresponds to a not checked
 response, or a "no" response. When a respondent checked one item
 from a list, the not checked items are coded as "0". If a
 respondent did not check any items on a list, they are recoded as NA (they
 skipped the entire question). Note that NA is also entered in appropriate
 skips - i.e. text entry fields where the respondent did not select
 "Other", and therefore was not asked to provide an entry. Text
 entry responses are modified in the pubicly available data as some
 resondents entered identifying information in these fields. If teh name of
 the agency was entered, or the city within which they operate, these were
 removed from the text responses. 3. There is no instrument- or
 software-specific information needed to interpret the data. 4.
 Environmental/experimental conditions: Survey data were collected through
 an online platform. Participants could take the survey at any time and at
 any location they had access to an internet connection. 5.
 Quality-assurance procedures performed on the data: the data were reviewed
 for incomplete and duplicate resopnses DATA-SPECIFIC INFORMATION FOR:
 Transit payment perferences of unbanked passengers Sheet 1: 1. Number of
 variables: 161 2. Number of cases/rows: 21 3. Missing data codes: missing
 data is coded as NA. this includes appropriately skipped questions.
 unchecked options from a list are coded as 0 4. Variable List: Variables
 are listed as follows - the variable name, followed by a colon: a
 description of the variable and in parentheses the (possible values)
 new.id: id assigned to respondent agency.type: type of area served by
 agency (rural, suburban, etc.) agency.type.otxt: if other entered in
 agency.type, text entry agency.fleet.size: number of vehicles in fleet
 agency.mode.bus: has bus as a service type (yes/no) agency.mode.light: has
 light rail as a service type (yes/no) agency.mode.heavy: has heavy rail as
 a service type (yes/no) agency.mode.paratransit: has paratransit as a
 service type (yes/no) agency.mode.ferry: has ferry as a service type
 (yes/no) agency.mode.on: has on demand as a service type (yes/no)
 agency.mode.other: has another mode as a service type (yes/no)
 agency.mode.otxt: text entry for other mode/service type methods.cash:
 accepts payment type - cash (yes/no) methods.credit: accepts payment type
 - credit (yes/no) methods.debit: accepts payment type - debit card
 (yes/no) methods.ach: accepts payment type - ach debit (yes/no)
 methods.check: accepts payment type - check (yes/no) methods.other:
 accepts payment type - another form of payment (yes/no) methods.otxt: text
 entry for other payment type where.cash.tc.all: cash accepted at all
 transit centers (yes/no) where.cash.tc.some: cash accepted at some transit
 centers (yes/no) where.cash.online: cash accepted online (yes/no)
 where.cash.office: cash accepted at agency office (yes/no)
 where.cash.business: cash accepted at local business (yes/no)
 where.credit.tc.all: credit accepted at all transit centers (yes/no)
 where.credit.tc.some: credit accepted at some transit centers (yes/no)
 where.credit.online: credit accepted online (yes/no) where.credit.office:
 credit accepted at agency office (yes/no) where.credit.business: credit
 accepted at local business (yes/no) where.debit.tc.all: debit accepted at
 all transit centers (yes/no) where.debit.tc.some: debit accepted at some
 transit centers (yes/no) where.debit.online: debit accepted online
 (yes/no) where.debit.office: debit accepted at agency office (yes/no)
 where.debit.business: debit accepted at local business (yes/no)
 where.ach.tc.all: ach debit accepted at all transit centers (yes/no)
 where.ach.tc.some: ach debit accepted at some transit centers (yes/no)
 where.ach.online: ach debit accepted online (yes/no) where.ach.office: ach
 debit accepted at agency office (yes/no) where.ach.business: ach debit
 accepted at local business (yes/no) where.check.tc.all: check accepted at
 all transit centers (yes/no) where.check.tc.some: check accepted at some
 transit centers (yes/no) where.check.online: check accepted online
 (yes/no) where.check.office: check accepted at agency office (yes/no)
 where.check.business: check accepted at local business (yes/no)
 where.other.tc.all: other payment method accepted at all transit centers
 (yes/no) where.other.tc.some: other payment method accepted at some
 transit centers (yes/no) where.other.online: other payment method accepted
 online (yes/no) where.other.office: other payment method accepted at
 agency office (yes/no) where.other.business: other payment method accepted
 at local business (yes/no) where.other.otxt: text entry for other payment
 location interface.smarttap: phone/watch fare payment interface accepted
 at boarding (yes/no) interface.smart: in-app phone/watch fare payment
 interface accepted at boarding (yes/no) interface.cardtap: agency issued
 tap card fare payment interface accepted at boarding (yes/no)
 interface.cardswipe: agency issued magnetic stripe card fare payment
 interface accepted at boarding (yes/no) interface.cardpunch: agency issued
 passes (paper/punch card) fare payment interface accepted at boarding
 (yes/no) interface.credittap: credit/debit card tap to pay fare payment
 interface accepted at boarding (yes/no) interface.creditswipe:
 credit/debit card swipe fare payment interface accepted at boarding
 (yes/no) interface.token: tokens fare payment interface accepted at
 boarding (yes/no) interface.cash: cash fare payment interface accepted at
 boarding (yes/no) interface.other: other fare payment interface accepted
 at boarding (yes/no) interface.otxt: text entry for otherh fare payment
 interface accepted at boarding (yes/no) load.onboard: load agnecy issued
 cards on board (yes/no) load.somerail: load agnecy issued cards on board
 (yes/no) load.allrail: load agnecy issued cards at all rail stations
 (yes/no) load.somebus: load agnecy issued cards at some bus stops (yes/no)
 load.allbus: load agnecy issued cards at all bus stops (yes/no)
 load.business: load agnecy issued cards at local businesses (yes/no)
 load.office: load agnecy issued cards at agency office (yes/no)
 load.online: load agnecy issued cards online (yes/no) load.app: load
 agnecy issued cards in app (yes/no) load.other: load agnecy issued cards
 at another location (yes/no) load.otxt: text entry for load agnecy issued
 cards at another location (yes/no) open.implement: stage of implementation
 of open loop payments: 1 Yes, we have implemented open payments 2 Yes, we
 are in the process of implementing open payments 3 No, but we are
 currently considering it 4 No, but we have considered it 5 No, we have not
 considered it open.chal.cost: cost a challenge for open payments
 implementation (yes/no) open.chal.equip: equipment installation a
 challenge for open payments implementation (yes/no) open.chal.staff: staff
 capacity a challenge for open payments implementation (yes/no)
 open.chal.contract: existing contract a challenge for open payments
 implementation (yes/no) open.chal.interest: lack of customer interest a
 challenge for open payments implementation (yes/no) open.chal.ability:
 lack of customer ability to adopt a challenge for open payments
 implementation (yes/no) open.chal.backend: backend payment infrastructure
 a challenge for open payments implementation (yes/no) open.chal.discount:
 discount eligibility verification a challenge for open payments
 implementation (yes/no) open.chal.continuity: continuity of discounts a
 challenge for open payments implementation (yes/no) open.chal.laws:
 federal/state laws or policies a challenge for open payments
 implementation (yes/no) open.chal.region: regional coordination a
 challenge for open payments implementation (yes/no) open.chal.liability:
 increased liability a challenge for open payments implementation (yes/no)
 open.chal.fraud: fraud a challenge for open payments implementation
 (yes/no) open.chal.evasion: fare evasion a challenge for open payments
 implementation (yes/no) open.chal.privacy: passenger privacy a challenge
 for open payments implementation (yes/no) open.chal.safety: passenger
 safety a challenge for open payments implementation (yes/no)
 open.chal.tech: technological complexity a challenge for open payments
 implementation (yes/no) open.chal.other: something else is a challenge for
 open payments implementation (yes/no) open.chal.otxt: text write in for
 something else a challenge for open payments implementation (yes/no)
 open.top.cost: cost one of top three challenges for open payments (yes/no)
 open.top.equip: equipment installation one of top three challenges for
 open payments (yes/no) open.top.staff: staff capacity one of top three
 challenges for open payments (yes/no) open.top.contract: existing contract
 one of top three challenges for open payments (yes/no) open.top.interest:
 lack of customer interest one of top three challenges for open payments
 (yes/no) open.top.ability: lack of customer ability to adopt one of top
 three challenges for open payments (yes/no) open.top.backend: backend
 payment infrastructure one of top three challenges for open payments
 (yes/no) open.top.discount: discount eligibility verification one of top
 three challenges for open payments (yes/no) open.top.continuity:
 continuity of discounts one of top three challenges for open payments
 (yes/no) open.top.laws: federal/state laws or policies one of top three
 challenges for open payments (yes/no) open.top.region: regional
 coordination one of top three challenges for open payments (yes/no)
 open.top.liability: increased liability one of top three challenges for
 open payments (yes/no) open.top.fraud: fraud one of top three challenges
 for open payments (yes/no) open.top.evasion: fare evasion one of top three
 challenges for open payments (yes/no) open.top.privacy: passenger privacy
 one of top three challenges for open payments (yes/no) open.top.safety:
 passenger safety one of top three challenges for open payments (yes/no)
 open.top.tech: technological complexity one of top three challenges for
 open payments (yes/no) open.top.other: something else one of top three
 challenges for open payments (yes/no) open.top.otxt: text write in for
 something else one of top three challenges for open payments (yes/no)
 open.efficiency: agreement with open payments would improve operational
 efficiency (Strongly disagree, Disagree, Neither agree nor disagree,
 Agree, Strongly agree, Don't know ) open.meetsneeds: agreement with
 open payments would not meet passenger needs (Strongly disagree, Disagree,
 Neither agree nor disagree, Agree, Strongly agree, Don't know )
 open.transfer: agreement with open payments would help passengers transfer
 (Strongly disagree, Disagree, Neither agree nor disagree, Agree, Strongly
 agree, Don't know ) open.robbery: agreement with open payments would
 increase risk of passenger robbery (Strongly disagree, Disagree, Neither
 agree nor disagree, Agree, Strongly agree, Don't know )
 open.savemoney: agreement with open payments would save the agency money
 (Strongly disagree, Disagree, Neither agree nor disagree, Agree, Strongly
 agree, Don't know ) open.discount: agreement with open payments would
 improve discount eligibility verification (Strongly disagree, Disagree,
 Neither agree nor disagree, Agree, Strongly agree, Don't know )
 open.privacy: agreement with open payments would persent data privacy
 concerns (Strongly disagree, Disagree, Neither agree nor disagree, Agree,
 Strongly agree, Don't know ) open.modes: agreement with open payments
 would be difficult to implement across modes (Strongly disagree, Disagree,
 Neither agree nor disagree, Agree, Strongly agree, Don't know )
 open.senti.planners: support for open payments among agency planners
 (Strongly supports, supports, Neutral, Does not support, Strongly does not
 support) open.senti.board: support for open payments among the
 agency's board (Strongly supports, supports, Neutral, Does not
 support, Strongly does not support) open.senti.ops: support for open
 payments among the agency's operations team (Strongly supports,
 supports, Neutral, Does not support, Strongly does not support)
 open.senti.it: support for open payments among the agency's IT team
 (Strongly supports, supports, Neutral, Does not support, Strongly does not
 support) open.senti.reg: support for open payments among regular
 passengers (Strongly supports, supports, Neutral, Does not support,
 Strongly does not support) open.senti.irreg: support for open payments
 among infrequent passengers (Strongly supports, supports, Neutral, Does
 not support, Strongly does not support) open.senti.local: support for open
 payments among local government (Strongly supports, supports, Neutral,
 Does not support, Strongly does not support) open.senti.cbo: support for
 open payments among local community organizations (Strongly supports,
 supports, Neutral, Does not support, Strongly does not support)
 cash.barriers.familiarity: lack of familiarity would prevent passengers
 from transitioning to cashless payment (yes/no) cash.barriers.interest:
 lack of finterest would prevent passengers from transitioning to cashless
 payment (yes/no) cash.barriers.needs: not fitting needs of passengers
 would prevent passengers from transitioning to cashless payment (yes/no)
 cash.barriers.trust: lack of agency trust would prevent passengers from
 transitioning to cashless payment (yes/no) cash.barriers.trustother: lack
 of trust in data collecting entities would prevent passengers from
 transitioning to cashless payment (yes/no) cash.barriers.budget:
 preference for cash as budgeting tool would prevent passengers from
 transitioning to cashless payment (yes/no) cash.barriers.privacy:
 preference for cash due to privacy would prevent passengers from
 transitioning to cashless payment (yes/no) cash.barriers.obtain:
 challenges obtaining a bank account would prevent passengers from
 transitioning to cashless payment (yes/no) cash.barriers.lackaccount: lack
 of bank account would prevent passengers from transitioning to cashless
 payment (yes/no) cash.barriers.other: another reason would prevent
 passengers from transitioning to cashless payment (yes/no)
 cash.barriers.otxt: text entry, another reason would prevent passengers
 from transitioning to cashless payment (yes/no) cash.top: top reason
 passengers may be prevented from transitioning away from cash
 cash.top.otxt: top reason is other reason and selected cash.txt:
 additional comments (text entry) calitp.top.data: top three ways cal-itp
 can help with open payments - shared tools for data management
 calitp.top.payment: top three ways cal-itp can help with open payments -
 shared tools for payment management calitp.top.procure: top three ways
 cal-itp can help with open payments - procurement cost-sharing
 calitp.top.specs: top three ways cal-itp can help with open payments -
 sample contract specifications calitp.top.operations: top three ways
 cal-itp can help with open payments - quantifying operational benefits
 calitp.top.pilot: top three ways cal-itp can help with open payments -
 pilot program funding calitp.top.other: top three ways cal-itp can help
 with open payments - another reason calitp.top.otxt: top three ways
 cal-itp can help with open payments - another reason text
 calitp.fam.gtfsrt: familiarity with cal-itp assistance with gtfs real time
 (yes/no) calitp.fam.discount: familiarity with cal-itp assistance with
 automating discoutne eligibility verification (yes/no)
 calitp.fam.standards: familiarity with cal-itp assistance with operational
 data standards (yes/no) calitp.fam.msa: familiarity with cal-itp
 assistance with master service agreements (yes/no) calitp.fam.procure:
 familiarity with cal-itp assistance with procurement (yes/no)
 calitp.fam.none: familiarity with cal-itp assistance with none of the
 above (yes/no) calitp.gtfsrt: use of cal-itp assistance with gtfs real
 time (Not interested in this service, Would like more information about,
 Have not used, but would like to) calitp.discount: use of cal-itp
 assistance with automating discount eligibility verification (Not
 interested in this service, Would like more information about, Have not
 used, but would like to) calitp.standards: use of cal-itp assistance with
 operational data standards (Not interested in this service, Would like
 more information about, Have not used, but would like to) calitp.msa: use
 of cal-itp assistance with master service agreements (Not interested in
 this service, Would like more information about, Have not used, but would
 like to) calitp.procureassist: use of cal-itp assistance with procurement
 (Not interested in this service, Would like more information about, Have
 not used, but would like to) info.position: what position does the
 participant ahve at the agency (text entry)