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 9
Introduction 9
The primary characteristic of this architecture is the disaggregation of payment from the rid-
ership information. Similar to a retail transaction where the cash register calculates the sale, the
faregate or farebox conducts the sale. The amount of the sale is transmitted to a POS terminal
that processes the card payment. The terminal notifies the cash register when the payment is
completed. At this point in the transit world, the faregate opens or the appropriate signal acti-
vates or a message displays on the farebox. The application of business rules to provide fare cal-
culation could be accomplished by central server equipment at the agency or region as an offline
process at an end-of-day period. Once calculated, an aggregate transaction could be sent to a
bank representing a cardholder's transit costs for that day.
The disaggregation of payment from the ridership information collection is an intermediate
step in the evolution to open interoperability for fare payment. The key challenge for making this
configuration a reality is the cooperation of the supplier community. As subsequently discussed
in the Financial Services Industry Interoperability Issues section of this document, the supplier
community for the financial services industry has developed readers that can accommodate mul-
tiple contactless payment products. If transit adopts this model, most of the data interoperabil-
ity concerns discussed in this document are alleviated by moving from a data-rich stored-value
transit application to the simple recording of a bankcard presentation.
1.5.2 Multiple Closed Stored-Value Payment Products
Closed stored-value products are becoming an increasingly attractive means to create loyal
customer relationships. In the retail environment, coffee shops such as Starbucks and Peet's issue
closed-account-based stored-value cards. Sports venues are also beginning to recognize the ben-
efits of a contactless stored-value payment media. Two parts are required to create interoper-
ability between disparate closed stored-value systems:
· The need to read participants' cards or payment media and
· Agreement on how settlement will occur.
First, each participant must have a reader that can read the respective cards. The readers must
be able to generate a transaction record with sufficient payment data, including time and date,
purchase amount, and transaction location. Second, no complex transaction processing system
is needed to conduct settlement between two disparate stored-value payment systems. If two
closed stored-value payment system operators agree to accept each other's media and the read-
ers can read each payment medium, settlement may occur by using the data collected by each
system, as long as the participants trust the integrity of the transaction data generated. This type
of arrangement is a referred to as a "trust model," because it requires participants to trust the
integrity of the transaction data.
The trust model can create interoperability with less technical complexity and can work with
most technologies or different combinations of technologies. The trust model may be used by
two or more participants. The transportation council of the Smart Card Alliance has a project
under way that would establish a trust model for use in clearing transactions between multiple-
party closed-payment systems.
1.5.3 Multiple Payment-Enabled Devices
There are two configurations of payment-enabled devices:
· Transit-enabled contactless chips embedded into devices and
· Devices with transit application (software) that communicates with the reader in a non-ISO-
14443-compliant mode (e.g., Bluetooth, 802.11, or infra-red).
