WO2000050986A1

WO2000050986A1 - Secure flexible prepaid card system and method

Info

Publication number: WO2000050986A1
Application number: PCT/US2000/004654
Authority: WO
Inventors: Stuart A. Fox
Original assignee: Fox Stuart A
Priority date: 1999-02-24
Filing date: 2000-02-23
Publication date: 2000-08-31
Also published as: AU3242600A

Abstract

A system and method for securely and flexibly handling prepaid card transactions in a single store, chain of stores, or multiple independent stores or chains of stores. Point of sale terminals are programmed to read prepaid cards and contact a host computer that autorizes transactions. The host computer (6) accesses a database containing a list of all clerks authorized to use each terminal. In a preferred embodiment, three types of terminals are provided: activation terminals (3) that permit value to be added to prepaid card, clerk terminals (4) that permit value to be redeemed from, but not added to, prepaid cards, and manager terminals (2) that are capable of adding or deleting a clerk from the list of clerks authorized to use a terminal. The system also permits a merchant or customer service provider to directly access the data base from a computer in a secure restricted manner.

Description

Secure Flexible Prepaid Card System and Method

FIELD OF THE INVENTION

The present invention relates to prepaid card systems and, in particular, to a secure and flexible system and method for handling prepaid card transactions in a single store, chain of stores or multiple independent stores or chains of stores .

BACKGROUND OF THE INVENTION

Prepaid magnetic-strip cards have been used for years as payment for goods and services. Typically, prepaid card systems fall into two general classes. In one class, a value is stored in the magnetic strip on the back of the card and each time a card is used to purchase a good or service the stored value is decreased by the purchase amount. Prepaid cards used to pay for, for example, copies at copy machines typically fall into this first class.

In the other class, a value is not stored on the card itself, but instead is stored in an account on a computer. The card typically contains information identifying the account. Prepaid phone cards are an example of this type of system. Prepaid debit cards offered by some department stores and other stores are another example . Prepaid debit card systems at department and other stores have typically required a major investment in hardware and software. For example, one known technique has been to implement a prepaid debit card system on top of an existing store credit card system. This technique involves creating a credit card account with a preloaded credit (i.e., the value of the prepaid debit card) and a zero dollar credit limit (so that the card cannot be used to charge more than the preloaded credit) .

There remains a need however for a prepaid debit card system that can be implemented in stores and chains of stores that do not have the infrastructure to support a system in- house. There also remains a need for a prepaid debit card system that offers multi-level security features that will give merchants confidence that the cards are not used in a fraudulent manner and a need for a system that has the flexibility to exploit the many advantageous uses prepaid debit cards can have in business and marketing.

SUMMARY OF THE INVENTION

Briefly, the present invention provides a prepaid debit card system and method which is available to any merchant who has programmable point of sale terminals (such as those used to process credit card transactions) . The point of sale terminals are programmed so that they can read information encoded on a prepaid debit card and contact a host computer at a systems headquarters. The host computer processes prepaid card transactions of preferably numerous merchants and stores information about the transactions in a flexible, secure database.

The system provides multiple levels of security to prevent value from being added to a prepaid card in an unauthorized manner. First, only certain terminals are capable of adding value to a prepaid card and those terminals can be kept in a secured area. Second, a list of all clerks who are authorized to use each terminal is stored in the database, further preventing a clerk from initiating an unauthorized transaction. Third, only certain terminals, referred to herein as manager terminals, are capable of adding or deleting a clerk from the list of clerks authorized to use a terminal. Fourth, users who access the database directly by connecting to the host computer from another computer, instead of from a point of sale terminal, have a profile stored in the database specifying whether the user can add value to a prepaid card account , how much the user can add in a single transaction, and how much the user can add over a specified period of time, such as a day. In addition, the host computer limits each such user's access to the database to information regarding specific merchants and the profile further specifies which portions of the merchants' information is accessible to the user.

The system is also structured to exploit the use of prepaid cards as a business and marketing tool for merchants. For example, in a preferred embodiment of the invention, the database stores information necessary to implement a "buy ten get one free" type promotion and to implement a frequent buyer type promotion where cardholders are rewarded for the use of their prepaid cards. The present invention also provides a convenient and flexible mechanism for prepayment of a variety of services and products. One embodiment, described below, specifically provides a prepaid card system and method for payment of prepaid residential phone service.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram of the prepaid debit card system of a preferred embodiment of the present invention. Fig. 2 is a block diagram illustrating portions of the database used in an embodiment of the present invention. Fig. 3 is a block diagram illustrating additional portions of the database used in an embodiment of the present invention.

Fig. 4 illustrates transaction types comprising an embodiment of the present invention.

Fig. 5 is a flowchart illustrating an add or delete clerk operation initiated at a manager terminal.

Fig. 6 is a flowchart illustrating an activation operation. Fig. 7 is a flowchart illustrating a redemption operation.

Fig. 8 is a block diagram illustrating the services provided to a merchant by the host computer in a preferred embodiment of the present invention. Fig. 9 is a block diagram of the services provided to a cardholder in a preferred embodiment of the present invention. Fig. 10 is a flowchart illustrating commission payment.

Fig. 11 is a flowchart illustrating an activation operation of a prepaid residential phone card.

Fig. 12 illustrates detail_codes for a prepaid residential phone card.

Fig. 13 is a block diagram illustrating still additional portions of the database used in an embodiment of the present invention.

DETAILED DESCRIPTION OF THE

PREFERRED EMBODIMENTS

Fig. 1 illustrates the basic hardware setup of a preferred embodiment of the present invention. In this embodiment, a merchant having one or more stores accepts prepaid debit cards as payment for the purchase of goods and services . Each store contains one or more manager terminals 2, activation terminals 3 and/or clerk terminals 4. The preferred terminal is a Nurit 2080/2085 point of sale terminal manufactured by Lipman Electronic Engineering Ltd. However, any point of sale terminal or computer device with a prepaid card reading capability may be used if it can be programmed to perform the operations described herein.

The manager, activation and clerk terminals may be physically identical and their designations refer only to the functions a terminal performs. As explained below, manager terminal 1 can add or delete a terminal operator (also referred to herein as a clerk) to the system, activation terminal 2 can add value to a prepaid card, and clerk terminal 3 can redeem value from a prepaid card. Manager terminal 1 may also perform the functions of the activation and clerk terminals 3 and 4; and activation terminal 3 may perform the functions of clerk terminal 4.

Each terminal is connected, preferably by a dedicated phone line 5, to host computer 6 in systems headquarters 7. Host 6 processes transactions initiated by terminals 2, 3 and 4 and updates and maintains database 8, which is on central server 15. Database 8, described below, contains information about merchants, terminals, users and transactions. Host 6 and central server 15 are preferably industrial-grade Intel Pentium^® II based computers running the Microsoft™ Windows NT Server operating system and the Microsoft™ SQL Server database backend program. In one embodiment of the present invention host computer 6 is a Compact Proliant 3000 server with dual Intel Pentium^® II 450 MHz processors and central server 15 is a Compact Proliant 3000 server with a single Intel Pentium^® II processor. Host computer 6 may be comprised of multiple computers in order to efficiently process numerous simultaneous calls from terminals 2, 3 and 4 in stores 1.

Host 6 is also attached to one or more workstations 9. Workstations 9 are used, for example, by customer service 10 to access and maintain information in database 8. They may be any computer capable of processing web-based documents. A customer 11 calling customer service 10 is first connected to an IVR (integrated voice response) unit 12 where the customer's request is handled in an automated fashion. IVR unit 12 passes the call to customer service 10 if the automated response does not address the customer's question.

Host 6 is also connected to merchant computer 13 via phone lines, Internet, local or wide area network or other means. This enables the merchant to request and receive reports regarding prepaid card transactions, to review and update database 8, and to perform other operations. Merchant 14 may also directly contact customer service 10, for example, to establish an account in the database 8.

Database Overview

Figure 2 illustrates the general structure of database 8. Each box represents a table in the database and the contents of a box identify the fields of a record in the table. A line between two boxes indicates that the two tables have common fields, indicated by the endpoints of the line, over which they can be joined. As used herein, the tables are said to be "linked" on the common fields. The tables themselves are preferably stored in multiple files with table entries for each merchant stored in files in directories uniquely associated with the merchant .

Merchants table 21 contains general information about a merchant, such as when the merchant's merchants table entry was created (the receipt_data field) , the types of payment it accepts (Visa/Master Card, American Express, prepaid cards, ATM cards, check verification, Diners Club, Discover, EBT (food stamps) , and other) (the visa, amex, prepaid_cards , atm, check_verify, diners, discover, ebt and other fields, respectively) , whether the merchant signed up for a payment and service program (the _7.erαant_c2u. field) , whether the merchant's account has been cancelled (the cancelled field), its legal business name (the legal_businessname field) , its DBA (doing business as) name (the dba field) , its tax identification number (the tax_id field) , the name and phone and fax number of a contact person (the contact, contact_phone , and contact_fax fields) , its physical and mailing addresses (the nine fields starting with the "phys_" and "mail_" prefixes) , its field of business (the sic_code field) and a bank account routing number and bank account number (the aba and account_no fields) . It also contains a merchant identification number, merchant__id, which is assigned by the system and uniquely identifies the merchant, and a sales representative identification number (rep_id) , which identifies the sales representative that sold the merchant the prepaid card system. The rec_id field contains a unique number assigned to each record in the table.

Principals table 22 contains information about the principals of each merchant. This information may include the principal's name, driver license information, phone number, social security number, date of birth, address, length of time as principal and percent ownership (the legalname, drivers_license and lic_expdate, phone, ssn, data_of_Jbirt , address, ci ty state and zip, years, months and percent ownership fields) . It is linked to the merchant table on the merchant_id field. Multiple principals table entries may exist for each merchant. The principal_id field contains a unique number assigned to each principal .

Rates table 24 contains information about the rates charged to a merchant for each of the various forms of payment accepted by the merchant. A rates table entry exists for each form of payment accepted by a merchant . The type of payment is provided in the type field. For prepaid cards, the merchant is charged, in one embodiment, a per item fee on each sale using a prepaid card, as specified in the mer ch_per_i tern field. Alternatively, a merchant may be charged a percentage of the sale price. Also, a merchant may be charged a fee for receiving a statement, as specified in the -77erc_s atement_fee field. A merchant may also receive a commission, specified in the merch__commission field, for certain types of transactions; for example, a merchant may receive a commission for a sale of a prepaid card. Rates table 24 also stores information regarding up to three levels of commissions to be paid to sales representatives who were involved in the sale of the prepaid card system to the merchant (repl_commission, rep2_commission and rep3_commission) . These values may be used to vary the default commission for a representative given in reps table 23 described below. Rates table 24 is linked to merchants table 21 on the merchant_id field. The representatives are identified through the rep_id field in the associated merchant table entry. The id field contains a unique number assigned to each record in the table.

Reps table 23 contains information about the sales representatives that sold the prepaid card system to a merchant. This information may include the representative's name and initials (the ini tials, firstname, lastname, and mini tial fields) , business name (businessname field) , social security number ( ssn field) , hire and termination dates (hiredate and termdate fields) , address (address, city, state and zip fields) , phone, fax and email information (phone, fax and email fields) , default commission rate (defaultcom field) and a flag indicating whether a commission report is sent to the representative (report field) . A reps table 23 entry is linked to the merchants table on the rep_id field. An entry in the reps table may also be linked, on the iso_id field, to another reps table entry, thus identifying a sub- representative. In the preferred embodiment, two sub- representatives may be entered for each representative, for a total of three representative and sub-representatives. The three correspond to the three levels of commissions in rates table 24. Any number of representatives and sub- representatives may be allowed in alternative implementations of the present invention. Each record in reps table 23 is also linked on the type field to the type_id field in rep_type table 25. J2ep_type table 25 identifies the type of sales representative (internal or external) in its description field.

Terminals table 26 contains information about each terminal owned by each merchant. Multiple records in terminals table 26 may be associated with a single merchants table entry. The merchant_id field identifies the store where the terminal is located and provides a link to the store's entry in merchants table 21. The owner_id field identifies the owner of the store if, for example, the store is part of a chain. The millennium_no field contains an identification number assigned to each terminal by the system. The manager_card field contains the manager card number for the terminal. A terminals table record is linked on the millenniu_τι_no field to possibly multiple records in terminal^passwords table 27. Other information about each terminal may include identification numbers of various debit/ATM and credit card processors (the lynk_no, gensar_no, visanet_no, buypass_no, and mellon_no fields) , serial numbers and manufacturer/model information for the terminal, its pinpad and its printer (the serial_no, pinpad_sernum, printer_sernum, terminal _type , pinpad_type and printer_type fields) , the date the terminal was shipped to the customer ( ship_date field), the version number of the terminal's software ( version field) , a flag indicating whether use of the terminal is password protected (i.e., limited to certain clerks as described below) (password field) , and whether a terminal is, e.g., leased or purchased (purchase_type field). The rec_id field contains a unique number assigned to each record in the table.

Terminal_passwords table 27 contains the passwords (or clerk numbers) of the clerks who are authorized to use the terminal identified in the millennium_no field. The password field contains the password or clerk number. Multiple terminal_passwords table entries may exist for each terminals table entry. The rec_id field contains a unique number assigned to each record in the table.

Figure 3 illustrates other tables in database 8. Cards table 41 contains an entry for each prepaid card that is distributed to a merchant. The Pin field contains a unique identifier for each prepaid debit card. This identifier is also encoded in the magnetic strip on the back of the card (or printed on or otherwise associated with a card) . The Product_id field links the entry to an entry in Products table 42, which identifies the type and characteristics of the prepaid card. The Control_no, Batch, and Lot fields provide tracking information for each card. The Disabled field indicates whether the card has been disabled. The Balance field specifies the current cash balance available on the prepaid card. Other fields in Cards table 41 are discussed below.

Products table 42 contains information about groups of cards. The Id field contains a product identification number. The Description field identifies the type of the cards in the group (e.g., prepaid debit card, prepaid phone card, etc.). The Disabled field indicates whether all the cards in the product are disabled. The Pin_count field contains the number of cards in the group and the Activation_count contains the number of cards that have been activated. The [Jsage_amount field contains the total amount debited from all the cards in the group and the Ac ivation_amount contains the total amount of value added to the cards in the group. The Prompt field indicates the language that prompts from the host computer should be in. The Expire_date field contains the date on which all cards in the group expire. The Program_id field identifies the software program that is associated with the cards in the group; for example, one program may be run for a specific group of prepaid debit cards and a different program may be run for a different group of cards. Finally, the Rechargeable field indicates whether the cards in the group may be recharged (i.e., whether value may be added to a card) .

Transactions table 43 contains information about all transactions processed by the system. The rec_id field is a unique identification number assigned to each record in the table. The Datetime field specifies the date and time of a transaction. The Pin field specifies the pin number of the prepaid card used in the transaction and provides a link to the entry for that card in cards table 41. The Type field specifies the type of the transaction. These types include (1) original activation, (2) recharge, (3) return, (4) CS (customer service) credit, (5) test transaction, and (6) redemption, as shown in Figure 4. The test transaction type is used to test the system. The other types of transactions are described below. The Account_id field specifies the terminal number of the terminal on which the transaction was performed and provides a link to the entry for that terminal in terminals table 26 -- Account_id in transactions table 43 has the same meaning as millennium__no in terminals table 26. The Amount field contains the amount of the transaction, if applicable. The Clerk field contains the password (or clerk number) of the clerk (or other user) that handled the transaction; it has the same meaning as the password field in terminal_passwords table 27. The Ach_flag and Aα_date ime fields indicate whether the system has processed the transaction against the merchant's account and, if so, when. The Client and Port fields indicate the host computer that processed the transaction, if there is more than one host, and the port number on the host computer that was used.

A person skilled in the art will recognize that there are many different ways of configuring the tables in database 8, and the present invention is not limited to the configuration shown herein. Different and/or additional tables may be used and different and/or additional fields may be used in the tables.

Additionally, tables and fields may be added to database 8 to support, for example, a prepaid phone card system. In this case, rates table 24 could, for example, contain rate and commission information regarding phone card plans, cards table 41 and products table 42 could contain rateplan information, and additional tables could be added that stored inbound and outbound call information for each card and call routing and language information for each prepaid phone card product .

Manager Terminal Manager terminals are, in one embodiment of the present invention, the only terminals at which clerks or other terminal operators can be added or deleted from database 8. For added security, the add/delete function can only be activated after a valid manager card is swiped through the terminal. Manager cards are provided by Lipman Electronic Engineering, Ltd. for each Nurit terminal to enable restricted access to special terminal features that may be r defined by purchasers of the terminals. The add/delete clerk function is not a feature of the standard Nurit terminal. The add/delete clerk function is illustrated in Figure 5. In step 70, a manager or authorized clerk swipes a manager card through the manager terminal . In step 72 , the manager then selects an add or delete clerk operation on the terminal. In step 74, the manager enters a clerk number (or password) . In step 76, the terminal then calls host 6 in systems headquarters 7 and sends it a message containing a transaction code specifying either an add clerk or delete clerk transaction, the terminal's identification number, the clerk number, and manager card identification information.

In step 78, host 6 examines terminals table 26 in database 8 and determines whether the received terminal number is valid -- i.e., whether an entry exists for it in the database. If it is valid, then host 6, in step 80, tests whether a valid manager card was used. If the manager card is valid, step 86 is executed. Otherwise, if either the terminal number or manager card is invalid, step 82 is performed in which host 6 sends a message to the terminal indicating that the transaction is not authorized.

In step 86, the received clerk number is added or deleted, depending on the transaction code, to or from the database. For an add clerk transaction, a terminal_passwords entry is created, with the password being the received clerk number (or password) , for each terminal in the same store as the calling terminal (i.e., each terminal whose terminals table entry has the same merchant_id as the calling terminal) . For a delete clerk transaction, every entry in terminal_passwords table 27 whose mille.riniu-n_.no identifies a terminal in the same store as the calling terminal and whose password is the same as the received clerk number (or password) is deleted.

In alternate embodiments, different or additional information may be transmitted from the terminal to host 6. For example, the manager or authorized clerk may also specify a specific terminal number or set of terminal numbers that a clerk is to be added to or deleted from. Also, a software version number may be transmitted so that the host can check it against the version field of the calling terminal's entry in terminals table 26, as an added verification of the calling terminal.

Prepaid Debit Card In one embodiment of the invention, each prepaid debit card has a magnetic strip on the back having data in the following format: account number, field sep, yymm, use code, filler

where account number is preferably a long random number assigned to the card; field sep is a field separator, such as ' = ', yymm is the year and month the card expires; use code is the American Bankers Association code specifying where geographically the card can be used (a use code of 101 means the card can be used anywhere) ; and filler is filler for possible future use. An entry in cards table 41, described above, is created for each card that is manufactured and shipped to a merchant. Preferably, a card is initially given a balance of $0 (i.e., the Balance field of its Cards table entry is set to 0) , though a merchant may request that the accounts be preloaded with some value for, for example, a promotion.

Activation Terminal Activation terminals 3 (and manager terminals 2) contain software that enable value to be added to a prepaid card. Clerk terminals 4 do not contain this software and therefore a clerk without access to an activation or manager terminal cannot perform this function.

Figure 6 is a flowchart illustrating the process of adding value to a prepaid card from an activation terminal. In step 90, a clerk swipes a customer's prepaid debit card in an activation (or manager) terminal . The terminal then prompts the clerk for the type of transaction and in step 92 the clerk selects an activate (add value) transaction. The clerk then enters the amount to be added to the prepaid card and his or her clerk number in steps 94 and 96.

In step 98, the terminal connects to host 6 via, in one embodiment, an asynchronous modem connection, and transmits a message having the following format :

<stx>_/MESSAGE<etxxlrc> where <stx> is a start of text indicator, <etx> is an end of text indicator and <lrc> is linear redundancy check, which is calculated from the body of the message and used as a simple error correcting mechanism. If the <lrc> calculated by the host does not equal the <lrc> sent by the terminal, the host sends a <nak> (negative acknowledge) character to the terminal and the terminal will resend the message. This is repeated up to three times before the host sends an <eot> (end of transmission) character and disconnects the phone line.

If the <lrc> calculated by the host matches the one sent by the terminal, the host processes the body of the message, MESSAGE. The MESSAGE sent by the terminal has the following comma delimited fields:

[transaction type] , [terminal number] ,

[pin number] , [amount] , [cleric number]

where transaction type is the type of the transaction, in this case an activate transaction, terminal number is the terminal number of the calling terminal, pin number is the account number encoded on the swiped prepaid card, amount is the amount to be added to the account associated with the swiped prepaid card, and clerk number identifies the clerk. In step 100, host 6 determines the type of transaction from the transaction type field of the received message. If it is an activation, the host then performs step 102 in which it determines whether the received terminal number is valid (whether it, for example, has a valid entry in terminals table 26) . If it is valid, the host determines, in step 103₇ whether the clerk is authorized to use the terminal. This is done by searching the terminal_passwords table 27 for an entry having millennium_no set to the received terminal number and password set to the received clerk number. If the clerk is authorized to use the terminal, the host then determines, in step 106, whether an entry exists in cards table 41 for a card with the received account number. If it does then processing proceeds to step 108.

If the results of any of the tests in steps 102, 103 or 106 are negative (i.e., the terminal is invalid, the clerk is not authorized to use the terminal, or the received prepaid card account number is invalid) , step 104 is performed in which the host sends a message to the terminal indicating that the requested transaction has been denied.

Otherwise, in step 108 the host calculates the new balance for the card by adding together the current balance for the prepaid card from the Balance field in the card's cards table entry and the received activation amount. It then sends a message to the terminal stating that the requested transaction is authorized (i.e., "OK") and what the new card balance is. The message is in the same message format as the one earlier sent from the terminal to the host -- <stx.> ,MESSAGE<etxxlrc> . The terminal performs an <lrc> check on the message and, if the message is valid, the terminal sends an <ack> (positive acknowledge) character to the host. Otherwise, the terminal sends a <nack> character to the host, and the host attempts to resend the message. If the host fails after three attempts, it sends an <eot> character and disconnects the phone line in step 112.

In step 110, the host tests whether it received an <ack> character back from the terminal. If it did, it hangs up the call in step 114 and updates the cards table entry for the received card number with the new balance. The host also creates an entry in transactions table 43. If this was the first time value was added to the card, the transaction type is set to indicate an original activation; otherwise, the transaction type is set to indicate a recharge.

If the host did not receive an <ack> character, but instead received a <nack> character, two more attempts are made to send the message from the host to the terminal and if those fail too, the host hangs up in step 112 and does not update the cards table . Clerk Terminal Clerk terminals 4 (as well as activation and manager terminals 2 and 3) contain software for redeeming value from a prepaid debit card and returning a prepaid debit card. A redemption is performed, for example, when the card is used to purchase goods or services .

Figure 7 illustrates the process of redeeming value from a prepaid card. The first six steps in the process are similar to those for the activation process described above. The clerk swipes a customer's prepaid card in a terminal in step 130, and selects a redeem operation at his or her terminal in step 132. The clerk then enters the amount to be redeemed in step 134 and his or her clerk number in step 136. The terminal then connects, via, for example, a dial-up connection, to host 6 in step 138, and sends a message having the same format as that for an activation except that the transaction type field specifies an redemption transaction.

In step 140, the host determines the type of the transaction and, if the transaction is a redemption, performs step 142. In step 142, the host determines if the call is from a valid terminal, for example, by checking whether a terminals table entry exists for the received terminal number. If the terminal is invalid, the host sends, in step 144, a message to the terminal indicating that it is invalid and hangs up (step 162) . If the terminal is valid, the host next determines, in step 148, whether the clerk is authorized to use the terminal. Again, this is done by checking if there is a terminal_passwords table entry in which the millennium_no field is set to the received terminal number and the passwords field is set to the received clerk number. If the clerk is authorized to use the terminal, the host then determines, in step 150, whether the prepaid debit card exists in database 8 by searching Cards table 41 for an entry whose Pin field is the same as the received card account number. If the card exists, and is not disabled, then step 154 is executed. If steps 148 or 150 determine that the clerk is not authorized to use the terminal or the prepaid card is not valid, the host sends, in step 152, a message to the terminal that the transaction is declined and hangs up (step 162) .

In step 154, the host compares the received redemption 5 amount to the current balance stored in the cards table entry for the card to determine if there is sufficient funds. If there is not sufficient funds, the host sends a message to the terminal indicating the current balance and that there is not sufficient funds for the transaction (step 156) and

10 terminates the phone connection (step 162) . If there is sufficient funds, the host sends a message to the terminal indicating the available balance left after the transaction and that the transaction is approved (step 158) . The host then waits for a positive acknowledgement from the terminal

15 (step 160) and if it does not receive one after three attempts to transmit the message to the terminal, it hangs up (step 162) .

If the host receives a positive acknowledgement it then updates the cards table entry for the received account number

20 by debiting the received redemption amount from the balance field and adding the redemption amount to the total_usage field (step 164) . The host also creates, in step 164, a transactions table entry, setting the Pin field to the received account number, the Type field to indicate a

25 redemption, the Account_id field to the received terminal number, the Amount field to the amount of the redemption, the Clerk field to the received clerk number, and the Ach_flag field to 0, indicating that commissions on the redemption have not yet been processed. The host then hangs up in step

30 162.

The process for a card return is similar to the processes described above. The clerk swipes the card, presses the appropriate keys on the terminal for a return transaction and enters his clerk number. The terminal then

35 calls the host computer, which verifies that the calling terminal is valid, that the clerk is authorized to use the terminal and that the card is valid. The host then sends a message to the terminal indicating the remaining card balance and, waits for a positive acknowledgement from the terminal. If it receives it, the host updates the cards table entry for the prepaid card, setting the balance to zero. It also creates a transaction table entry, setting the transaction type field to indicate a return.

All terminals also have software for producing batch reports that itemize and total all transactions performed at a terminal over a period of time.

Commission Payment Transactions table 43 is periodically scanned by host computer 6, preferably once a day, in order to collect commissions from the merchants for prepaid card transactions. A flowchart of this process is illustrated in Figure 10.

In step 250, the host computer sets the current entry to the first entry in the transactions table. Step 252 determines whether the transaction is a redemption by examining the entry's type field. If it is, step 254 is performed which determines whether the transaction has already been processed by examining the ach_flag field. If either the transaction is not a redemption or the transaction has already been processed, then processing continues at step 262. Otherwise, step 256 is performed, in which the host computer determines the amount of commission owed by the merchant. This involves finding the rates table entry associated with the transaction by tracing the links from transactions table 43 to terminals table 26, then from terminals table 26 to merchants table 21, and from merchants table 21 to rates table 24. In step 258, the commission is withdrawn from the merchant's bank account using the routing code found in the aba_no field of the corresponding terminals table entry. In step 260, commissions owed to sales representatives and sub-representatives are calculated using the information in the corresponding rates table entry found above and the corresponding reps table entry, which is found by following the link from the corresponding merchants table entry to reps table 23.

In step 262, the current entry is set to the next transactions table entry. Step 264 tests if the end of the table has been reached. If it has, the process is over (step 266); otherwise the process returns to step 252.

Merchant Services In a preferred embodiment of the invention, a merchant is provided direct access to the information stored in database 8, as illustrated in Figure 8.

In step 180, a user at, for example, merchant computer 13 (in Figure 1) connects to host computer 6 via, e.g., a dial-up connection, a hardwired connection or the Internet. For each user who may access host computer 6 in this manner, a users table entry must first be created.

Users table 28 is shown in Figure 2. The ini tials field contains the user's initials. The fullname field contains the user's full name. The password field contains a password for the user. The last_login field contains the date and time the user last used the system. The credi t field specifies whether the user is authorized to issue credit (i.e., add value) to a prepaid card. The credi t field specifies whether a user can issue a credit. The creditlimi t field specifies the maximum amount of credit the user is authorized to issue per transaction. For example, a user may be authorized to credit no more than $5 at a time. The dailylimi t field specifies the maximum amount the user is authorized to issue per day. The reps, merchants, and comms fields specify whether the user is authorized to access the reps, merchants and rates tables, respectively. The userε_id field contains a unique number assigned to each record in the table . In step 182, host computer 6 verifies the user's access rights by, for example, prompting the user for his or her initials and passwords, looking up the users table entry for the user having the entered initials and comparing the entered password to the password field of that users table entry. Alternatively, a user's access rights may be verified based on the phone number the user is calling from -- using ANI (automatic number verification) or Caller ID to identify the originating phone number -- or the Internet IP address of the user, if the user is accessing the host via the Internet. Other verification techniques may also be used.

In a preferred embodiment of the invention, operating system features on the host computer are used to limit a user's access to the database, permitting a user to access only the data of a specific merchant or group of merchants. For example, in Windows NT, a user's profile maintained by the operating system can be used to limit access by the user to files only in specified directories. Accordingly, on a Windows NT system, the tables in database 8 can be stored in multiple files, with each file containing data regarding one merchant and stored in a directory that only contains files regarding that merchant. A user's access to information about specific merchants can then be implemented using the directory restriction feature.

Returning to Figure 8, if access is denied in step 182, the connection is terminated in step 184. Otherwise, the user may choose either to access the raw data for the merchant directly (step 186) or to access the data through a browser-based interface 188 on the host computer. The former option would typically be chosen by users who have their own software for querying the data and generating reports. In either case, merchants are provided with real-time information about all transactions processed by host computer 6.

Interface 188 provides at least the following features: form queries 190, report generator 192 and card specific functions 194. Form queries 190 are forms which a user fills in to perform various queries on database 8. Report generator 192 generates daily reports 196, weekly reports 198 and monthly reports 200, which itemize and/or summarize prepaid card transactions for the merchant over the relevant time period. Reports may present information on a per terminal or per card basis, if desired. Also, reports may be sent to the merchant on a periodic basis by, for example, fax or mail. Reports for chains of stores, for example in a franchise, may be consolidated so that activations and redemptions among the various stores in the chain may be reconciled. For example, if over the relevant time period store A in a chain activated a card for $10 and did not redeem value from a card and stored B redeemed $5 but did not receive any money to activate a card, then $5 should be transferred from store A to store B, since store B gave the cardholder $5 worth of goods or services, but did not yet receive any payment for it.

Card specific functions 194 allow a merchant to directly service customers, if desired. Merchants may prefer however to have customers use customer service 10 in systems headquarters 7, as described below. Card-specific functions include looking up a balance on a prepaid card 202, issuing credit 204, and adding to, or otherwise accessing, information in a notes table, which is a log of cardholder requests and complaints. As a security feature, a user's ability to issue credit is limited by the information in the user's user table entry. As explained above, the user table entry specifies whether a user may issue credit (the credi t field) , the amount of credit that may be issued in a single transaction (the credi tlimi t field) and the amount of credit that may be issue in a single day (the dailylimi t field) . A credit issued through interface 188 (or customer service 10) generates a transactions table entry with the transactions type preferably set to indicate a CS (customer service) credit. A credit is also reflected in the cards table entry for the prepaid card, with the Balance and Total_credi ts fields being incremented by the credited amount . Also, a user's ability to access the reps table, merchants table, rates table is restricted based on the contents of the reps, merchants and comms fields.

5 Cardholder Customer Service

A cardholder who has questions about his or her prepaid card may call customer service, as illustrated in Figure 9. In step 220, a cardholder calls customer service and is connected to an IVR (integrated voice response) unit in step

10 222. The IVR unit handles certain requests in an automated fashion, such as a request to get the balance on a prepaid card 224 or to find the closest location accepting the cardholder's card 226. To get the balance, the IVR unit prompts the cardholder to enter the account number of the

15 card and then looks the information up in cards table 41. To get the closest location, the IVR unit preferably determines the cardholder's current location based on the originating telephone number, which is determined using for example ANI or Caller ID.

20 If the cardholder desires other services, the call is connected to a customer service representative 228. The customer service representative can for example provide information on past transactions 230, issue credits (if authorized to do so) 232, and add notes to the notes table

25 234. Each customer service representative has an entry in users table 28 and is provided access to database 8 in the same manner as other users . A customer service representative may have authorization to examine the data of multiple merchants.

30

Card Uses The prepaid card system of the present invention provides the flexibility to implement many special features. For example, a "buy 10 get 1 free" type promotion can be

35 implemented by adding a num_times__used field to cards table 41, which contains the number of times a card has been used for a redemption. When a card is used for a transaction, the host computer can then include in a message to the terminal that the cardholder is, for example, entitled to one free product if the card was previously used ten times, two free products if the card was previously used twenty times, etc. If the cardholder chooses to accept a free product, the num_times_used field is decremented by ten. Of course, any number of previous uses may be used and any bonus or prize may be substituted for a free product. For example, a cardholder may be given discounted products instead of free products or the cardholder may have value added to his or her card.

Similarly, a frequent user rewards program, in which a cardholder earns points towards free or discounted products or other prizes, can be implemented by adding a redeemed_points field to cards table 41. For example, each dollar spent may be considered a point toward a bonus or prize. The Total_usage field in cards table 41 then corresponds to the total number of points a cardholder has earned and the redeemed_points field would contain the total number of points a cardholder has already cashed in. The Total_usage minus the redeemed_points in this example gives the currently available points .

The prepaid cards may also be conveniently used to serve various business functions. For example, a prepaid card may be used as a store credit voucher for returned items, instead of the slips of paper that are now typically used. They may also be used as a store credit voucher even without a return, for example, as a grand opening promotion or other promotion. The prepaid card system of the present invention is not limited to the uses and the specific implementations described above .

Prepaid Residential Phone Cards An embodiment of the present invention for paying for prepaid local phone service is illustrated in Figures 11 through 13. Prepaid local phone services are used by customers who, because of credit problems or other reasons, do not qualify for regular phone service in which bills are sent typically monthly. In known such services, the customer must go each month to a vendor associated with the service provider and prepay the bill for the following month. For an initial activation of the service, the vendor must get required information from the customer, such as the customer's name, address and types of services desired (e.g., call waiting, caller ID, call forwarding, etc.) and communicate this information to the service provider. Each subsequent month, when the customer prepays for the next month, the vendor must communicate payment information, as well as any changes in requested services, to the service provider. This process is burdensome to some vendors.

This embodiment of the present invention simplifies and automates the above process. Briefly, for an initial activation, the vendor provides the customer with a prepaid card, as described above, swipes the card in a terminal and enters the amount of money provided by the customer, information regarding the desired services and the vendor's clerk number. The terminal then calls the host computer, which verifies the clerk number and that the received amount is sufficient. The customer later directly calls the service provider (e.g., using a service provider's toll free number), provides the account number on the prepaid card and provides the required account set-up information. For subsequent payments, the vendor swipes the customer's card at the terminal (or enters the customer's phone number if the customer does not have the card) and enters the amount of money provided by the customer, information regarding the desired services and the vendor's clerk number. The terminal again calls the host computer, which again verifies the clerk number and that the amount of money provided is sufficient. Figure 11 illustrates the activation process for this embodiment (i.e., adding value to a prepaid card account) in more detail. In step 300, the vendor swipes a customer's prepaid card or enters the customer's home phone number. The vendor then selects an activate transaction (step 302) and enters the amount of money provided by the customer (step 304) and the vendor's clerk number (step 306) . Next, the vendor enters a product code, indicating the services the customer wants to purchase (step 308) . In one embodiment this code is a sequence of two digit numbers, each number indicating a service. Examples of product codes for a prepaid residential phone card are shown in Figure 12. In step 310, the terminal connects to host 6 via, in one embodiment, an asynchronous modem connection, and transmits a message having a format similar to that described above in connection with Figure 6 except that the clerk number field is divided into two fields, as follows:

[clerk number] | [product code]

where clerk number identifies the clerk and product code is the entered product code. The host computer then processes the received message as in Figure 6, first determining whether the transaction type is an activation (step 312) and then determining whether the call is from a valid terminal (step 314) , whether the clerk is authorized to use the terminal (step 316) and whether the prepaid card used in the transaction has an entry in cards table 41 (step 318) . In this embodiment, cards table 41 will also contain a phone field, identifying the phone number associated with the card, if one has been assigned, so that cards table 41 can" be searched both on a received card pin number or a received phone number. If the terminal is not valid, the clerk is not authorized or the card is not in the database, the host sends a message to the terminal indicating that the requested transaction is denied (step 330) and hangs up (step 322) . Otherwise, step 324 is performed. In step 324, the host computer determines the price of services specified in the product code. First, the product table entry associated with the card is found via the link between the product_id field of the cards table entry and the id field of an entry in products table 42. Next, for each two-digit subcode in the received product code, the host locates an associated product_details table entry. The format of product_details table 372 is shown in Figure 13. The rec_id field is a unique identifier for each record in the table. The detail_code field is a code identifying a service/product, such as those shown in Figure 12. The amount field specifies the price of the service. The description field provides a description of the service. The product_id field provides a link to the id field of an entry in products table 42 (shown in Fig. 2) . A products table entry may be linked to multiple product_details table entries. The host computer then sums the price of each service/product specified in the received product code.

In step 326, the host computer determines if the card's balance specified in the balance field of the located cards table entry plus the received amount is sufficient to pay for the services/products specified in the received product code. If it is not, the host sends a message to the terminal indicating that there is not sufficient funds and specifying the amount required for the requested transaction (step 328) and hangs up (step 320) . Otherwise, the host sets the balance field of the cards table entry to the new balance and sends a message to the terminal stating that the transaction is authorized and what the new card balance is (step 332) . The host then checks if the terminal positively acknowledges receipt of the message (step 334) .

If a positive acknowledgment is received, the host computer hangs up (step 336) and, in step 338, updates the cards table entry with the new balance and creates a transactions table entry. In this embodiment, each transaction table entry is linked to possibly multiple transaction_details table entries, which are also created at this time. The format of transaction_details table 370 is shown in Fig. 13. The rec_id field is a unique identification number assigned to each entry in the table. The transaction_id field links the entry to an entry in transactions table 43. The prOduct_detail_id field links the entry to an entry in product_details table 372. The Export_Status field, as explained below, is set to 0 before the transaction has been posted for retrieval by the phone provider and 1 after the transaction has been posted. The Acknowldege_Date field indicates the date the phone provider has processed the transaction. For overcharge transactions received from the phone provider, which are described below, the amount field is set to the amount of the overcharge and the Acknowledge_Date is set to 3 after the transaction is processed.

If a positive acknowledgment was not received after three attempts, the host hangs up and does not update the database, (step 322) .

Periodically, preferably every minute, host computer 6 scans transaction table 43 for transactions involving residential phone cards. For each such transaction, the host computer posts the transaction information and the balance on the associated card and then sets the card's balance to zero and changes the Export_Status field of the associated transaction_details entries from 0 to 1. The information is posted such that the prepaid residential phone provider can retrieve it using, for example, a computer via an Internet or other connection. The residential phone provider then processes the transaction and contacts, again for example via a computer connection, the host computer which in turn sets the Ac.kn0uded2re_.Date field in the transaction_details entry for the transaction. Also, if the customer's balance exceeded the amount needed for the transaction, the provider sends overpayment information to the host computer and the host computer creates a transactions table entry, and an associated transaction_details entry, for the customer. In this case, the produσt_detail_id field of the trans action_de tails entry is linked to a product_details table entry for an Overpayment . The amount of the overpayment is stored in the amount field of the transaction_details table. When the host computer periodically scans the transactions table, it processes overpayment transactions by crediting the customer's card balance and setting the Export_Status field of the associated transaction_details table entry to 2.

For an initial activation transaction, the customer, after prepaying for the service at a vendor and receiving his or her residential phone card, calls the phone provider (from a payphone or other phone) and provides the card number and certain required information, such as his or her address. The provider then contacts host computer 6 using any of the techniques discussed above (for example, through customer service 10, using its own computer to directly connect to host 6, or using a terminal) and provides the customer's card number. The host computer then verifies that there is an initial activation transaction associated with the card number in the transactions table and that the card has a balance. If both items are verified, the host computer reports the available balance and the services/products sold to the customer. It then sets the Ac.cnow2edgre_.Date field in the associated transaction_detail table entries. If both items are not verified, the host computer reports that the card is not found or that it has no balance.

In this disclosure, there is shown and described only the preferred embodiments of the invention. It is to be understood that the invention is not limited to the particulars disclosed and extends to all equivalents included within the scope of the claims. For example, although particular data structures and algorithms were shown and described, other data structures and algorithms may equivalently be used. Moreover, the invention is not limited to particular types of hardware (computers, electronic device, etc.) . For example, manager, activation and clerk terminals may be any electronic or microprocessor-based device that performs the required functions; connections between devices, such as the terminals and host computer, may be any type of connection that permit the devices to communicate be it by telephone lines, wireless communications, local or wide area networks, or otherwise; and any device shown as a single unit may be implemented as multiple units (for example, multiple computers may comprise host computer 6) and multiple units may be combined into a single unit.

Claims

What is claimed is:

1. A prepaid card system comprising: a. one or more prepaid cards each having an associated account number; b. at least one activation terminal at which value can be added to the one or more prepaid cards; c . at least one clerk terminal at which value can be redeemed from, but not added to, the one or more prepaid cards; d. a host computer connected to the at least one activation terminal and the at least one clerk terminal ; and e. a database that can be accessed by the host computer wherein the database stores i) for each of the at least one activation and clerk terminals, information regarding each clerk authorized to use the terminal; and ii) for each of the one or more prepaid cards, a current balance associated with the prepaid card.

2. The system of claim 1 further comprising at least one manager terminal wherein: a. the database further stores, for each of the manager terminals, information regarding each clerk authorized to use the manager terminal; and wherein b. the information regarding each clerk authorized to use each of the activation, clerk and manager terminals can be modified from the manager terminal .

3. The system of claim 1 further comprising a second computer connected to the host computer wherein the database further stores information regarding access rights of users of the second computer to information in the database, including, for each user, a . whether the user may increase the current balance associated with each of the one or more prepaid cards ; b. an amount the user may add to the current balance associated with at least one of the one or more prepaid cards in a single transaction; and c . a total amount the user may add to the current balance associated with at least one of the one or more prepaid cards over a specified period of time.

4. The system of claim 1 wherein the database further stores for each terminal information regarding a merchant that owns the terminal .

5. The system of claim 4 wherein at least two terminals in the database are owned by different merchants.

6. The system of claim 1 wherein the database further stores transaction information regarding each modification to the current balance associated with at least one of the one or more prepaid cards, the transaction information comprising: a. an identification of the terminal at which the transaction was initiated, b. an identification of the clerk who initiated the transaction; c. an identification of the prepaid card whose current balance was modified; d. an amount of the transaction; and e. a type of the transaction.

7. The system of claim 6 wherein the database further stores merchant information comprising: a. a list of terminals associated with a merchant; b. a list of sales representatives entitled to commissions for transactions occurring at terminals associated with the merchant, c. information regarding commissions owed to the sales representatives on the list of sales representatives and a commission owed to an operator of the host computer, and d. information identifying a bank account number from which commissions are to be paid.

8. The system of claim 7 wherein the transaction information further comprises, for each transaction for which a commission is owed, information regarding whether the commission has been paid from the merchant ' s bank account .

9. The system of claim 5 wherein the database is structured such that information relating to a first merchant is stored in a different directory from information relating to a second merchant.

10. The system of claim 9 wherein a user at a merchant computer can be connected to the host computer, and wherein the host computer limits the user's access to the database to information regarding one or more specific merchants.

11. The system of claim 10 wherein the merchant computer connects to the host computer via the Internet.

12. The system of claim 1 wherein the database further stores, for each of the one or more prepaid cards, the number of times the card has been used.

13. The system of claim 1 wherein the database further stores, for each of the one or more prepaid cards, a bonus point total derived from the use of the card and a redeemed point total indicating then number of bonus points that have been redeemed.

14. The system of claim 13 wherein the bonus point total is the total dollar amount of transactions in which the card was used to purchase goods and services.

15. A method of processing prepaid card transactions comprising the steps of: a. reading a prepaid card, including identifying information, at an activation terminal; b. entering at the activation terminal a value to be added to the prepaid card; c. sending to a host computer (i) information identifying the prepaid card, (ii) the value to be added to the prepaid card, and (iii) identification information associated with a person operating the activation terminal; d. determining whether the person operating the activation terminal is authorized to operate the activation terminal and, if the person is authorized, adding the value to a balance stored in a database entry associated with the prepaid card; e. reading the prepaid card, including identifying information, at a clerk terminal; f . entering at the clerk terminal a value to be redeemed from the prepaid card; g. sending to the host computer (i) information identifying the prepaid card, (ii) the value to be redeemed from the prepaid card, and (iii) identification information associated with a person operating the clerk terminal; h. subtracting the value to be redeemed from the prepaid card from the balance stored in the database entry associated with the prepaid card if (i) the person operating the clerk terminal is authorized to operate the clerk terminal and (ii) the balance in the database entry associated with the prepaid card is greater than or equal to the value to be redeemed.

16. The method of claim 15 further comprising the steps of: a . reading at a manager terminal a manager card identification number from a manager card; b. entering at the manager terminal a manager terminal operation; c. entering at the manager terminal identification information associated with a person; d. sending to the host computer the manager card identification number, the operation and the identification information associated with the person; and e. determining whether the manager card identification number is from an authorized manager card and, if so, updating information in the database, based on the entered operation, regarding whether the person having the entered identification information is authorized to use certain activation, clerk and manager terminals.

17. The method of claim 16 where the operation is to authorize the person having the entered identification information to use certain activation, clerk and manager terminals .

18. The method of claim 16 where the operation is to remove authorization of the person having the entered identification information to use certain activation, clerk and manager terminals.

19. The method of claim 16 where the certain activation, clerk and manager terminals are all activation, clerk and manager terminals in the same store as the manager terminal sending information to the host computer.

20. A method of processing prepaid card transactions comprising the steps of : a. connecting a workstation to a host computer wherein the host computer can access a database storing information regarding prepaid cards and terminals for performing prepaid card transactions; b. determining access rights of a user at the workstation to the information in the database, including

(1) whether the user may increase a current balance associated with one of the prepaid cards;

(2) an amount the user may add to the current balance associated with one of the prepaid cards in a single transaction; and

(3) a total amount the user may add to the current balance associated with one of the prepaid cards over a specified period of time.

21. The method of claim 15 further comprising the step of sending terminal identification information to the host computer and wherein the steps of determining whether the persons operating the activation and clerk terminals are authorized comprises, for each such person, locating a database entry associated with the received terminal, the database entry specifying a list of persons authorized to use the terminal, and determining whether the person operating the terminal is on the list of the authorized persons.

22. The method of claim 15 wherein the steps of adding the value to the balance and subtracting the value to be redeemed from the balance further comprise, for each transaction, storing transaction information comprising: a. information identifying the terminal at which the transaction was initiated, b. information identifying the person operating the terminal ; c. information identifying the prepaid card whose balance was modified; d. an amount of the transaction; and e. a type of the transaction.

23. The method of claim 15 further comprising the steps of a. determining a list of sales representatives entitled to commissions for transactions occurring at the activation and clerk terminals, b. determining commissions owed to the sales representatives on the list of sales representatives and to an operator of the host computer, and c. paying the commissions from a specified account associated with the terminals.

24. The method of claim 23 further comprising the step of storing, for each transaction for which a commission is owed, information regarding whether the commission has been paid from the account.

25. The method of claim 15 further comprising storing in the database entry associated with the prepaid card the number of times the card has been used.

26. The method of claim 15 further comprising storing in the database entry associated with the prepaid card a bonus point total derived from the use of the card and a redeemed point total indicating the number of bonus points that have been redeemed.

27. The system of claim 26 wherein the bonus point total is the total dollar amount of transactions in which the card was used to purchase goods and services .

28. The system of claim 1 wherein a set of the one or more prepaid cards is for prepaying for a service billed on a periodic basis.

29. The system of claim 1 wherein a set of the one or more prepaid cards is for prepaying for prepaid local telephone service.

30. A prepaid card system for prepaying for a service billed on a periodic basis comprising: a. one or more prepaid cards each having an associated account number; b. at least one activation terminal at which value can be added to the one or more prepaid cards; c. a computer associated with a provider of the service; d. a host computer that can communicate with the at least one activation terminal and the provider computer; and e. a database that can be accessed by the host computer wherein the database stores i) for each of the at least one activation terminals, information regarding each clerk authorized to use the terminal; ii) information regarding access rights of users of the provider computer to information in the database; and iii) for each of the one or more prepaid cards, a current balance associated with the prepaid card and information regarding the prepaid service.

31. The system of claim 30 wherein the prepaid service is prepaid local phone service.

32. A method for processing prepaid transactions for a service billed on a periodic basis comprising the steps of: a. reading a prepaid card, including identifying 5 information, at an activation terminal; b. entering at the activation terminal a value; c. entering at the terminal a product code; d. sending to a host computer (i) the card identifying information, (ii) the value, (iii) the product

10 code, and (iv) identification information associated with a person operating the activation terminal ; and e. at the host computer,

(1) determining whether the person operating the 15 activation terminal is authorized to operate the activation terminal;

(2) if the person operating the terminal is authorized, locating a database entry associated with the prepaid card, the database

20 entry storing a balance;

(3) determining a price associated with the product code, and

(4) determining whether the received value plus the balance is greater than or equal to the

25 price and, if it is, adding the value to the balance in the database entry and storing information regarding the product code in the database entry.

30 33. The method of claim 32 further comprising the step of: sending to a computer associated with a provider of the service the card balance and the information regarding the product code and setting the card balance in the database entry to zero.

35

34. The method of claim 33 further comprising the steps of a. determining at the provider computer a price associated with the received product code information; and b. sending a message from the provider computer to the host computer instructing the host computer to credit the balance associated with the card if the price determined by the provider computer exceeds the balance received by the provider computer.

35. The method of claim 32 wherein the product code specifies an initial activation of the service and further comprising the steps of: a. providing, by a customer to a representative of the provider, information regarding the card and customer information required for activating the service; b. connecting a computer associated with the provider to the host computer and determining whether the representative is authorized to access information regarding the card; and c. if the representative is authorized, sending to the provider computer the card balance and the information regarding the product code.

36. The method of claim 32 wherein the service is prepaid local phone service.