National Academy of Sciences | 150 Year Anniversary

Questions? Call 800-624-6242

| Items in cart [0]

The National Academies Press

Rights & Permissions

topleft topright

TCRP Report 115: Smartcard Interoperability Issues for the Transit Industry (2007)
Transit Cooperative Research Program (TCRP)

Citation Manager

Transportation Research Board. "1.5.1 Acceptance of Contactless Bank Cards." TCRP Report 115: Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press, 2007.

Please select a format:

BibTeX EndNote RefMan


Page
7
bottomleft bottomright
Page
7
Front Matter (R1-R9)
Summary (1-2)
Chapter 1 - Introduction (3-3)
1.2 Elements of Fare Payment Interoperability (4-4)
1.3 Interoperability Across Regions (5-5)
1.4 Interoperability Beyond Transit (6-6)
1.5.1 Acceptance of Contactless Bank Cards (7-8)
1.5.3 Multiple Payment-Enabled Devices (9-9)
1.6 Hypothetical Examples - Interoperability Between WMATA and TransLink (10-10)
1.6.1 Information to Be Exchanged for Payment (11-12)
1.6.3 Process for Determining the Net-Settlement Position (13-13)
2.1 Management and Organizational Issues (14-14)
2.1.1 Establishing a Governing Body or Project Sponsor (15-16)
2.1.2 Identifying and Mitigating Operational Differences (17-17)
2.1.3 Establishing a Framework for Program Funding (18-18)
2.1.4 Creating a Rollout Schedule (19-19)
2.1.5 Developing a Contracting Strategy (20-21)
2.2.2 Funds Pool Management (22-22)
2.2.3 Financial Exposure and Risk Associated with Advanced Features (23-23)
2.3.2 New Processes (24-24)
2.4 Equipment Design Issues (25-25)
2.5.2 Supplier Behavior (26-26)
2.5.3 Supplier Compliance with Available Standards (27-27)
Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs (28-28)
3.1.1 SmarTrip (29-33)
3.1.2 TransLink (34-34)
3.1.3 Chicago Card (35-35)
3.1.4 Central Puget Sound Regional Fare Coordination (RFC) Project (36-36)
3.1.5 Go-To Card (37-37)
3.1.6 Orlando Regional Alliance for Next Generation Electronic Payment System (ORANGES) (38-38)
3.1.7 Go Ventura (39-39)
3.1.8 Transit Access Pass (TAP) (40-40)
3.1.9 Compass (41-41)
3.1.10 Octopus (42-42)
3.1.11 EZ-Link (43-43)
3.1.12 Oyster (44-44)
3.2.1 Commonalities and Differences (45-46)
3.2.2 Current Trends and New Developments (47-47)
3.4.2 SmarTrip (48-48)
3.5 Summary (49-50)
4.1 Industry Interoperability Analysis (51-51)
4.2.1 Physical Layer (52-56)
4.2.2 Data Layer (57-59)
4.2.3 Application Layer (60-60)
4.2.4 Security Layer (61-66)
4.3 Gap Analysis (67-68)
5.1 Development of Conceptual Fare Payment System Architecture (69-69)
5.2 Identification of the Data Types (70-70)
5.3.2 Operation Data Flows (71-73)
6.1 Scope of the Data-Management Policy (74-74)
6.2.1 Data Location (75-75)
6.3 Identification of Stakeholders and Their Roles and Responsibilities (76-76)
6.4 Other RequirementsPrivacy (77-77)
6.5 Current Trends (78-78)
7.1 Use of Standard API in Proof of Concept (79-82)
7.2 Development of AFC Simulator (83-84)
7.3 Demonstration (85-85)
7.4 Conclusion (86-86)
Chapter 8 - Conclusions (87-91)
Appendix A - Set of Functionality for a Standard API (92-99)
Abbreviations used without definitions in TRB publications (100-100)

Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 7
Introduction 7 Table 2. Shared application structure. Transit Application Functions Purse (Pre-Tax $) Transit Products Transit Benefits Characteristics Shared Value Identification Trip Data Purse Card · Procedures for exchanging data, and · Processes for clearing transactions. The primary reason interoperability has not proliferated beyond transit is the proprietary nature of fare payment systems. Proprietary point of sale (POS) terminals purchased from an automatic fare collection (AFC) supplier for a retail application cost too much for a small mer- chant to acquire (i.e., approximately $1,200 to over $5,000 per unit). 1.5 Evolution of Interoperability with Open Payment Systems Now that financial institutions are implementing contactless payment products, a baseline architecture may be used to begin developing an interoperability strategy for transit with open payment systems. Given the recent activities associated with the financial institutions migrat- ing their credit and debit card product offerings to contactless smartcards, the following sce- narios for interoperability begin to emerge: · Acceptance of contactless bank cards on buses and at faregates, · Two or more transit entities arrange to accept each others' closed stored-value payment prod- ucts, and · Acceptance of multiple-payment-enabled devices. To determine the interoperability requirements with an open payment system, the charac- teristics of the existing transit payment architecture need to be identified. Currently, all fare collection systems combine payment with the fare calculation into a single application, and payment is embedded in every layer of the system. This type of architecture substantially increases fare system complexity, and allows equipment suppliers to control the application software. Figure 3 illustrates a current conceptual fare payment system architecture. 1.5.1 Acceptance of Contactless Bank Cards As contactless credit cards proliferate, transit agencies become increasingly attractive cus- tomers for financial institutions. The most likely relationship that will emerge between the finan- cial institutions and transit agencies is similar to a merchant in the retail space. Under this type of relationship, transit agencies accept a bankcard for transit fare payment and pay a transaction processing fee to the financial institutions. The key issue is that the bankcard data structure is not designed for conducting fare calculations. Therefore, two baseline system architecture configu- rations emerge for using a bankcard to pay a fare: · Transit and credit card applications both reside on the same chip or · The credit card application only resides on a contactless chip.

OCR for page 8
8 Smartcard Interoperability Issues for the Transit Industry Ridership and payment data Sales and payment data Payment Figure 3. Current conceptual fare payment system architecture. The transit application residing with a credit card application on the same chip has been the vision for smartcards since the early 1990s. Though technically feasible, the institutional barriers still make this configuration economically infeasible. However, using a contactless credit card prod- uct for fare payment is technically feasible in a cost-effective manner if some of the institutional constraints can be modified. The architecture for this configuration is illustrated in Figure 4. Payment data Ridership data Sales and payment data Payment Payment Figure 4. Disaggregation of payment from ridership and fare calculation.