Distributed payment and loyalty processing for retail and vending

FIELD OF THE INVENTION

[0001] This invention relates to electronic payment and loyalty systems for retail and automatic unattended vending. In particular the invention relates to an electronic payment and loyalty system wherein the customer account information is cached in a nonvolatile memory on the payment terminal or point of sale system and addresses the problems of securely storing customer identity information, operation of the payment system during a failure of the server or network, allowing the use and funding of offline electronic stored value accounts, and the use of customer account synchronization scheduling to limit merchant fraud risk in a network or retail locations.

BACKGROUND OF THE INVENTION

[0002] Electronic payment processing for attended retail locations and self-service automated vending locations is usually typically performed using online authorization or offline authentication with a chip or smart card. Payment processors have adopted authorization and authentication processes on a wide scale to prevent fraud losses and to limit abuse of accounts by customers. These approaches are applied to both credit and debit electronic payment accounts, as well as to check authorization and guarantee schemes.

[0003] With online authorization system, the payment terminal captures the payment account information and some security information from a magnetic stripe card or other electronically coded token (chip card, RFID device). The payment terminal connects to the payment server or host and requests an authorization. The server returns an authorization or a decline depending on the state and validity of the customer's account. Periodically, the payment terminal submits a settlement batch file to the payment system server, which then creates a settlement batch to transfer funds from the customers Financial Institution (FI) to the merchant's Demand Deposit Account (DDA). Existing prior art online authorization systems include those operated by Master Card International, Visa International, and American Express along with numerous smaller networks and private label systems.

[0004] In modern offline payment systems the customer account information is stored in contact-based or contact-less chip or smart cards. The smart card authenticates itself to the payment terminal typically using cryptographic methods. If the card is successfully authenticated and the payment account parameters are within acceptable limits for the transaction the terminal authorizes the transaction. Thus, the transaction can be authorized without a network connection to the payment system server or host. Periodically, the payment terminal submits a settlement batch file to the payment system server, which then transfers funds from the customers Financial Institution (FI) to the merchant's Demand Deposit Account (DDA). In addition, the data stored on the customer's smart card is periodically updated or synchronized with the payment system server or host. Existing prior art smart card based offline authorization systems include those operated by Master Card International, Visa International, and American Express along with numerous smaller networks. Open applications standards for smart card payment system can be found in a number of sources including those from the Common Electronic Purse Specification volumes; Business Requirements, Version 7.0, March 2000, Functional Requirements, Version 6.3, September 1999, and Technical Specification, Version 2.3, March 2001; the Guidelines for Developing Applications on Open Platform Cards, May 7, 2001 from Visa International; and the Integrated Circuit Card Specification for Payment Systems, Book 2, Security and Key Management, Version 4.0, December 2000, Book 3, Applications Specification, Version 4.0, December 2000, and Book 4, Card Holder, Attendant, and Acquirer Interface Requirements, Version 4.0, December 2000.

[0005] The same online and offline technology is applied to customer loyalty systems. Loyalty systems issue loyalty points and create electronic offers or promotions as customers perform transactions with merchants. Once points are issues these systems allow customers to redeem the value of the loyalty points, electronic offers and promotions toward purchases of goods and services from the merchant. The payment system uses an online or offline authorization process to control the redemption of this promotional value.

[0006] Both the online and offline methods of have significant drawbacks for both merchants and consumers when applied to low value or frequent transactions. Online authorization requires a data network connection from the payment terminal to the payment system server and host. The cost of this data connection must be included in the transaction processing costs. Further, creating the network connection and the processing of the authorization by the central server increase the transaction processing time for both the merchant and the consumer. Smart card based systems do not require network connections for each transaction, reducing network cost and reducing transaction processing time. However, both contact-based and contact-less smart cards are considerably more expensive to issue than conventional magnetic cards. Further, all issued smart cards must have their software updated to allow the merchant or the payment processor to deploy any additional applications (e.g. a new electronic coupon algorithm), creating versioning and synchronization issues on a large scale, potentially across hundreds of millions of issued cards, and possibly creating a shortage of memory space on older versions of the card.

[0007] Caching of applications data or content from a set of centralized servers onto remote client fixed wireless or mobile or fixed wireless computer systems is well know. In U.S. Pat. No. 6,243,755 to Takagi and Kamitake a predictive algorithm to cache the information most likely to be needed by the user in a nonvolatile memory on the user's mobile terminal from a centralized server is disclosed. This approach only addresses serving individual users, rather than large groups of customers and does not address the risk of fraud as would be encountered in a payment system.

[0008] Caching of information on Point of Sale (POS) systems and payment terminals is an established practice. WO 00/14691 to Yoshihiro et. al. discloses a system in which payment account information is cached onto individual POS terminals from a server located at the store location. This system does not address the problems associated caching payment account information across multiple store locations. JP10198634 to Ken discloses a system in which merchant personnel or customers can load payment account information onto POS systems using email or other electronic messaging. This system does not address loading the information automatically onto the POS system or payment terminal based on a predicative algorithm.

[0009] A number of systems electronically manage coupons, loyalty points or other promotions based on customer transaction histories stored at the point of sale either in the POS system or some other suitable server at the merchant store location. U.S. Pat. No. 6,321,210 to O'Brien et. al., WO 02/01433 to Bernard and Bertrand, JP11003472 to Mitsuo, WO 01/69465 to Peters, and U.S. Pat. No. 5,642,485 to Deaton and Gabriel disclose systems for accumulating customer transaction histories at the point of sale. None of these systems discusses the sharing of this information between different locations or the complexities involved in using stored customer payment account information in a network of related stores.

[0010] U.S. Pat. No. 6,334,108 to Deaton and Gabriel discloses a system that synchronizes both customer payment account information and loyalty information between centralized servers and a network of POS systems at retail locations. This system also takes various measures to limit the fraud exposure for the customer payment account information cached in the POS systems at the merchant store locations. However the disclosed system does not address the problems of securely storing customer identity information (e.g. account number and PIN) in the POS system or payment terminal as is required by many payment system rules and regulations, operation of the electronic payment and loyalty system during a failure of the server or network, management of the server and network resources at peak transaction times, the funding of stored value accounts at the point of sale, or the use of customer account synchronization scheduling to limit merchant fraud risk in a network or retail locations using the system.

[0011] The use of electronic payment and loyalty applications has been limited in the areas of unattended automatic vending and related applications such as automated fuel dispensing or the distribution of prepaid cards, by network and transaction processing costs or the costs of distributing smart cards.

[0012] U.S. Pat. No. 5,845,256 to Pescitelli and Schuman discloses a system which caches transaction information in an automatic vending machine which is then loaded to a centralized server in batch for processing. This invention does not address fraud management and limits the vending to a product (insurance) having no value until the offline processing has been successfully completed, limiting the opportunities for fraud.

[0013] U.S. Pat. No. 5,637,845 to Kolls, discloses a system allowing the use of electronic payment cards at vending machines using an online authorization process. This invention does not address the cost issues of online payment processing and is therefore limited to high-value items such as prepaid telephone cards.

[0014] EP 0287367 to King, and U.S. Pat. No. 6,003,008 to Postrel et. al. disclose systems for performing offline electronic payment transactions using stored customer payment account information with vending machines on aircraft or ships. Neither of these inventions address the synchronization and security issues involved in performing offline payment transactions at a network of vending machines or customer loyalty functions.

[0015] Electronic payment with electronic debit and credit cards using an online authorization for automated or semi-automated fuel dispensing is well known to those skilled in the art. JP 11102482 to Junichi discloses a fuel POS system where customer identification and product purchase information is stored locally. This system does not address the synchronization required to manage this stored information in a network of fueling locations. U.S. Pat. No. 6,073,840 to Marion discloses an automated fuel payment system using Radio Frequency Identification (RFID) devices with an on-line payment authorization. Merchants using this system must pay the full cost of online payment processing.

SUMMARY OF THE INVENTION

[0016] The present invention overcomes the deficiencies of prior art payment systems by caching customer account information in a nonvolatile memory on the payment terminal. The information is cached in a secure nonvolatile storage on the terminals at the merchant locations where the customer is most likely to execute transactions. Customer account data, transaction data, including settlement information, are periodically synchronized with the payment system server.

[0017] Through secure caching of customer account information the present invention enables low cost offline authorizations, with the corresponding improvements in transaction speed and without the need to issue costly smart cards and without undue fraud risk. The system of the invention is applicable to electronic payments, electronic loyalty, and electronic coupons and promotions. The system of the invention supports virtually any payment scheme, including credit account payments and debit account payments including direct debit from a customer's demand deposit account using card based debit, ACH or check draft capture, as well as payment stored value or prepaid accounts. Another aspect of the invention allows customers to add funds to stored value accounts while at the merchant's location either with an electronic payment account, with cash or by check.

[0018] The customer account information cached in the payment terminal includes that used for electronic payment as well as loyalty functions. The cache or nonvolatile memory of the terminal also holds transaction data, business rules for the payment and promotion applications and security data. Customer account specific business rules stored in the payment terminal are used to limit fraud risk, including limits on payment accounts and verification of the validity of coupons and other promotions.

[0019] Account numbers and security codes stored on any convenient payment token are used to reference customer account information for the payment system of the invention. The token can be one used for general payment applications (i.e. a credit card or debit card), can be issued by the merchant or can be issued by the operator of the payment system of the invention. Alternatively, the token can be a device owned by the customer, such as a wireless device, possibly one incorporating cryptographic security capability. Regardless of the payment token or identifier used, the payment system of the invention provides the customer access to any of several payment, loyalty or promotional accounts. Thus, one or more tokens act as surrogate tokens for other accounts. For example, a customer can use a credit card to both make payment and access loyalty and promotional accounts. In another example, the customer can use the identifier or token (possibly combined with the entry of shared secret information) to use a check (and possibly a check guarantee service) at the merchant's location.

[0020] In the preferred embodiment of the invention, a cryptographic hash of some convenient account number, an optional security code and customer shared secret information references customer account information (typically a password or PIN). The use of a hash allows the customer account information to be referenced without the account number or shared secret information being stored in the nonvolatile cache memory of the payment terminal at the merchant's location.

[0021] If a customer, whose account information is not in the cache memory on the terminal at a particular merchant location, wishes to perform a transaction at that location, the payment terminal connects to the payment system server through a data network to access the customer account information. At the same time, the payment system server of the invention can use the network connection to synchronize account and transaction data.

[0022] The payment server of the invention controls the synchronization data in the payment terminal cache memory to regulate the capacity demands on the server and data network and to limit fraud risk. At times of peak transaction rates the server limits the volume of data transferred to a minimum. The processing load for transactions is distributed to the payment terminals to the extent possible. This regulation of synchronization or online data volume and the distribution of transaction processing reduces the required telecommunications or data network capacity required as well as optimizes use of the server equipment for a given transaction rate capacity.

[0023] The central server of the payment system of the invention performs centralized fraud management. The server performs fraud scoring and account activity profiling for both new accounts and the ongoing use of established accounts. Based on these risk scores the server determines transaction limits for customer accounts, customer account and transaction data synchronization schedules with the nonvolatile cache memory in the payment terminals and identifies high risk accounts for which no account information or account blocking information is cached on the payment terminals.

[0024] An object of the invention is to improve transaction speed and lower network costs by caching customer account and transaction data in a payment terminal or POS system at a merchant's retail location while maintaining payment system security by storing account numbers, optional security codes and PIN codes in the form of a non-reversible cryptographic hash rather than in unencrypted form. Account and transaction data indexed through the cryptographic hash includes payment, loyalty, electronic coupons and promotional purses.

[0025] Another object of the invention is to increase peak transaction capacity of the payment system infrastructure, including servers or hosts and network or telecommunications facilities, by distributing processing load to terminals maximizing system capacity at peak demand times. The server regulates synchronization and network use to manage capacity at peak transaction rate times.

[0026] Another objective of the invention is to provide robustness or continuity for the electronic payment and loyalty functions at each merchant store location in the event of network or server failure.

[0027] Another object of the invention is to reduce the merchant's fraud risk through global server control of customer account and transaction information synchronization schedules. During these synchronization events rules to prevent risk at each store location are dynamically updated on each payment terminal.

[0028] Another object of the invention is to limit the merchant's exposure to high-risk transactions or accounts by not caching in nonvolatile memory account information for high-risk customers on the payment terminal under control of the server.

[0029] Another object of the invention is to allow the use of stored value or prepaid accounts for customer payments, which the customer can fund at the merchant's payment terminal using either an electronic payment account or with cash.

[0030] Another object of the invention is to provide the hireactical security and security management required to operate the system using the existing corporate and franchises structures existing in many retail environments.

[0031] Yet another object of the invention is to allow low cost and low risk payment and loyalty functions at both attended and unattended merchant retail locations including stores, vending machines, and fueling stations and without the need to distribute smart cards to customers.

[0032] It will be appreciated that the foregoing statements of the features of the invention are not intended as exhaustive or limiting, the proper scope thereof being appreciated by reference to this entire disclosure and to the substance of the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The invention will be described by reference to the preferred and alternative embodiments thereof in conjunction with the drawings in which:

[0034]FIG. 1 is an overall diagrammatic view of the preferred embodiment of the system or the invention;

[0035]FIG. 2 is a block diagram of the payment terminal used at a merchant terminal according to the preferred embodiment;

[0036]FIGS. 3A, 3B, <b>3</b>C, <b>3</b>D, <b>3</b>E, <b>3</b>F, <b>3</b>G, <b>3</b>H, <b>3</b>I, <b>3</b>J, and <b>3</b>K is a flow chart of a basic transaction for a payment at a merchant terminal according to the preferred embodiment;

[0037]FIGS. 4A, 4B, and <b>4</b>C is a flow chart of an electronic payment according to the preferred embodiment;

[0038]FIGS. 5A, 5B, <b>5</b>C, <b>5</b>D, and <b>5</b>E is a flow chart for customer account creation according to the preferred embodiment;

[0039]FIGS. 6A, 6B, and <b>6</b>C is a flow chart showing a payment account authorization according to the preferred embodiment; and,

[0040]FIGS. 7A, 7B, <b>7</b>C, <b>7</b>D, <b>7</b>E, and <b>7</b>F show the nonvolatile memory data structure for the merchant payment terminal according to the preferred embodiment.

DETAILED DESCRIPTION OF THE PREFERRED AND ALTERNATIVE EMBODIMENTS

[0041] The preferred embodiment of the invention is used to facilitate transactions with customers who wish to make payment and gain loyalty benefits at one of several merchant locations. The customer and merchant employee interface with the payment system using dedicated terminals or other Point Of Sale (POS) systems at the merchant locations, which communicate over a data network with centralized servers or hosts. In the preferred embodiment customer account information is cached in a secure manner in nonvolatile memory on the payment terminal or POS system and synchronized with the host as required. The major system components of the payment system used in the preferred embodiment of the invention are illustrated in FIG. 1. However it will be appreciated that many aspects of the invention are equally applicable to other embodiments of payment systems that might be contemplated for use in conjunction with payment and electronic loyalty systems at physical merchant locations.

[0042] The major system components of the preferred embodiment include:

[0043] Transaction manager <b>10</b>

[0044] Payment switch <b>14</b>

[0045] Stored value processor <b>16</b>

[0046] Security manager <b>18</b>

[0047] Settlement manager <b>20</b>

[0048] Report generator <b>22</b>

[0049] Database <b>24</b> and a database management system

[0050] Terminal communications system <b>44</b>

[0051] Merchant IT equipment <b>50</b>

[0052] Customer access gateway <b>42</b>

[0053] The database <b>24</b> resides in non-volatile storage such as hard disk drives and includes:

[0054] Customer accounts <b>28</b>

[0055] Merchant accounts <b>30</b>

[0056] Transaction ledgers <b>32</b>

[0057] Security information store <b>34</b>

[0058] Data warehouse <b>38</b>

[0059] Not all of the illustrated components are necessary to the functioning of the invention. For example, a stored value processor <b>16</b> is desirable to facilitate payment, but such a payment option is not critical to all embodiments of the invention.

[0060] The principal components identified above are preferably housed and executed on one or more servers dedicated to the payment system of the invention and remote from the merchant store locations. Many of the components may be implemented as distributed sub-systems.

[0061] The merchant terminal equipment (<b>50</b>) deployed at each merchant store location is an integral component of the payment system of the invention. The merchant terminal equipment communicates with the host components through the terminal communications system (<b>44</b>). The components of the merchant terminal equipment are discussed in a section below.

[0062] External components interfaced to the RO system include:

[0063] External payment processors <b>56</b>

[0064] Merchant extranet <b>48</b>

[0065] Customer access devices <b>52</b>

[0066] CRM system <b>54</b>

[0067] Fraud profile databases <b>58</b>.

[0068] A summary of the interaction between these components is first presented in this section.

[0069] Summary of Interaction of Components of the Payment System

[0070] The following is an overview of the functions of the main components or subsystems of the preferred embodiment of the payment system of the invention.

[0071] The transaction manager <b>10</b> controls the overall transaction flow and executes the required business logic. The transaction manager uses the services of the other components of the payment system, including the payment switch <b>14</b>, the security manager <b>18</b>, and the terminal communications system <b>44</b>. The transaction manager or the central processor (<b>100</b>) in the merchant terminal equipment (<b>50</b>) computes the price, promotional value, tip, fees and taxes. If a payment authorization is required the transaction manager receives the authorization from either the internal stored value processor (<b>16</b>) or external payment processors (<b>56</b>) through the payment switch (<b>14</b>). During transactions that cannot be executed using information cached on the terminal (<b>50</b>) the transaction manager and the terminal communicate through the terminal communications system (<b>44</b>) to exchange the required account information.

[0072] The security manager <b>18</b> controls all access to data, reports and system services for the payment system server, including access for both merchant employees and customers. The report generator <b>22</b> provides merchant personnel with reports on payment and loyalty transactions from the data warehouse <b>38</b> and under the control of the security manager <b>18</b>.

[0073] The security manager uses a set a set of security protocol adaptors to accommodate the authentication protocols used by the various merchant and customer connections to the system. For data or system service access for merchant personnel the security manager (<b>18</b>) authenticates the person and determines the permissions for data and service access. Authentication is done when personnel access the payment system over the merchant extranet (<b>48</b>) or through terminal or POS equipment (<b>50</b>) at a store location. If personnel attempt to access data or services for which they are not authorized security manager (<b>18</b>) will prevent them from doing so. Customers access the system through either merchant IT equipment <b>50</b> connected through the terminal communications system <b>44</b> or with a variety of wired or wireless customer access devices <b>52</b> connected through the customer access gateway <b>42</b>. The security protocol adaptors in the security manager <b>18</b> accommodate the security protocols used by each of these customer connections.

[0074] The security manager (<b>18</b>) and the transaction manager (<b>10</b>) manage merchant fraud risk within the payment system. Risk management occurs both when new customer payment accounts (<b>28</b>) are authorized and as an ongoing process throughout the life to the customer account.

[0075] The transaction manager <b>10</b>, settlement manager <b>20</b>, report generator <b>22</b>, and security manager <b>18</b> each make use of the records maintained in the database <b>24</b>. This information includes the customer account information (<b>28</b>), merchant account information (<b>30</b>), and security access and authentication information in the security information store (<b>34</b>). Certain transaction records are maintained in ledgers <b>32</b> and an archive of transaction details is maintained in the data warehouse <b>38</b>.

[0076] To maintain security of the entire payment system server network security measures are employed. Firewalls, encryption schemes (including the use of Virtual Private Networks or VPNs) and other measure to limit access are employed on all external network connections and select internal network connections. Security equipment and processes are employed in the terminal communications system (<b>44</b>), the customer access gateway (<b>42</b>), the merchant extranet (<b>48</b>), the payment switch (<b>14</b>) and connections to the CRM system (<b>54</b>).

[0077] The RO system is adapted for use in association with a chain of affiliated merchants, for example in a franchise group. The security information store (<b>34</b>) is maintained wherein merchant location-specific information is retained to allow the payment system to be used seamlessly across the various merchant locations in the chain and across merchant brands with differing ownership. Such information includes for example payment types accepted, payment accounts, settlement protocols and rules, and administrative privileges.

[0078] For affiliated chains of merchants the security information store (<b>34</b>) is organized in a hierarchical manner. Merchant brands are divided into administrative groups that are generally organized along corporate organizational lines. A merchant brand can be divided into one or more geographic divisions and the geographic divisions divided into one or more geographic subdivisions. These subdivisions can include the territory of an individual franchise operator. There can be multiple levels of geographic subdivisions as required by corporate organizational structure. Geographic divisions or subdivisions are divided into individual store locations. Merchant employees and RO system administrators are organized into functions or “roles” that are used to simplify administration of permissions (for example to authorize refunds or to change merchant account information). These permissions are set through an administrative interface. Merchant employee permissions and roles are organized hierarchically in a manner that reflects corporate and ownership structure. Examples of levels in this hierarchy may include:

[0079] 1. Corporate,

[0080] 2. Geographic division or region,

[0081] 3. Group of store or franchise group,

[0082] 4. Store employees.

[0083] Roles within these levels include:

[0084] 1. Financial manager,

[0085] 2. Marketing or product manager,

[0086] 3. Operations manager,

[0087] 4. Franchise owner,

[0088] 5. Store manager, and

[0089] 6. Store employee.

[0090] A security administration interface itself contains a hierarchy of security administration authority. Different levels within an organization can set the permissions and create accounts for personnel within their part of the company. Generally, security administrators can create or delete accounts for their level in the hierarchy or below. Thus, control of the administrative function is itself hierarchical. As an example, administrators at a corporate level can set permissions for corporate employees at the corporate, regional or divisional level. Administrators at the regional or divisional level can set permissions for personnel within that division or region including store managers, franchisees or store owners. Administrators at the store or franchisee level can set permission for personnel directly associated with that store or stores. Levels and authorities for company-owned stores within a chain are generally structured differently than for franchisee-owned stores. The security administration interface is used to create or delete new merchant employee and store location accounts. Generally, security administrators can create or delete accounts for their level in the hierarchy or below. For example, administrators at the store or franchise level will create or delete store employee accounts.

[0091] The customer account <b>28</b> contains all payment and loyalty information applicable to each customer for a variety of merchant brands and store locations. The applicable portion of the customer account information (<b>112</b>) is loaded into a nonvolatile of cache memory (<b>110</b>) on the terminal (<b>50</b>) at specific merchant locations to reduce transaction time and costs, while managing fraud exposure.

[0092] Each merchant location is associated with a merchant account <b>30</b> allowing the payment system to tailor payment, loyalty processing, and settlement rules and conditions applicable to that merchant location. The merchant location can be a part of a chain of affiliated merchants or a single stand-alone location. A separate merchant account is required for each store location in either case. The merchant account (<b>30</b>) contains basic store information including a store number of other identifier, the store name or location name. The account also contains the geographic or other company divisions the store is associated with, and one or more brand identifiers associated with the store. The merchant account contains (or has links to) one or more financial account records showing all transactions at that store location and preferably including:

[0093] 1. The merchant account number for that account,

[0094] 2. The type (settlement, promotional, etc) of account,

[0095] 3. The account owner, or merchant of record,

[0096] 4. The current settlement balances for that account,

[0097] 5. The financial institution holding the Demand Deposit Account, and

[0098] 6. The transaction history (or links to the ledger system) for that account,

[0099] 7. Links to the security information store (<b>34</b>) for the employees at the store location,

[0100] 8. Account contact information, including the name of the account owner or primary contact, the contact telephone number, the contact's email address, the mailing address, and alternative contact information as may be required, and

[0101] 9. The payment types and customer authorizations accepted by the merchant location, and any authorization rules, such as value limits, need for signature capture, etc, for each payment type.

[0102] The settlement processor <b>20</b> creates financial settlement files for each store location using the service. These files are transmitted at required time intervals through the payment switch (<b>14</b>) to the appropriate payment processors (<b>56</b>), who then settle funds to each merchants demand deposit account. In general each store location of a chain of merchant will have individual demand deposit accounts and will be settled separately.

[0103] Customers using various types of wireless and fixed wired devices <b>52</b> to access the services of the RO system through the customer access gateway <b>42</b>. The customer access gateway interfaces with a variety of public access wide area networks or local area wireless base stations (<b>104</b>) in the merchant terminal equipment (<b>50</b>).

[0104] External Components

[0105] The RO system can use one or more external payment providers <b>56</b>. The services of these providers can include multiple payment types including credit, debit, and stored value.

[0106] The merchant employees use the merchant extranet (<b>48</b>) to access reports created by the report generator (<b>22</b>) and administer the payment system. Access to the extranet can be through the Internet, telephone, or other suitable means.

[0107] The transaction manager (<b>10</b>) and the security manager (<b>18</b>) use the external fraud profile database (<b>58</b>) as a source of information by for the authorization of new customer accounts and the ongoing management of merchant fraud risks.

[0108] Customers can access the services of the RO system using a wide variety of wireless and fixed wired devices <b>52</b>, including telephones, text messaging devices and Internet terminals connecting to the customer access gateway <b>42</b>.

[0109] The CRM system <b>54</b> is used to perform customer support and relationship management functions using the records in the database, including the customer account <b>28</b> and data warehouse <b>38</b>. The CRM system can be operated by a variety of entities including the RO system service provider, a financial institution or the merchants themselves.

[0110] Distributed Components

[0111] The payment system may be distributed between multiple locations and entities. Even individual components, including those shown in FIG. 1, may themselves be partitioned and distributed. For example, the customer access gateway <b>42</b> may be partitioned between any combination of telecommunications carriers and Internet Service Providers (ISPs). In another example, the security manager <b>18</b> may be under the control of and reside within a number of entities such as telecom carriers, ISPs and merchant or third party data centers. The database <b>24</b> may also be distributed such that different data tables (customer account <b>28</b> and merchant account <b>30</b>) are under the control of various entities supporting the payment system, such as ISPs, telecommunication carriers, banks, etc. In some cases, it might also be desirable to have, for example a directory of product offerings, that resides on some combination of merchant terminal equipment <b>50</b> at individual stores, centralized merchant data centers and the payment system service contractor.

[0112] Terminal Components

[0113] The terminal communications system <b>44</b> transmits payment and loyalty account information to the merchant terminal equipment <b>50</b> at each individual store location. The merchant terminal equipment (<b>50</b>) can include a variety of systems at the store location or distributed to remote data centers including, payment terminals, integrated POS systems, self-service kiosks and associated peripherals.

[0114] Transaction and customer payment account information are stored in nonvolatile memory in the merchant's payment terminal (<b>50</b>). The key components of the terminal are shown in FIG. 2. It will be clear that the components describe here can be included in any combination of dedicated payment terminal, Point of Sale system, self-service kiosk or other merchant terminal equipment, without changing the nature or function of the invention. Further, the components shown can be distributed between the different systems without changing the nature or function of the invention. The distributed components communicate over any type of suitable wired of wireless data network.

[0115] The central processor (<b>100</b>) provides the computing functions required to manage transactions. The central processor interfaces with and controls the other components of the terminal. The optional printer (<b>102</b>) is used to print receipts, signature slips, coupons or any other material required in printed form by merchants or consumers. The communications interfaces (<b>106</b>) are used to connect the terminal to the payment system host or directly to payment processors (<b>56</b>). The network can be any type of data connection including, wired wide area networks, wireless terrestrial networks, satellite networks (VSAT) and using any suitable data protocol such as the Internet Protocol (IP). The terminal can use multiple network connections to communicate with the server and payment processors (<b>56</b>). The central processor (<b>100</b>) uses the volatile memory (<b>108</b>) as it executes the payment algorithm programs. Customers use the bill acceptor (<b>120</b>) to fund stored value accounts as a self-service process. Payment account information is captured using the card swipe (<b>122</b>). It will be understood that a smart card reader, magnetic ink or optical check scanner, or the wireless base-station (<b>14</b>) can be used as well to complement or substitute for the card swipe without changing the nature or function of the invention. Any required manual data entry can be done with the keyboard (<b>124</b>), which can be supplemented with a mouse or trackball (not shown). Information is presented to customers and merchants via the display (<b>126</b>).

[0116] Customer account information (<b>112</b>), transaction data (<b>114</b>), business rules (<b>116</b>) and security data (<b>118</b>) are all contained within the nonvolatile memory (<b>110</b>). The nonvolatile memory provides a read/write media for longer-term storage of data. Any type of nonvolatile memory, including hard disk drives and flash memory is suitable.

[0117] Customer wireless access devices (<b>52</b>) communicate with the payment system through the local area wireless base-station (<b>104</b>) while the customer is in the store. The wireless base-station can use any suitable Radio Frequency (RF) technology, including those complying with the IEEE 802.11 or Bluetooth standards, or Infrared technology (IR) including the IR Data Access (IrDA) standard. Customer account numbers and security information are exchanged from customer wireless access devices and the terminal through the local area wireless base-station as an alternative to using a card swipe (<b>122</b>) or smart card reader. In an alternative embodiment the wireless base-station communicates with RF Identification (RFID) devices.

[0118] The optical scanner (<b>128</b>) is used to read information from customer coupons and other printed offers. The optical scanner can also be used to read customer information if the customer identifier is a bar coded card or other media.

[0119] Payment Transaction

[0120] The payment system is used for customer payment at merchant Points of Sale (POS), which include sites attended by a merchant employee or self-service (unattended or semi-attended) kiosks, vending machines or gas pumps. The majority of the transactions are performed using the customer account data stored in the payment terminal without the need to connect to the server through a network. The process flow for these payment transactions is shown in FIGS. 3A, 3B, <b>3</b>C, <b>3</b>D, <b>3</b>E, <b>3</b>F, <b>3</b>G, <b>3</b>H, <b>3</b>I, <b>3</b>J and <b>3</b>K.

[0121] Customer Account Retrieval

[0122] The process is initiated when the customer arrives at the point of sale (<b>500</b>). The customer presents their payment credential (<b>502</b>) or identifier and the information is captured using the card swipe (<b>504</b>). The terminal stores (<b>506</b>) the captured account number in volatile memory (<b>108</b>). Alternatively, the customer can enter another identifier such as a telephone number or user name.

[0123] If the transaction requires a PIN code (<b>508</b>) or other shared secret information the terminal displays (<b>514</b>) the request for this information on the terminal's display (<b>126</b>). The customer enters (<b>516</b>) the PIN typically using the keyboard (<b>124</b>). The terminal central processor (<b>100</b>) computes a hash (<b>518</b>) of the PIN and account number or other identifier. The central processor queries the customer account information (<b>520</b>) from the customer account information (<b>112</b>) in the nonvolatile cache memory (<b>110</b>). If a PIN or other shared secret information is not used the central processor queries the customer account information in the nonvolatile memory by account number or other identifier. The central processor determines if the required data is available (<b>522</b>) in the customer account information.

[0124] Customer Order

[0125] Once customer account information (<b>112</b>) is available, the terminal optionally displays customer service priority (<b>524</b>) including loyalty points, promotional offers and instant coupons (<b>526</b>), and customer ordering preferences (<b>528</b>) on the terminal display (<b>126</b>). Alternatively, this information can be presented in printed form using the printer (<b>102</b>). If the customer wishes to order a preference (<b>530</b>) the selection is entered (<b>538</b>) into the terminal typically using the keyboard (<b>124</b>). Alternatively, the customer can select an ad-hoc order, which is typically entered (<b>532</b>) through the keyboard (<b>124</b>) or by capturing product information, generally in Universal Product Code format, with a scanner (<b>128</b>). The customer selects the preference number (<b>534</b>) or other identifier for the order if the customer wishes to place the same order in the future. The preference is then stored in the customer account information (<b>112</b>) in the nonvolatile memory (<b>110</b>). It will be understood that the process described is essentially the same when used at an attended point of sale, a vending machine, a self-service kiosk or self-service fueling pump.

[0126] Payment, Coupons and Promotions

[0127] Once the customer has placed their order, the central processor (<b>100</b>) or other apparatus, such as a POS system, computes the price, tax, tip and service fee for the order (<b>540</b>). The customer is asked for their payment choice (<b>542</b>), typically through the display (<b>126</b>). Alternatively, the choice of payment can be determined in advance and stored as part of the customer account information (<b>112</b>). If the customer wishes to pay electronically (<b>544</b>), they are asked for any paper coupons or promotions (<b>548</b>) they wish to apply to the purchase. The coupon information, including promotion code and value, is captured by scanning with the optical scanner (<b>128</b>) a code on the coupon or manual entering the code (<b>550</b>) using the keyboard (<b>124</b>). The central processor (<b>100</b>) queries the business rules (<b>116</b>) in the nonvolatile memory (<b>110</b>). The central processor determines (<b>558</b>) if the coupon or promotion can be applied to the order. If not, the terminal displays the reason (<b>556</b>) on the display (<b>126</b>) and requests another coupon or promotion from the customer (<b>554</b>). If the customer has another coupon or promotion the process is repeated. If a coupon or promotion applies the central processor (<b>100</b>) applies the value to the price, tax, tip and service fee for the customer's order (<b>560</b>). The customer then has the option to try another coupon or promotion (<b>562</b>), which follows the same process.

[0128] The central processor (<b>100</b>) determines if there are electronic promotional purses (<b>568</b>) in the customer account information (<b>112</b>). If purses exist, the central processor sorts the purses into precedence order (<b>570</b>) using the promotional rules. The central processor then determines if the purse applies to the customer's order (<b>572</b>). If so, the central processor determines if there is sufficient value in the purse (<b>574</b>) to be applied to the order and applies this value (<b>582</b>) to the price, tax, tip and service fee as appropriate. Once one purse has been tested and perhaps used, the central processor determines if there is another purse to be applied (<b>578</b>). If so, the process is repeated.

[0129] The value of the coupons, promotions and promotional purses that have been applied is shown to the customer (<b>580</b>) via the display (<b>126</b>) or in printed form with the printer (<b>102</b>).

[0130] Stored Value Payment

[0131] If the customer has a cash stored value account (<b>590</b>) that is to be used for the payment the central processor (<b>100</b>) determines if the purchase is within the security limits set by the server. If not the terminal connects (<b>594</b>) to the server (if a connection is not already open) and requests an authorization for the transaction. If the authorization is granted (<b>596</b>) the central processor determines if there is sufficient balance (<b>598</b>) in the stored value account. If so, the central processor debits (<b>600</b>) the customer's account balance.

[0132] If the stored value account does not have sufficient balance additional funds are added to the account. The customer can choose to add funds to the account electronically (<b>602</b>). Alternatively the customer can add funds in cash (<b>604</b>) (or check) by presenting the cash to a merchant employee. The merchant employee enters (<b>606</b>) the cash amount using the keyboard (<b>124</b>). Alternatively, the customer can feed cash into the bill acceptor (<b>120</b>). The bill acceptor then captures the cash amount for the terminal.

[0133] If electronic funding is chosen the terminal requests the funding amount (<b>608</b>) funding through the display (<b>126</b>) and the amount is entered (<b>610</b>) through the keyboard (<b>124</b>) or determined from a value stored in the customer account information (<b>110</b>), which may then be verified through the keyboard. The electronic payment transaction process flow shown in FIG. 4 is then applied.

[0134] Once funds have been acquired for the stored value account the central processor (<b>100</b>) credits (<b>614</b>) the stored value account information in the customer account information (<b>112</b>) and the transaction information is stored in the transaction data (<b>114</b>) in the nonvolatile memory (<b>110</b>).

[0135] Direct Payment

[0136] If a stored value account is not being used, the customer makes the payment directly. The customer is given the choice of paying electronically (<b>616</b>). If the customer chooses cash (or check) they present the cash (<b>618</b>) to a merchant employee. Alternatively, the customer can feed cash into the bill acceptor (<b>120</b>). The merchant employee enters (<b>620</b>) the cash amount using the keyboard (<b>124</b>). Alternatively, the bill acceptor captures the cash amount. If electronic payment is to be used (<b>622</b>) the process flow shown in FIG. 4 is applied. Once the payment process is complete the transaction information is stored (<b>624</b>) in the transaction data (<b>114</b>) of the nonvolatile memory (<b>110</b>).

[0137] Adding Value to Promotional Purses

[0138] Once the transaction is complete the terminal determines if the customer should receive offers, promotions or coupons. These offers, promotions and coupons can be associated with existing purses or new purses can be created to hold the value.

[0139] The central processor (<b>100</b>) determines if the customer has existing promotional purses (<b>626</b>) in the customer account information (<b>112</b>). If so, the central processor sorts the purses (<b>628</b>) into precedence order for the addition of value using rules for the purses. The central processor determines if value should be added to a purse (<b>630</b>), and credits the value (<b>632</b>) to the purse if appropriate. If there are other purses (<b>634</b>) the process is repeated. Optionally the customer is shown (<b>636</b>) the accumulated value in the purses from all offers, promotions, loyalty points and coupons using the display (<b>126</b>) or in printed form using the printer (<b>102</b>).

[0140] The central processor then determines if the customer is qualified for other coupons, offers or promotions (<b>638</b>). The terminal displays or prints the coupons or offers (<b>640</b>) on the display (<b>126</b>) or printer (<b>102</b>). Purses are created for the offers and promotions and the value credited to these accounts (<b>642</b>).

[0141] If required the merchant employee then fulfills the customer order (<b>634</b>). Alternatively, a vending machine dispenses the selected product.

[0142] Data Query and Synchronization

[0143] If the customer account information (<b>112</b>) is not cached in the nonvolatile memory (<b>110</b>) the terminal will query the server to get the required information. If the terminal is not connected to the server (<b>646</b>) the terminal connects to the server (<b>648</b>) through the communications interfaces (<b>106</b>). The central processor (<b>100</b>) sends a query (<b>650</b>) to the server through the communications interface. The server transmits (<b>652</b>) the requested account information and indicates if the terminal is to cache (<b>654</b>) this information in the customer account information (<b>112</b>) in the nonvolatile memory (<b>110</b>). If not, the terminal will keep the account information in volatile memory (<b>108</b>) and not retain it once the transaction is completed. If the allowed, the terminal will cache (<b>656</b>) the account data in the customer account information (<b>112</b>) to use during this and subsequent transactions.

[0144] If the server determines the need to synchronize other data (<b>658</b>) the server synchronizes (<b>660</b>) customer account information (<b>112</b>), transaction data (<b>114</b>), business rules (<b>116</b>) and security data (<b>118</b>) with the nonvolatile memory (<b>110</b>) or cache memory in the terminal.

[0145] The algorithms used to determine which account information is to be cached and when synchronization occurs between the terminal and the server is discussed in the section Data Cache Synchronization below.

[0146] Electronic Payment

[0147] The invention supports the use of electronic payment both to fund stored value accounts and for direct payment. In either case the process shown in FIGS. 4A, 4B, and <b>4</b>C is followed.

[0148] If electronic payment account data is not stored (<b>670</b>) in the customer account information (<b>110</b>) the terminal requests the customer's payment credential (<b>672</b>) though the display (<b>126</b>). The payment credential could include a customer wireless access device (<b>52</b>), a magnetic stripe card, an optically coded card or other media, a smart card, a check draft or an RFID device. The customer presents the payment credential (<b>674</b>) and the payment account information is captured (<b>676</b>).

[0149] The central processor (<b>100</b>) applies transaction limits (<b>678</b>) regardless if stored payment account information or captured payment information is used. If the transaction is determined to be within the limits (<b>680</b>) the payment information is stored (<b>682</b>) in the transaction data (<b>114</b>) in the nonvolatile memory (<b>110</b>) for latter settlement.

[0150] If an online authorization is required (<b>680</b>) the terminal determines the connection path to used for the processor and payment type (<b>684</b>). If a PIN or other shared secret information is required by the processor (<b>686</b>) the terminal requests this information (<b>688</b>) though the display (<b>126</b>). The customer enters the PIN (<b>690</b>) thought the keyboard (<b>124</b>) and the central processor computes a PIN offset (<b>692</b>) or other hash as required. The terminal connects to the payment processor host (<b>694</b>) and requests an authorization. The connection path is through the communications interfaces (<b>106</b>) and can be with the payment system server of the invention or directly to the payment processor's host.

[0151] If the authorization is not received (<b>696</b>) the terminal informs the customer of the failure (<b>698</b>) through the display (<b>126</b>). The customer has the option to try another payment credential (<b>700</b>). If the customer chooses not to proceed the process is terminated. If the customer chooses they can present a new payment credential (<b>702</b>) and the payment account information is captured (<b>704</b>). The payment account is authorized using the process shown in FIG. 6 (<b>706</b>).

[0152] If data synchronization is required (<b>708</b>) the contents of the terminal cache or nonvolatile memory (<b>110</b>) is synchronized with the host. Finally, the transaction data is stored (<b>712</b>) in the transaction data (<b>110</b>) in the nonvolatile memory or cache for latter synchronization and settlement.

[0153] In an alternative embodiment, a signature is captured as part of the electronic payment process. The signature can be captured on a paper slip or in digital form. The need to capture a signature is determined by the payment processor or payment association rules and the merchants risk management polices.

[0154] Refunds and Reversals

[0155] The preferred embodiment of the invention enables merchants to issue refunds to customers using the merchant payment terminal of POS systems (<b>50</b>).

[0156] A unique transaction number printed on the customer's receipt is used to retrieve specific transaction information or the customer's identifier is used to retrieve the transaction record for that customer from which the correct transaction is selected. If the transaction is still in the nonvolatile memory (<b>110</b>) it is recalled from the transaction data (<b>114</b>) and displayed on the terminal display (<b>126</b>). The merchant employee can then issue a full or partial refund. A manager authorization code may need to be entered depending on the merchant's business rules. The refund information is logged in the transaction data record at the conclusion of the transaction. A printed receipt is generated on the printer (<b>102</b>) and presented to the customer. This process allows refunds to be processed offline without the need to connect to the server.

[0157] If the transaction data (<b>114</b>) of interest is no longer in the nonvolatile memory (<b>110</b>) the terminal connects to the server through the terminal communications system (<b>44</b>). A unique transaction number printed on the customer's receipt is used to retrieve specific transaction information from the server or the customer's identifier is used to retrieve the transaction record from the server for that customer from which the correct transaction is selected. The merchant employee can then issue a full or partial refund. A manager authorization code may need to be entered depending on the merchant's business rules. A printed receipt is generated on the printer (<b>102</b>) and presented to the customer. The refund information is logged in the transaction data record at the conclusion of the transaction.

[0158] Customer Account Creation

[0159] New customers will typically create new accounts for the payment system of the invention at a merchant's point of sale. The process flow for creation of a new customer account is shown in FIGS. 5A, 5B, <b>5</b>C, <b>5</b>D, and <b>5</b>E. At the same time, an electronic payment account is typically authorized following the process shown in FIGS. 6A, 6B, <b>6</b>C. It will be understood that the customers can establish accounts remotely using a customer access device (<b>52</b>) connected through the customer access gateway (<b>42</b>) to the payment server of the invention. This remote process follows essentially the same flow discussed in this section. Verification of identity and signature capture will be delayed until the customer is physically present at the merchant's location (typically performing the first transaction with the new account).

[0160] When a customer enters a merchant's business location (<b>720</b>) and approaches a merchant employee (<b>722</b>), typically to place an order for goods or service, the customer is asked if they wish to establish an account (<b>724</b>) for the electronic payment system of the invention. If not, the customers order and payment is processed in a conventional manner (<b>726</b>).

[0161] Payment Account Creation

[0162] The customer is asked if they wish to establish a stored value account (<b>728</b>). If not, the customer presents a payment credential (<b>730</b>, the information is captured from the credential, and the electronic payment account is authorized following the process shown in FIG. 6 (<b>732</b>).

[0163] If the customer does want a stored value account they select the funding method (<b>734</b>). If the customer wishes to fund the stored value account electronically (<b>736</b>) they present the electronic payment credential (<b>742</b>) and the information is captured. The payment account is then authorized following the process shown in FIG. 6 (<b>744</b>).

[0164] The customer presents cash to the merchant employee if the customer wishes to fund the stored value account with cash (<b>738</b>) (or check). Alternatively, the customer can feed cash into the bill acceptor (<b>120</b>). The merchant employee enters (<b>740</b>) the cash amount using the keyboard (<b>124</b>). Alternatively, the bill acceptor captures the cash amount.

[0165] Account Established

[0166] Once payment choices have been activated a customer account is established. The central processor (<b>100</b>) creates a new customer account (<b>746</b>) in the customer account information (<b>112</b>) in the nonvolatile (<b>110</b>) or cache memory. The electronic payment account information (<b>748</b>) and stored value account payment funding information (<b>750</b>) is stored in the customer account information (<b>112</b>).

[0167] If an identification card or other credential is to be issued (<b>752</b>), the employee swipes the card (<b>754</b>) with the card swipe (<b>122</b>) and the card number is captured (<b>756</b>) and stored in the customer account information (<b>112</b>). The card is then presented to the customer (<b>758</b>).

[0168] If the account is to be indexed by a stored by a hash rather than an account number (<b>760</b>) the central processor (<b>100</b>) computes the hash of the PIN or other shared secret information and the account number (<b>762</b>) and optional security code information. The hash is stored (<b>764</b>) in the customer's account information (<b>112</b>) and the actual values of the PIN and account number are deleted from nonvolatile (<b>766</b>) and volatile memory.

[0169] Creation of Promotional Accounts

[0170] Promotional accounts are created at the same time the customer's account is established. New purses are created based on paper coupons or promotions as well as electronic promotions.

[0171] If the customer has paper coupons or other introductory promotional offers (<b>768</b>) the information, including promotion codes, from these coupons is scanned (<b>770</b>) with the optical scanner (<b>128</b>) or manually entered using the keyboard (<b>124</b>). The central processor (<b>100</b>) queries the business rules (<b>116</b>) to determine if the promotion applies (<b>774</b>). If the promotion does not apply the terminal informs the customer using the display (<b>126</b>). If the customer has another coupon (<b>780</b>) the process is repeated.

[0172] If the coupon does apply, the central processor creates a new promotional purse in the customer account information (<b>112</b>) and stores the value of the promotion (<b>776</b>).

[0173] The central processor (<b>100</b>) determines if the new customer qualifies for other introductory coupons or promotions (<b>782</b>) using information in the business rules (<b>116</b>). If the customer is qualified the prints using the printer (<b>102</b>) or shows on the display (<b>126</b>) the coupons and offers the customer qualifies for (<b>784</b>). If the coupon or promotion does apply, the central processor creates a new promotional purse in the customer account information (<b>112</b>) and stores the value of the promotion (<b>786</b>).

[0174] Synchronization

[0175] If the terminal (<b>50</b>) is required to synchronize upon completion of the customer account creation process (<b>788</b>) the central processor (<b>100</b>) determines if a connection to the server exists through the communications interfaces (<b>106</b>). If not, a connection is established (<b>792</b>). The terminal and server then synchronize (<b>794</b>) the new customer account information (<b>112</b>) and other data in the nonvolatile memory if required (<b>796</b>).

[0176] Payment Account Authorization

[0177] Whenever a new electronic payment account is to be used by the customer the account must be authorized for use by the payment processor. This process is shown in FIGS. 6A, 6B, and <b>6</b>C. Once authorized the customer can use the payment account under the terms and conditions stated in the service agreement on a repetitive basis, generally without the need for additional authorization procedures by presenting a payment credential and providing shared secret information. Suitable payment types include credit and online debit accounts as well as offline debit methods such as checks and Automatic Clearing House (ACH) payments. The process described here is intended to be real-time and uses an online authorization for the payment processor as a significant step in the process. However with offline payment methods, a delay may be required to ensure the verification of the payment account information before the account can be used for transactions. Limitations on new accounts are discussed latter in this document.

[0178] When a new electronic payment account needs to be authorized the terminal determines the connection path to the processor (<b>799</b>) and connects (<b>800</b>) through the communications interfaces (<b>106</b>) to the server of the payment system of the invention through the terminal communications system (<b>44</b>), which connects to the payment processor (<b>56</b>) through the payment switch (<b>14</b>). Alternatively, the terminal (<b>50</b>) can connect directly to the external payment processor's server (<b>56</b>) through the communications interfaces (<b>106</b>).

[0179] Connection to the server is used to invoke globally controlled fraud management processes. The transaction manager (<b>10</b>) evaluates the fraud score of the account using the fraud profile database (<b>58</b>) and determines if this score is acceptable (<b>802</b>). Alternatively, the external payment processor (<b>56</b>) computes the fraud profile score. If the score for the customer is not acceptable the authorization process is terminated. Fraud management is discussed latter in this document.

[0180] The terminal requests an authorization and if this authorization is not received (<b>804</b>) the customer is informed of the failure (<b>806</b>) through the display (<b>126</b>). If the customer wishes to try another electronic payment account (<b>808</b>) and if there have not been too many attempts (<b>810</b>) the process is repeated. If the customer does not wish to try another electronic payment account the process terminates. The fraud management processes managed by the server or the invention, and discussed latter in this document, determine the number of tries allowed.

[0181] Once an authorization has been received from the payment processor (<b>56</b>), shared secret information is collected from the customer if this is required (<b>812</b>). Alternatively, shared secret information previously collected for the account can be used. The terminal asks the customer to enter shared secret information (<b>814</b>) through the display (<b>126</b>) and in response the customer enters the shared secret information (<b>816</b>) using the keyboard (<b>124</b>). The terminal asks the customer to reenter shared secret information (<b>818</b>) through the display (<b>126</b>) and in response the customer reenters the shared secret information (<b>819</b>) using the keyboard (<b>124</b>). If the two entries do not agree (<b>820</b>) the process is repeated.

[0182] Suitable shared secret information includes Personal Identification Numbers (PIN) or password. In an alternative embodiment, biometric identifiers are used instead of shared secret information, and can include, fingerprints, handprints, voiceprints, and retinal scans. In another alternative embodiment cryptographic security information contained in the customers wireless access device (<b>52</b>) is used, and can include, PKI certificates, symmetric secret key cryptographic methods or asymmetric secret key cryptographic methods. These alternatives in no way change the nature or function of the invention.

[0183] If signature capture and customer identification is required to authorize the payment account (<b>822</b>), the terminal requests the customer's signature (<b>824</b>) through the display (<b>126</b>) or producing a signature slip with the printer (<b>102</b>). The customer signs the signature slip or on a digital tablet attached as a peripheral to the terminal (<b>826</b>). The merchant employee verifies (<b>828</b>) the customer's signature and identity, ideally using a photo identification credential. The employee then enters a verification code into the terminal (<b>830</b>) using the keyboard (<b>234</b>). The verification code and digital signature information (if any) is transmitted to the server (<b>832</b>) for storage. At the end of the authorization process the terminal disconnects from the server (<b>834</b>).

[0184] The digital signature or paper signature slip is archived for latter retrieval in the event of a dispute between the customer and the merchant. The printed slip contains either a full or summary of the contract showing the terms and conditions for use of the payment system of the invention by the customer. Full versions of the contract can be provided in printed form at the merchant's location or sent through the mail. Alternatively, electronic versions of the full contract can be supplied by email or through an Internet web site.

[0185] Terminal Nonvolatile Memory Structure

[0186] All information required for the terminal to independently process payment transactions is held in the merchant terminal's (<b>50</b>) nonvolatile memory (<b>110</b>). This memory contains customer account information (<b>112</b>), transaction data (<b>114</b>), business rules (<b>116</b>) and security data (<b>118</b>). The structure of the information in the nonvolatile memory is shown schematically in FIGS. 7A, 7B, <b>7</b>C, <b>7</b>D, <b>7</b>E and <b>7</b>F. This information is accessed and used by the central processor (<b>100</b>) during payment and loyalty transactions. The information in the nonvolatile memory is synchronized over a data network with the information held in the server at times determined by either the transaction flow and volume at the terminal or global merchant fraud management processes run on the server.

[0187] In the preferred embodiment of the invention, the nonvolatile storage is organized as a tree or hieratical schema with a root (<b>900</b>). The nonvolatile memory (<b>110</b>) can be stored in a number of ways, depending on the exact configuration of the merchant terminal equipment (<b>50</b>). For example, if a standalone payment terminal is used the required information can be stored in flash memory on the terminal. In another example, with a multi-point or multi-lane POS system, the required information can be stored on a hard disk in the POS system server.

[0188] Customer Account

[0189] The customer account information (<b>112</b>) contains information required for customer payment and loyalty transactions. The customer account information stored in the terminal (<b>50</b>) nonvolatile memory (<b>110</b>) would only include the information required to perform payment and loyalty transactions at that specific store location. Customer account information pertaining to other merchants or locations would not be loaded into the nonvolatile memory at a particular merchant location at any time.

[0190] The data in the customer account (<b>112</b>) preferably contains:

[0191] 1) A unique account number (<b>904</b>) which may be stored as a hash of other information (i.e. account number and PIN) for security purposes,

[0192] 2) Customer name (<b>922</b>),

[0193] 3) User name or customer alias (<b>924</b>) used for account access,

[0194] 4) Security keys (<b>960</b>) or other security information required to interact with customer wireless access devices (<b>52</b>),

[0195] 5) Telephone number or other device identifiers (<b>966</b>), along with device type or capability information including device ID, such as, IP address, device capabilities for display, device capabilities for security, etc,

[0196] 6) Customer status (<b>956</b>) information including information on privileges (<b>958</b>) the customer may have as a result of their status, and

[0197] 7) Customer order prefaces (<b>1010</b>), preferably including,

[0198] a) A unique preference identifier (<b>1012</b>),

[0199] b) The payment account (<b>1014</b>) used to pay for the preference,

[0200] c) Item preferences (<b>1016</b>) comprising the order and composed of special instructions (<b>1018</b>) for the item, option or modifier identifier choices (<b>1020</b>) for the item, and a substitution list (<b>1022</b>) if the item is not available.

[0201] The customer account information (<b>112</b>) includes a payment wallet (<b>926</b>) containing all payment information and loyalty account information in one or more purses. The payment wallet preferably contains,

[0202] 1. One or more cash purses (<b>928</b>) with stored value account information (i.e. a prepaid account) and including the cash value of the account (<b>930</b>), the electronic funding account (<b>932</b>) for the stored value account, the funding method (cash, electronic, etc.) (<b>934</b>) for the stored value account, and payment limits (<b>936</b>) used for fraud management with the stored value account,

[0203] 2. Promotional value purses (<b>938</b>) preferably containing:

[0204] a. Information identifying the promotion (<b>940</b>),

[0205] b. The merchant promotional account (<b>942</b>) against which the value of the promotion is debited,

[0206] c. The value of the promotion (<b>944</b>) to the customer,

[0207] d. The exclusivity (<b>946</b>) of the promotion with respect to other promotions,

[0208] e. The precedence (<b>948</b>) rules and parameters for the promotion with respect to other promotions,

[0209] f. Lists of required or excluded items (<b>950</b>) for the promotion to apply,

[0210] g. Rules for the application of the promotion (<b>952</b>) to the order, and

[0211] h. Value limits (<b>954</b>) on the promotion used to prevent fraud,

[0212] 3. Electronic payment account (<b>1000</b>) information including,

[0213] a. The account number (<b>1002</b>), account reference used by the server to determine account number, or hash of the account number if the account number is not stored directly for security reasons,

[0214] b. Payment limits (<b>1004</b>) for use of the account without additional (typically online) authorization,

[0215] c. The payment type (<b>1006</b>), such as credit, debit, etc., and

[0216] d. The access path (<b>1008</b>) or processor information for that account.

[0217] Business Rules

[0218] The nonvolatile memory (<b>110</b>) contains information on business rules (<b>116</b>) that are applied to payment and loyalty transactions. Preferably, the business rules contain the following information:

[0219] 1. Payment types accepted at that merchant location and including the acceptance information (<b>914</b>) for that payment type, the merchant account number (<b>916</b>) used for settlement and the authorization rules (<b>918</b>) and limits for that payment type, and

[0220] 2. The promotions (<b>910</b>) accepted at that merchant location and preferable including the following information,

[0221] a. A name (<b>1060</b>) which the customers and merchant employees use to identify the promotion,

[0222] b. Internal identifiers (<b>1062</b>) for the promotion, which may include a promotion number (<b>1064</b>), promotion codes (<b>1066</b>) for tracking the promotion usage, and coupon codes (<b>1068</b>) used to tie electronic promotions to paper coupons and advertisements,

[0223] c. An indicator of the promotion type (<b>1070</b>),

[0224] d. The discount (<b>1072</b>) applied for the promotion, which may include, the merchant's promotional account (<b>11074</b>) to which the value of the promotion is debited, evaluation rules (<b>1076</b>) used to determine the value and applicability of the promotion, and the value (<b>1078</b>) parameters of the promotion,

[0225] e. Display symbols (<b>1090</b>) used to communicate to merchant employees that the promotion is applicable to the order and what the promotion is,

[0226] f. Relationships (<b>1080</b>) for application of the promotion, which may include; the exclusivity (<b>1082</b>) parameters of the application of the promotion to the order verses other promotions, the precedence (<b>1084</b>) for this promotion with respect to the applicability of other promotions, a list of items in the order that must be included or excluded (<b>1086</b>) for the promotion to be valid, and rules (<b>1088</b>) for the application of the relationship parameters, and

[0227] 3. The applicability (<b>1092</b>) parameters and rules of the promotion, which may include;

[0228] a. Applicable hours (<b>1096</b>, <b>1100</b>) for the promotion by days of the week (<b>1094</b>) and holidays (<b>1098</b>)

[0229] b. The start date (<b>1102</b>) of the promotion, and

[0230] c. The end data (<b>1104</b>) of the promotion.

[0231] Transaction Data

[0232] The transaction data (<b>114</b>) for the merchant location is stored in the nonvolatile memory (<b>110</b>). The transaction data contains the transaction history record and is synchronized as required with the data stored on the payment system servers. This transaction information is used for reporting on merchant account (<b>30</b>) activity performed by the report generator (<b>22</b>), customer account (<b>28</b>) activity, settlement for electronic payment accounts as performed by the settlement manager (<b>20</b>), and logging transaction information for auditing and archival purposes in the ledgers (<b>32</b>) and data warehouse (<b>38</b>). The transaction data stored on the terminal preferably includes,

[0233] 1) The transaction number (<b>1110</b>) for each transaction,

[0234] 2) The transaction type (<b>1112</b>) (refund, sale, etc.),

[0235] 3) The order path (<b>1114</b>) (in person, drive through, Internet, telephone, etc.),

[0236] 4) The cost of the transaction (<b>1116</b>), including, as appropriate, parameters for the total cost (<b>1118</b>), a subtotal (<b>1120</b>) of the goods and services ordered, the applicable taxes (<b>1122</b>), tip (<b>1124</b>), which may include a shift identifier or identifier for individual employees, and remote order or service fee (<b>1126</b>),

[0237] 5) A list of the items ordered (<b>1128</b>), including, as appropriate, parameters for the SKU, UPC or other product identifier (<b>1130</b>), modifiers for the item (<b>1132</b>), options for the item (<b>1134</b>), the unit price (<b>1136</b>) of the item, and the applicable tax codes (<b>1138</b>) for the item,

[0238] 6) The date (<b>1140</b>) of the transaction,

[0239] 7) The time (<b>1142</b>) of the transaction,

[0240] 8) The ID (<b>1144</b>) of the employee or manager handling the transaction,

[0241] 9) An employee or manager authorization code (<b>1146</b>) if required for the transaction,

[0242] 10) Information on the applicable settlement accounts (<b>1148</b>) for payment and promotions including, the settlement account or DDA number (<b>1150</b>), and settlement date (<b>1152</b>),

[0243] 11) The customer account (<b>1154</b>) used for the transaction including, the customer ID (<b>1156</b>), the payment types (<b>1158</b>) used, and the account numbers (<b>1160</b>) used for payment and loyalty, and

[0244] 12) Information on the customer order fulfillment time (<b>1162</b>).

[0245] Security Data

[0246] Security data (<b>118</b>) required for applying security policies for transactions, administration and reporting at each individual store location is stored in the nonvolatile memory (<b>110</b>). The security information preferably contains the following;

[0247] 1) Information for the store level payment system administrative account (<b>1024</b>) and including, shared secret information (<b>1026</b>) for access to the administrative account, rules and data for the administrative roles and privileges (<b>1028</b>) for the administrative account, and data access rules and information (<b>1030</b>) for the administrative account,

[0248] 2) Employee account (<b>1032</b>) information and including, shared secret information (<b>1034</b>) for access to the employee account, privileges and roles (<b>1036</b>) for the employee account, and data access (<b>1038</b>) privileges for the employee account, and

[0249] 3) Terminal security information (<b>1040</b>) for system or network access to the merchant terminal equipment (<b>50</b>) or POS system and including, Massage Authentication Code (MAC) keys (<b>1042</b>), secret key cryptographic (<b>1044</b>) information, Public Key Cryptography (PKI) certificates (<b>1046</b>) and other public key cryptographic information, and network addresses (<b>1048</b>) or other network or equipment identifiers.

[0250] Terminal Data Synchronization

[0251] Data stored in nonvolatile memory (<b>110</b>) on the merchant terminal equipment (<b>50</b>) must be synchronized with the customer account (<b>28</b>) information, merchant account (<b>30</b>) information, ledgers (<b>32</b>), security information store (<b>34</b>) and data warehouse (<b>38</b>) records in the server database (<b>24</b>). Synchronization ensures that the information in the merchant terminal equipment, at possibly many store locations, and the server database is in agreement and that the state of account and transaction information is up to date enough for transaction processing, reporting and settlement.

[0252] During data synchronization the merchant terminal equipment (<b>50</b>) connects to the payment system server through the terminal communications system (<b>44</b>). Data synchronization occurs under the control of the transaction manager (<b>10</b>) and the security manager (<b>18</b>) on the payment system server. Frequency and timing of synchronization events is determined by a combination of multiple factors including the following:

[0253] 1) Frequency of transactions at a location,

[0254] 2) Value of transactions at a location,

[0255] 3) Time of day and day of week and timing of employee shifts,

[0256] 4) Number and frequency of transactions where the customer account information is not in the terminal cache memory,

[0257] 5) Number and frequency of new account creation and authorization events, and

[0258] 6) Fraud management strategies for a location. Fraud management is discussed below.

[0259] Capacity Management

[0260] The peak transaction processing capability of the preferred embodiment of the payment system of the invention is extended through network and server capacity management. With dial-based data network connections the number of ports available in the terminal communications system (<b>44</b>) often limits the system capacity. In other cases, network bandwidth limitations or server and storage read/write speed limitations determine the maximum online transaction rate for the payment system. In all cases, the economics of operating the payment system are improved if a greater peak transaction rates are achieved without requiring additional capital equipment or telecommunications capacity.

[0261] The terminal communications system (<b>44</b>) under the control of the transaction manager (<b>10</b>) regulates synchronization processes to optimize transaction capacity of the system. Primary capacity regulation in the payment system of the invention is achieved by caching customer account information (<b>112</b>) and transaction data (<b>114</b>) in the nonvolatile memory (<b>110</b>) in the merchant terminal equipment (<b>50</b>). Those transactions that can be completed using this cached information require no server or telecommunications resources. Examples of capacity management strategies that can be employed with the preferred embodiment of the invention include:

[0262] 1. Delay synchronization for reporting and settlement purposes during peak transaction periods,

[0263] 2. Synchronization of data when an online payment authorization is required, and

[0264] 3. Synchronization of data when a new account is activated or an account is deactivated.

[0265] Account Number Hashing and Referencing

[0266] For security of account number information and to comply with some payment association and payment network rules account number information and PIN codes (or other shared secret information) are not stored directly in the nonvolatile memory (<b>110</b>) on the merchant terminal equipment (<b>50</b>). In the preferred embodiment of the invention, a non-reversible cryptographic hash of the customer payment account number and the PIN (sometimes referred to as a PIN offset) is stored. Thus, there is no permanent record of payment account numbers or shared secret information on the terminal. Account number information need only be stored in the secure payment system server. When the payment system server receives transaction data with hashed account numbers the transaction manager (<b>10</b>) performs a lookup in the customer account (<b>28</b>) to retrieve the unencrypted payment account number (possibly using a reference indicator <b>1002</b> if more than one payment account is active). The actual payment account number is then used for processes such as transaction logging in the ledgers (<b>32</b>) and data warehouse (<b>38</b>) and settlement processes executed by the settlement manager (<b>20</b>).

[0267] Network Cost and Capacity Management

[0268] In the preferred embodiment of the invention multiple data network paths or connections are used between the terminal communications system (<b>44</b>) and the merchant terminal (<b>50</b>). The connection or network path used depends on the costs or rate structure of the connection options and the transaction rates or bandwidth requirements. For example, a demand dial connection is typically billed based on a rate structure involving a connection or setup charge along with a per-minute charge. A continuous network connection is often billed on a variable basis depending on the time of the day (bulk rates from ISPs are billed in hourly increments and can depend on the time of the day). Yet other data connections (such as wireless data networks) are billed on the basis of the number of data packets (typically of a fixed size) sent and the time of day or day of the week. The terminal communications system can compute the most economical connection option based on the rate table for each option at each time of day and day of the week, the predicted number of transactions, and the predicted volume of data requiring transfer for synchronization in a give period of time. As history on transaction volume and volume of synchronization data is developed, the terminal communications system can improve these predications. The terminal communications system then uses the lowest cost option and instructs the terminal which connections to use at different times during the day and day of the week. When a transaction requires a connection from the terminal to the server, the central processor (<b>100</b>) picks the lowest cost communications interface (<b>106</b>) based on these instruction.

[0269] Network and Server Failure

[0270] In the event of network or server failure, the preferred embodiment of the invention supports offline loyalty and payment transactions using the customer account information cached in the nonvolatile memory of the payment terminal. Alternative payment methods are used for transactions where the customer account information is not in the terminal memory. These alternatives include payment in cash or electronic payment where the terminal receives an authorization by directly connecting to the external payment processor (<b>56</b>), possibly at a higher transaction and network cost. Loyalty points and other records can be collected in the terminal's nonvolatile memory for any customer account and are transferred to the server during synchronization once service is restored. Redemption of coupons, promotions and loyalty points can only occur for customers whose account information has been cached on the terminal.

[0271] Customer Account Fraud Management

[0272] The preferred embodiment of the distributed payment and loyalty system includes fraud prevention capabilities. The security manager (<b>18</b>) controls the fraud prevention processes using information in the data warehouse (<b>38</b>), the customer account (<b>28</b>), ledgers (<b>32</b>) and external fraud profile databases (<b>58</b>). The security manager also applies information received from the external payment processors (<b>56</b>), which can be in the form of authorizations, fraud profile information or fraud scores. Using this information the security manager applies policies to minimize the merchant's fraud risk while balancing the costs of performing transactions online verses offline and potential lost business from not being able to complete transactions that have too high of a fraud potential score. To enforce limits on accounts the security manager sets and dynamically updates security rules used by the transaction manager (<b>10</b>), the customer access gateway (<b>42</b>), the terminal communications system (<b>44</b>) and the merchant terminal equipment (<b>50</b>).

[0273] 1. Randomly samples for synchronization data.

[0274] 2. Sets “floor limits” on value and frequency for terminals for both new and established accounts based on fraud scoring.

[0275] 3. Can limit number of terminals with SVA balances to prevent “multi-point” attacks.

[0276] 4. During synchronization information on deactivated accounts is removed from the terminal's catch.

[0277] 5. Profiles accounts and deactivates or “puts on watch” bad or questionable accounts. On watch accounts are not cached to terminal and removed from terminal cache and may only be processed on line.

[0278] Fraud Profiling and Scoring

[0279] The security manager (<b>18</b>) scores customer accounts for fraud potential at payment account activation time and continues to profile ongoing account activity to detect fraud. The security manager supplements ongoing profiling with fraud scoring (particularly from external scoring services). Through the profiling and scoring process, the security manager determines parameters for rules used to limit merchant payment or fraud risk within constraints of limiting costs and lost business. These rule parameters are changed dynamically based on updated profiling and scoring information. Scoring a profiling techniques applied by the security manager include for both new and ongoing accounts,

[0280] 1. Checking “stop files” for known bad account numbers,

[0281] 2. Digit checks to confirm the validity of the account number or financial institution outing number,

[0282] 3. Checks for non-issued account numbers (not yet issued) or inactive account numbers,

[0283] 4. Account PIN verification,

[0284] 5. Account holder address and telephone number verification,

[0285] 6. Account expiration date,

[0286] 7. Frequency of purchases and sudden changes in frequency of purchases,

[0287] 8. Individual and total value of purchases per time period and sudden changes in these parameters,

[0288] 9. Limits on velocity between purchase location,

[0289] 10. Sequence numbers for checks,

[0290] 11. Reports of stolen account information or credentials,

[0291] 12. Customer history of valid use (time, total value of purchases, etc.),

[0292] 13. Sudden changes in purchasing behavior (frequency, value, location, etc.), and

[0293] 14. Declined authorization requests and reasons for decline.

[0294] Fraud Management Through Synchronization of Account Information

[0295] The security manager (<b>18</b>) and the transaction manager (<b>18</b>) control the synchronization of information in the nonvolatile memory (<b>110</b>) of the merchant terminal equipment (<b>50</b>). The timing or frequency of synchronization is determined by capacity demand on the servers and network facilities, frequency of online payment transactions and security requirements. The security manager (<b>18</b>) computes the timing and frequency of synchronization for each individual merchant location. This timing and frequency is based on a prediction of aggregate or weighted risk score for each merchant location and with the prediction based on a number of factors including:

[0296] 1. Risk scores of the individual transactions at the location,

[0297] 2. Frequency or volume of transactions at the location,

[0298] 3. History or detected fraud incidents at the location or other locations, and

[0299] 4. Dollar value of the transitions at the location.

[0300] Limits on Accounts

[0301] Depending on merchant, payment processor and RO system operator business rules and the type of payment account being used by the customer, limits are placed on a newly activated accounts and established accounts. Customer account limits (<b>936</b>) are updated, by the transaction manager (<b>10</b>) through the terminal communications system (<b>44</b>), in the customer account information (<b>112</b>) in the nonvolatile memory (<b>110</b>) of the merchant terminal (<b>50</b>) during the synchronization process. Limits on accounts include:

[0302] 1. Limits on each type of payment account (e.g. stored value, promotional, credit, debit),

[0303] 2. Limits on the value of a specific transaction,

[0304] 3. Limits on the total value of transactions per period of time (e.g. per day),

[0305] 4. Limits on the number of transactions per period of time (e.g. per day),

[0306] 5. Limits on transaction location (e.g. locations where the customer account information is cached in the terminal <b>50</b>),

[0307] 6. Manager approval required for transaction,

[0308] 7. Waiting period to establish offline account (e.g. ACH, check guarantee),

[0309] 8. Limits on items that can be purchased with the payment account, and

[0310] 9. Cash only customer.

[0311] In the preferred embodiment of the invention account limits are set based on fraud scores produced by one or more predictive algorithms run by the Security manager (<b>18</b>) using information gathered from the customer account (<b>28</b>), merchant account (<b>30</b>), ledgers (<b>32</b>), data warehouse (<b>38</b>), fraud profile database (<b>58</b>) and external payment processors (<b>56</b>). Data used in the predication of fraud scores include:

[0312] 1. Risk score for the customer payment account (see section above),

[0313] 2. Number of successful or failed transactions for the customer,

[0314] 3. Time the account has been active,

[0315] 4. Level of account activity,

[0316] 5. Merchant locations at which the account is used,

[0317] 6. Sudden changes in account activity,

[0318] 7. Method of payment (e.g. cash, stored value, credit, debit) and risk level for each method of payment,

[0319] 8. Availability of online payment authorizations,

[0320] 9. History of settlement failures, charge-backs, NSF conditions, stop payment, etc., and

[0321] 10. Changes in payment account being used.

[0322] Payment Account Expiration

[0323] Certain electronic payment account types (e.g. credit accounts) have expiration dates. These dates are either verified by the transaction manager or will be sent as a reason for a declined authorization request from the external payment processor (<b>56</b>) through the payment switch (<b>14</b>). In other cases, the customer may close a payment account and forget to update their payment account information in the customer account (<b>28</b>). In this case, the transaction manager (<b>10</b>) will typically be informed of the closed account situation by the external payment processor (<b>56</b>) when a settlement fails.

[0324] Once a payment account has expired, the customer account information (<b>112</b>) in the nonvolatile memory (<b>110</b>) is updated during synchronization with the server. Following synchronization the customer account information cached on the terminal (<b>50</b>) indicates that the customer's electronic payment account has expired.

[0325] When the customer attempts to use an expired payment account or a closed payment account they are notified by the transaction manager (<b>10</b>) of the problems on their customer access device (<b>52</b>) through the customer access gateway (<b>42</b>) or on the merchant terminal (<b>50</b>) through the terminal communications system (<b>44</b>). The notification can be in electronic display or printed form. The customer then has the options to either update the electronic payment account being used following the processes shown in FIGS. 5A, 5B, <b>5</b>C, <b>5</b>D and <b>5</b>E and FIGS. 6A, 6B and <b>6</b>C or to pay or fund a stored value account with cash. Once a new electronic payment account has been authorized the customer account information is updated to indicate this fact.

[0326] Customer Account Interface

[0327] In the preferred embodiment of the invention, customers can interact with the payment system of the invention using their wired or wireless customer access device (<b>52</b>) through the customer access gateway (<b>42</b>). Through this interface a customer can manage their account, receive account reports and fund accounts.

[0328] Account Management

[0329] The customer interface through the customer access gateway (<b>42</b>) using a customer access device (<b>52</b>) affords the same features for account creation and management (i.e. update payment account) available through the merchant terminal (<b>50</b>) through the terminal communications system (<b>44</b>).

[0330] Account Reporting

[0331] Customers can receive account reports on their customer access device (<b>52</b>) through the customer access gateway (<b>42</b>). These reports include information such as the balance of stored value and promotional accounts, transaction history and transaction details.

[0332] Account Funding

[0333] Customers can electronically add funds to a stored value account using their customer access device (<b>52</b>) through the customer access gateway (<b>42</b>). This process follows essentially the same process as would be performed at the merchant terminal (<b>50</b>).