Processing transactions of different payment devices of the same issuer account

(54) Title: METHOD (57) Summary:

(30) Unionist Priority: 03/01/2007 us 11/681174,

01/30/2007 US 60/887307 (73) Holder (s): visa usa, inc.

(72) Inventor (s): Ayman A. Hammad, Khalid El-Awady, Phil Dixon (74) Attorney (s): Momsen, Leonardos & CIA.

(86) International Order: pct uS2007082842 of 29/10/2007 (87) International Publication: wo 2008 / 094324of 07/08/2008

<img file="BRPI0721202A2_D0001.tif" />

Network

310 "METHOD"

This order claims priority and benefit from US Serial Order No. 60 / 887,307, filed on January 30, 2007, entitled Contactless Bank Card Transit Payment, and US Serial Order No. 11 / 681,174, filed on March 1, 2007, entitled Delayed Transit Fare Assessment, the entire contents of each being hereby incorporated by reference.

BACKGROUND

The present invention generally relates to financial transactions, particularly for customers requesting financial transactions with commercial establishments, and more particularly for financial transactions conducted with a financial institution's portable payment device issued by a financial institution, such as a credit card. it can be used both in a retail transaction and in a transit fare transaction.

Portable payment devices can take many forms and be used in a wide variety of financial transactions. Portable payment devices may include, for example, smart cards, payment cards, credit cards, debit cards, stored value cards, contactless cards, prepaid cards, cell phones, Personal Digital Assistant (PDA) devices ), key chains, or smart cards. Financial transactions may involve, for example, retail purchases, transit fees, access to jurisdiction fees, etc. In all such transactions, portable payment device users (consumers) are concerned with convenience and the merchants with whom they do business are concerned with the ease of doing business with their customer-consumers.

Preferably, portable financial institution payment devices issued by a financial institution (FIPPD) are used online (for example, a service point that is connected to a payment processing system during a transaction). FIPPD information may be transmitted online to an issuer during a retail payment transaction for the purpose of authorizing the use of FIPPD for that transaction. The issuer may review transaction parameters such as transaction amount, credit history, card authenticity, and other factors when determining whether or not to authorize or decline the transaction.

However, some business transactions are not online such that FIPPD verification and authentication schemes are not readily accommodated. For example, the ability to go online in a transit environment such as a subway or bus system, or a jurisdictional access environment such as a stadium or concert hall, can be problematic because of the lack of communication in real time and lack of network systems for such environments. This is due in part to the need in such environments to process a transaction in approximately 300 ms, a transit system industry standard, and thereby allow access from 30 to 45 customers per minute in a transit system installation such as a subway or a bus. In addition, a bus on a bus route across the road may not have wireless or other communication systems to allow any real-time dialogue with any other system outside the bus, such as for online fare assessment or authorization. online ticket / voucher / admission card. Therefore, this absence of network connectivity in a transit environment presents a difficulty whenever an online authentication of the consumer's means of access, such as an admission ticket, voucher, or access card, is required in order to determine if, for example, the consumer is entitled to access and has sufficient funds to cover the cost of the desired transaction (fare for traveling on the transit system).

In addition, in a transit environment, the amount of the transit charge may not be known at the time of access requested. A fare calculation may depend on the current travel distance, travel direction, station entry and exit locations, travel mode (subway, bus, taxi), consumer category (student, senior), and / or usage times (peak, off-peak). Such parameters may be unknown before granting the service. As such, payment of transit fare and collection process cannot be effectively performed using a conventional online authentication and approval process.

Traditionally, traffic fare calculation and collection took place in a closed system. In a closed system, the transit company can issue its own portable transit payment device, such as a smart read / write card, where the portable transit payment device carries the necessary credentials and data to allow completion of a transaction on the fare device itself (tourniquet, fare box, or other Service Point). In this case, there is no additional processing required to determine the rate at the time of the transaction outside of the interaction between the card and the rate device. Instead, the card is authenticated and read by the fare device, logic is executed by the fare device to apply the transit system fare policy, and the card is updated (rewritten) to finalize transaction details including a deduction of any stored value for the fare cost. The fare device may further examine a white list, a positive list, a hot list, a negative list and / or a black list using the card number, for example, to determine whether the transaction will be completed and the cardholder will be Access is permitted in a transit system installation such as a subway terminal or bus passenger compartment.

The closed transit system, however, has its disadvantages.

In a closed transit system, the portable transit payment device and transit readers at each station or route must be able to perform fare computations based on data stored and retrieved from a passenger's access card, and terminals / readers from subsequent cards must be able to access data written to the passenger's access card at previous stations. This requirement places a significant processing load on transit system terminals and / or fare processing systems and increases the cost of implementing the infrastructure for such systems. As fare rates and other pertinent information generally change over time, this also increases the demands placed on such systems for precision maintenance.

In addition, a portable transit payment device may not be compatible with all fare devices within a passenger's travel plan. This can become a significant problem if a consumer wishes to use more than one transit system during a day's commuting, such as using multiple transit agencies or jurisdictions within a single geographic area that provide access both in and between jurisdictions, cities or different locations.

The present transit environment presents several challenges, including:

A common need is that there can only be one portable transit payment device for each transit agency or group of cooperative agencies that cannot be used for other such agencies or groups;

The desire to accommodate transit system user's transaction speed expectations while minimizing risk to the transit agency to collect payment for services granted; and

When a portable payment device is 'read-only', having no writing capabilities at the Service Point, Portable Payment devices cannot store the passenger's traffic chronology data - thus making the passenger fare calculations a little bit difficult with such devices. With such offline transactions, a list (that is, a white list of eligible cards or a negative list of rejected cards based on the unique card number) stored with each transit fare device is the primary mechanism for preventing fraud. This is suboptimal since the negative list would presumably grow unlimited when more FIPPDs are issued.

In addition to the passenger's desire for a transit system for fast transaction speed when accessing a transit system installation, there are security and other risks associated with the use of an FIPPD that is designed for online authorization when otherwise used in an offline transaction. These risks include, but are not limited to:

Authentication / Fraud: the lack of real-time FIPPD authentication creates a high potential for fraud by counterfeiting techniques;

Fare Cost Calculation: where the cost of a transit transaction is dependent on the immediate passenger history for the card (entry / departure / duration of travel, transfers, etc.), the passenger's transit fare cannot be calculated in each gate or fare box because the passenger's immediate travel history cannot be stored, written or resident in conventional FIPPDs;

Security / Data Storage: Protection of consumer data in a transit fare system can prove difficult. Tracking data in the form of a primary account number (PAN) for an FIPPD would require the transit system to collect and store this data securely, which is not something that transit fare systems commonly do now. If implemented, this requirement presents added cost and security concerns both to the transit system and its passengers; and

What is needed in the art is the payment and collection of transactions using a FIDDP device within the previous environments, including access fees for transit systems and jurisdictions, which overcome the challenges and disadvantages of the prior art.

SUMMARY

A payment transaction can be conducted in a combined scheme using a portable financial institution payment device (FIPPD). During the transaction of a consumer with a commercial establishment for a good or service, information from the FIPPD can be read at a point of service (POS) terminal. The consumer with the FIPPD receives the good or service associated with the transaction. After the consumer has received the good or service, the transaction value can be calculated, just like a central server, based on predetermined rules and / or policies. Once calculated, the transaction amount can be passed to a payment processing system, such as a credit card payment system, so that the merchant can collect the calculated transaction amount from one or more members of the system payment processing.

In an implementation, a consumer may seek to conduct a transaction with a merchant for a good, service, or a combination thereof to a POS terminal using an FIPPD associated with an account within a payment processing system. The POS may have a reader, such as a contactless card reader that collects data from an FIPPD data storage region, including FIPPD account information. The data in the FIPPD storage region, together with other transaction information such as the time and location of the POS, after retrieving it can then be stored in a different location than the POS. The consumer using the FIPPD for the transaction is then allowed to receive the good or service from the merchant before a calculation of the cost thereof. After the consumer receives the good or service, the transaction cost can be derived and then charged to the account associated with the FIPPD.

In another implementation, a consumer (passenger) may seek access at a transit facility to a transit POS terminal using an FIPPD associated with an account within a payment processing system. The transit POS may have a reader, such as a contactless card reader, that collects data from an FIPPD data storage region, including

FIPPD. The data in the FIPPD storage region, along with other transaction information such as the time and location of the transit POS, after retrieving it, can then be stored in a different location than the transit POS. The passenger using the FIPPD for the transit transaction is allowed to access the transit facility before calculating a fare to access the transit system. After the passenger accesses the transit facility, the fare can be derived from stored passenger transaction history data and charged to the account associated with the FIPPD.

BRIEF DESCRIPTION OF THE DRAWINGS The exposed invention will be described in the context of the attached drawing figures, where the same numbers are used throughout the exhibition and figures to refer to the same components and characteristics:

Figure 1 is a block-level diagram illustrating an exemplary payment processing system;

Figure 2 is a block level diagram illustrating an exemplary closed transit processing system;

Figure 3 is a block level diagram illustrating an exemplary open transit processing system that is compatible with the payment processing system seen in Figure 1; and

Figure 4 is a flow chart illustrating an exemplary process by which a financial institution's portable payment device can be used in the open transit processing system environment illustrated in Figure 3.

DETAILED DESCRIPTION

Implementations facilitate payment and collection of transactions using a portable financial institution payment device (FIPPD) such as a contactless card or a smart chip embedded in a mobile device such as a cell phone. The transaction value of each transaction may not be known when a consumer in the transaction receives one or more goods or services associated with the transaction from a merchant. Mechanisms are provided to prevent fraud by using a negative list system (for example, a list of invalid account numbers) sometimes called a black list or hot list, and / or by using a white or positive list system (eg example, a list of valid account numbers).

As used here, an FIPPD is intended to be widely understood to be a portable payment device associated with an account within a payment system. The account can be a credit account, a debit account, a stored value account (for example, a prepaid account, an account accessible with a gift card, an account accessible with a rechargeable card). As such, the FIPPD can be a (hand held) device such as a cell phone, an MP3 player, a Personal Digital Assistant (PDA), a 'key fob', a mini-card, a keychain device (such as such as the commercially available Speedpass ™ from Exxon-Mobil Corp.), a proximity contactless payment device such as one that conforms to the International Organization for Standardization (ISO) 14443, a substrate carrying an optically scanned data region, a smart card, or integral elements and / or with accessories doing the same equivalent function and a contactless bank card associated with a payment system. A contactless payment device is a device that incorporates a means of communicating with a portable payment device reader or terminal without the need for direct contact. Thus, such portable payment devices can effectively be presented in the vicinity of a portable payment device reader or terminal. A smart chip is a semiconductor device that is capable of performing most, if not all, of the functions of a smart card, but it can be embedded in another device. Such contactless devices typically communicate with the reader or terminal of a portable payment device using RF (radio frequency) technology, in which proximity to an antenna causes data transfer between the portable payment device and the reader or terminal.

Typically, an electronic payment transaction is authenticated if the consumer conducting the transaction is properly authorized and has sufficient funds or credits to conduct the transaction. Conversely, if there are insufficient funds or credits in the consumer's account, or if the consumer's portable payment device is reported as lost or stolen, then an electronic payment transaction may not be authorized. In the following description, an acquirer is typically a business entity (for example, a commercial bank) that has a business relationship with a particular business establishment. An issuer is typically a business entity (for example, a bank) that issues a portable payment device such as a credit, debit, or stored value card to a consumer. Some entities can perform both the issuer and acquirer functions.

In standard operation, an issuer validation request message (for example, authorization) is created during a consumer purchase of a good or service from a Service Point (POS). The issuer validation request message can be sent from the POS terminal located at a merchant to the acquirer of the merchant, to a payment processing system, and then to an issuer. An issuer validation request message can include a request for issuer validation to conduct an electronic payment transaction. It may include one or more of an account holder's payment account number, currency code, sales amount, merchant transaction stamp, acceptor city, acceptor state / country, etc. A sender validation request message can be protected using a secure encryption method (for example, 128-bit SSL or equivalent) in order to prevent data from being compromised.

Referring to Figure 1, an implementation of a payment system 100 compatible with an FIPPD is illustrated. Payment system 100 includes a plurality of merchants 140 associated with one or more acquirers 150, and issuers 170. Each commercial establishment 140 may have one or more commercial premises 140 (a), 140 (b) with acquirers 150 (a) and 150 (b) associated with those commercial premises, where 'a' may be a value of 1 to Ά * and 'b' can be a value from 1 to 'B'. Different commercial establishment locations 140 (a), 140 (b) can be affiliated with a single commercial establishment. A consumer 120 can purchase a good or service at commercial premises 140 (a), 140 (b) using an FIPPD 130. Purchasers 150 (a), 150 (b) can communicate with an issuer 170 via a processor payment 160.

FIPPD 130 can be in many suitable forms. As previously stated, the FIPPD 130 can be a mobile device that incorporates a contactless element such as a chip to store payment data (for example, a BIN number, account number, etc.) and a data transfer element without wires (for example, transmission) such as an antenna, a light-emitting diode, a laser, a near-field communication component, etc. The FIPPD 130 can also be used to perform debit functions (for example, a debit card), credit functions (for example, a credit card), or stored value functions (for example, a stored value card) .

Payment processor 160 may include data processing subsystems, networks, and other means of implementing operations used to support and deliver issuer validation services, exception file services, and clearing and settlement services for payment transactions. Purchaser 150, payment processor 160 and issuer 170 make up a payment processing system 180.

Payment processor 160 may include a server computer. A server computer is typically a powerful computer or group of computers. For example, the server computer can be a large mainframe, a cluster of minicomputers, or a group of servers functioning as a unit. In one example, the server computer can be a database server coupled to a web server. Payment processor 160 can use any wired or wireless network satisfactorily, including the Internet.

Merchant 140 typically has a point of sale (POS) terminal (not shown) that can interact with the FIPPD 130. Any satisfactory point of sale terminal can be used, including device readers (for example, card). Device readers can include any contact or non-contact mode of operation. For example, exemplary card readers may include RF (radio frequency) antennas, magnetic stripe readers, etc., to interact with the FIPPD 130.

As noted, a desirable element of the standard electronic payment transaction system is the entity responsible for the account management functions involved in the transaction. Such an entity may be responsible for ensuring that a user is authorized to conduct the transaction (by online issuer validation by issuer 170 such as issuer authentication 170), confirming the identity of a party to a transaction (by receiving a personal identification number), confirm a sufficient balance or credit line to allow a purchase, and reconcile the purchase amount with the user's account (by entering a record of the transaction amount, date, etc.). Also, such an entity may perform certain transit-related services in addition to standard transaction services.

For example, the payment transaction processing entity may be responsible for communicating with one or more transit agency computer systems to provide authentication data (generating and / or distributing keys) to control access to transit systems, process data obtained from a transit user’s mobile device to associate transit system user identification data with an account used to pay for transit expenses, generate billing records for transit activities, etc. Note that a trusted third party may also perform some or all of these functions, and in this way act as a clearinghouse for access control data and / or traffic activity data processing.

Referring now to Figure 2, collection of transit fees is typically performed on a closed transit processing system 200 - the portable transit payment device 210 being issued by the transit system and the fare being calculated at transit POS 240 Transit POS 240 can be a fare box or a tourniquet with a transit system reader 220, such as a contactless card reader. Transit POS 240 collects and stores data such as the card identification number, card transaction history, card expiration information, etc. Transit POS 240 and transit transit portable device 210 are validated, typically using encryption algorithms and keys. Transit POS 240 then requests data from the portable transit payment device 210. Transit reader 220 and transit POS 240 process data from transit reader 220 and apply the tariff policy rules to the transit agency. Processing of fare rules will result in a determination of a fare amount, followed by a decrease in the portable transit payment device 210 in value or number of tickets, or application of a ticket (such as a monthly ticket). The portable transit payment device 210 is updated by writing information back to the portable transit payment device 210 as needed to document the transaction on the portable transit payment device 210.

If a transaction has an impact on the cost of the next transaction, as in the case of a discounted transfer when the customer transfers to the next leg of the journey, the appropriate transit portable payment device history 210 is available at the time of the transfer transaction. The information stored on the portable transit payment device 210 is available to determine the fare cost at the time of the transaction. There is no need to examine any other computer or server to complete the transaction on the fare device and the passenger is allowed to enter the access facility.

After the transaction is complete, the fare transaction information is typically transferred to the central transit computer 270 by the private transit network 260 for accounting, information and fraud determination purposes. The portable transit payment device 210 is uniquely identified by a transit account number, and is tracked for out-of-balance, speed, or usage rule values. If the fraud rules are broken and the portable transit contactless device 210 is determined to have fraud associated with it, the portable transit payment device number 210 can be placed on a negative or positive list, which can be kept in a storage that it is accessible to the central traffic computer, as shown in Figure 3, reference number 305 and described below. The hotlist can be sent to each transit POS 240 for use as a validation component at the time of the transaction. For example, if the portable transit payment device identification number 210 is found in the hot list, the portable transit payment device 210 may be denied for entry into the transit system.

Referring now to Figure 3, an FIPPD 130 can be used in a scheme to conduct a transaction within an open access system 300. Implementing an access tariff application does not allow the opportunity for the payment transaction to go online to issuer 170 for issuer validation (e.g., authorization) at the time of the transaction as would occur with merchant 140, such as a retail merchant. This is due in part to the need to process a transaction in less than a second, typically within approximately 300 ms - a transit system industry standard, to allow 30 to 45 customers per minute at the transit facility (hereinafter called access period). The ability to enter the transit environment online can also be problematic because of the lack of real-time communication and network systems. For example, buses are on the road and may not have wireless or other communication systems to allow real-time dialogue with any other system outside the bus. Consequently, an implementation combines a process scheme to conduct a fare transaction, as illustrated in Figure 3.

For example, a passenger can present the FIPPD 130 at the transit POS with the traffic reader 220. The traffic reader 220 can capture financial institution account information, such as Magnetic Strip Data (MSD), from the FIPPD 130, in a offline mode (for example, without communicating with the payment processing system 180). Traffic reader 220 can read all track data, or just part of the track data as a primary account number (PAN) associated with the FIPPD 130. The track data, along with other transaction information, such as the time and location of transit POS 240, can be transmitted to the central transit computer 270 via the private transit network 260. At this time, however, the fare amount may not be known. Nevertheless, the consumer is given access to the transit facility.

The transaction information can be stored and analyzed on the central transit computer 320. The central transit computer 320 can have a database containing the transit transaction history for all passengers using the transit system. The transit transaction history can be updated with each use of FIPPD 130 in transit POS 240 or it can be updated on a batch basis.

The transit transaction history can be accessed to calculate the value of an offline fare. For example, a set of transit transaction history within the database can be accessed based on the PAN read from FIPPD 130 at each transit event (for example, entry, transfer, or exit) using FIPPD 130; the transit transaction history can then be put in a chronological order of transit events; and the traffic fare can be derived using the chronology of traffic events on the basis of predetermined traffic agency rules and policies.

Once the fare amount is derived, the transaction can be processed in communication with the payment processing system 180 as a standard online retail transaction would be with the merchant 140. The fare amount can be transmitted to the system payment processing 180 through the 310 online network. Once transmitted, the fare amount can be authorized, cleared and settled as described for payment system 100 - with the merchant 140.

Referring to Figure 4, a flow chart is used to illustrate an exemplary process 400 by which the FIPPD 130 can be used in the open transit system 300. Process 400 begins at step 402, where data from the associated FIPPD 130 data storage region with an account within the payment system 100 are read. The data can include any track data or subcomponent thereof. For example, the data may include an ID for the FIPPD associated with the account such as the PAN. The data can be read by the transit reader 220 such as a contactless reader reading a contactless payment card that was issued by an issuer in a payment processing system. The transaction data can include the data read on the traffic reader 220 along with other transaction information such as the date, time, a store identification code, the location of the transit POS 240, etc.

In step 420, the optional validation request can be conducted at transit POS 240 including rudimentary checks on the status of the FIPPD 130 or variations of online issuer validation (for example, authorization) with the payment processing system 180. For example, a transit validation may be requested, for example, by examining the expiration date of FIPPD 130 at transit POS 240. Also, an analysis of Module 10 can be done at transit POS 240, where a checksum formula is used to validate an identification number such as the PAN.

Alternatively, or in combination, the validation step

420 may include a check against the transit agency's white list or black list maintained either at transit POS 240 or at transit central computer 270 to determine whether the passenger should be allowed access at the transit facility. The white list can be a data list such as a reissued PAN associated with an eligible account that can be used to gain access to the transit facility. Similarly, the black list can be a list of data associated with an ineligible account, such as a reissued subscription that cannot be used to gain access to the transit facility. Therefore, the white list or black list may consist of identifiers for portable payment devices, such as the PAN associated with the FIPPD 130 or a power of attorney. The transit agency can place a portable payment device on such a list (for example, white or black) based on several parameters. For example, the portable payment device may have been reported stolen by a consumer, the portable payment device may have been a stored value card that emptied its value, or the portable payment device may have been used repeatedly during a course of one day such that fraud can be suspected. Stated otherwise, the speed with which the portable payment device is detected as having been used may indicate that fraud is being used to gain access to a transit facility; a transit agency may have a host of policies and rules that, when violated, put a portable payment device on the negative list. Each such list can be maintained in database 305 in communication with central traffic computer 270 or in transit POS 240.

The transit agency may also put a consumer device on a white list or black list based on a transmission originating from the payment processing system 180, such as in response to an issuer validation request. For example, the transmission may have included a notification from issuer 170 that there has been a declined transaction involving FIPPD 130 in the past or that the risk assessment of payment processing system 180 in FIPPD 130, the transit system can use compared to the assessment from risk to a traffic tolerance threshold for risk such that the transit agency may wish to place the FIPPD 130 on the negative list if the threshold is breached. Other responses to the issuer validation request may be a balance check response, a credit score response, an authorization response, or a combination thereof.

The white list or black list can be hosted on transit POS 240 or on database 305 in communication with central traffic computer 270, while still in communication with transit POS 240. When the list is hosted on the database data 305, the white list or black list can be updated without having to make changes to each transit POS 240. The central transit computer 270 does not have to be a single computer. Instead, the transit central computer 270 can be a computer network such as a network with nodes for a set of traffic readers 220. The nodes can be connected to each other, either laterally and / or hierarchically.

In step 430, the transaction data can be transmitted to the transit central computer 270 for storage and analysis. The central transit computer 270 can use the database 305 to contain history of transit transactions for passengers using the transit system over time. The transit transaction history can include transaction information such as the date and time of a transit event, a transit POS identification 240, a transit agency identification, and at least some of the data read from the transit storage region. FIPPD 130 data. The transit transaction history can be updated with each FIPPD 130 event on the transit reader 220 or on a batch basis.

In step 440, the passenger is given access to the transit facility. The transit facility can be a subway, a bus, a ferry, a tram, a 'hovercraft', a train, and other forms of transport as are typically found within a transit system. Steps 410 to 440 can take place offline within a short period of time such as less than approximately one second or during a period of time not exceeding the access period (for example, 300 ms). Steps 410 through 440 are repeated when respective passengers interact with transit POS 240.

In step 450, the transit transaction history stored in step 430 can be accessed to calculate a fare value offline (for example, not in real time) using the stored transaction data and transit agency policies. For example, a set of transit transactions can be accessed based on the identification information of FIPPD 130, such as the PAN of FIPPD 130; the set of transit transactions can then be ordered chronologically by transit events (for example, entry, transfer, or exit); and the traffic fare can be derived using the traffic event chronology based on predetermined traffic agency rules and policies. For example, a transit agency may charge a transit fee based on predetermined fare policies, such as a flat fee of $ 2.00 (US) for entry into the system. Other examples of predetermined fare policies include taxing the fare amount based on: an entrance to the transit system installation; an exit from the transit system installation; a distance to an entrance and a corresponding exit; a transfer from one transit system installation to another transit system installation; the sequential number of each transfer in a predetermined period of time; a travel direction in the transit system; a passenger rating corresponding to FIPPD 130 (for example, age-based, student status, or frequent flyer concessions); peak and off-peak travel time periods; a holiday travel time period; and combinations of the antecedent. Those in the art are familiar with the potential rules and policies that may apply when calculating a transit fare.

Sometimes several FIPPDs 130 can have the same PAN. For example, a husband and wife can each have their respective FIPPDs 130 linked to their joint checking account. Alternatively, several employees of the same employer can each have respective FIPPDs 130, all of which are associated with a single account (for example, PAN) within the payment processing system 180. As such, the respective fare calculations for these employees using their respective FIPPDs 130 to travel daily during the same time within the transit system will need to take into account which card is being used by each employee within the same PAN.

In step 460, the transit agency can transmit one of the most calculated fare values ​​to the payment processing system 180 for collection based on various payment models. For example, the model used by the transit agency to request payment for the fare values ​​calculated from the payment processing system 180 may be a payment model for each use, an aggregation model of multiple calculated fare values, or a model prepaid.

In the payment model for each use, when the transit tariff is determined, the tariff is transmitted to the payment processing system 180 for collection. Therefore, the transit fare can be sent directly to the payment processing system 180.

Alternatively, the calculated transit tariff can be grouped with other transit tariffs calculated for a plurality of FIPPDs 130 over a period of time and then sent on an intermittent basis to the payment processing system 180 for collection.

Once the transit fare is sent to the payment processing system 180, it can be processed according to a typical protocol for commercial establishments 140. For example, each $ 2.00 transit fare can be authorized, settled, and cleared through the payment processing system 180, the transit agency can be paid, and the consumer can receive the transit fees charged in a monthly declaration corresponding to his PAN.

In the aggregation model, the transit rate involving FIPPD 130 can be accumulated based on a predetermined algorithm before sending the transit rate to the payment processing system 180. The accumulated transit rates can be over time, through transit value, or through quantity. For example, the transit agency may accrue transit fees involving FIPPD 130 that occur over a period of week before transmitting the aggregate set of fees to the payment processing system 180. Alternatively, the transit agency may accrue amounts of transit tariff based on a threshold value. For example, once the accrued transit fare amount reaches $ 20.00 (US dollars), the transit agency can pass the aggregate set of fares to the payment processing system 180. In another example, the transit agency may accumulate transit fare values ​​based on the amount of transit fare - such as when a passenger completed five (5) trips involving the same FIPPD 130, where each trip had its own fare amount (for example, $ 4.00, $ 0.50, $ 1.00, and $ 5.00 US dollars), and then accumulate the fees and pass the full amount on to the payment processing system 180.

In the stored value model, the account associated with FIPPD 130 is accessed by the payment processing system 180 in the transit system. For example, the passenger may ask the transit agent at a payment window to deduct an amount from the passenger's credit card associated with the payment processing system 180 before the passenger goes to a tourniquet to seek entry into a system subway. of traffic. The transit agent can then conduct an online transaction with the payment processing system 180 thus to charge an amount against the account, for example $ 50.00 (US dollars). The transit system can then maintain a transit account associated with the FIPPD 130, for example, such that the transit account can be kept on the central transit computer 270. When the passenger wants to take the subway, the passenger can go to the tourniquet, bring the FIPPD 130 close to the traffic reader 220 in a contactless reading operation. Transit POS 240, in this case the tourniquet, can transmit the traffic event to the central traffic computer 270 via the private transit network 260. Once a plurality of such transit events are completed for the PAN associated with FIPPF 130 (such as both an entrance and an exit to the metro system for the passenger), the transit fare can be calculated and deducted from the transit bill on the central transit computer 270. In this case, the online transaction to record the transit event occurs before the offline transaction of the central transit computer 270 collects the aggregate set of fees from the payment system 180.

The passenger can establish the transit bill such that the bill is limited to predetermined intervals - such as when the end of the month arrives or when the transit bill has reached a lower threshold value such as $ 5.00 (US dollars) , whereby a predetermined amount is charged to the account that is associated with FIPPD 130 in the payment processing system 180. Therefore, the transit system can conduct an online transaction, for example for $ 50.00 (US dollars) with the payment processing system

180 once the predetermined interval is reached.

It should be understood that the present invention can be implemented in the form of control logic, in a modular or integrated manner, using software, hardware or a combination of both. Based on the exposition and teachings provided here, a person of ordinary skill in the art will appreciate other ways and / or methods for implementing the present invention.

It is understood that the examples and embodiments described here are for illustrative purposes only and that various modifications or changes in light of this will be suggested to persons skilled in the art and are to be included within the spirit and scope of this application and the scope of the appended claims.