WO2001015045A1

WO2001015045A1 - Methods and apparatus for managing prepaid transactions over a network

Info

Publication number: WO2001015045A1
Application number: PCT/US2000/022963
Authority: WO
Inventors: Dennis W. Andrews; Thomas E. Fedro
Original assignee: Ecatalystone.Com, Inc.
Priority date: 1999-08-20
Filing date: 2000-08-21
Publication date: 2001-03-01
Also published as: AU6923000A

Abstract

A management system manages transactions on a network such as the Internet by utilizing a prepaid instrument having information including a monetary value and a security code. The prepaid instrument is purchased by a customer [83] from a distributor. In use, the management system receives the information of the prepaid instrument from the distributor via the network. The management system then triggers a transfer of funds from the distributor based upon the monetary value of the instrument. When the funds are received from the distributor, an amount specific to the prepaid instrument is enabled. The customer then sends an activation request associated with the prepaid instrument to the management system, which request includes the security code, a user ID, and a password. The management system then activates the account by associating the user ID and the password with the security code of the prepaid instrument. The customer is now able to make purchases over the network with the prepaid instrument. In the course of a transaction between the customer and a web merchant, the management system receives a query from a merchant regarding a purchase associated with the prepaid instrument. The management system then determines whether the account associated with the prepaid instrument has sufficient funds to cover the purchase. A signal is transmitted to the merchant indicative of whether the account has sufficient funds to do so. If the transaction is completed, a signal is then sent back to the management system from the merchant indicating the same. The management system then debits the account and transferred funds to the merchant based on the value of the purchase.

Description

METHODS AND APPARATUS FOR MANAGING PREPAID TRANSACTIONS OVER A NETWORK

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority on U.S. Provisional Application for Patent Nos. 60/149,681; 60/149,682; 60/149,685; 60/149,687; 60/149,692; and 60/149,693, each of which was filed August 20, 1999, the entire disclosure of each of which is incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to the electronic commerce over a communication network such as the Internet and, more specifically, to systems for securely exchanging monetary value for goods and services purchased over the Internet. The present invention relates to systems for managing economic exchange between merchants and consumers through the use of prepaid monetary instruments, ensuring the anonymity of the consumer through the transaction. The present invention improves upon conventional payment systems that utilize credit cards and electronic funds transfer for e-commerce.

BACKGROUND OF THE INVENTION

With the advent and looming dominance of the Internet in today's consumer market, conventional currency transactions between consumers and merchants have been redefined. Gone are the days of exclusive cash, check, or credit card transactions. Financial institutions and web merchants have had to develop new transaction techniques to ensure the integrity of the transaction and to maintain the privacy of the consumer.

Automation has achieved some of these qualities for large transactions through computerized electronic funds transfer (EFT) systems. Electronic funds transfer is essentially a process of value exchange achieved through a banking system's centralized computer transactions. EFT services are a transfer of payments utilizing electronic checks, which are used primarily by large commercial organizations.

Examples of EFT systems utilized by retail and commercial organizations include an automated clearing house (ACH) where a user can enter a pre-authorized code and download information with billing occurring later, and a point-of-sale (POS) system where a transaction is processed by connecting with a central computer for authorization for the transaction granted or denied immediately. However, the payments made through these types of EFT systems are limited in that they cannot be performed without the banking system. Current EFT systems, credit cards, or debit cards, which are used in conjunction with an on-line system to transfer money between accounts, such as between the account of a merchant and that of a customer, cannot satisfy the need for an automated transaction system providing an ergonomic interface.

To implement an automated, convenient transaction that can dispense some form of economic value, there has been a trend towards off-line payments. For example, numerous ideas have been proposed for some form of electronic money that can be used in cashless payment transactions as alternatives to the traditional currency and check types of payment systems. See, for example, U.S. Patent No. 4,977,595, entitled "Method and Apparatus for Implementing Electronic Cash," and U.S. Patent No. 4,305,059, entitled "Modular Funds Transfer System." Other techniques for automated transactions include magnetic stripe cards purchased for a given amount and from which a prepaid value can be deducted for specific purposes. Other examples include memory cards or so called smart cards which are capable of repetitively storing information representing value that is likewise deducted for specific purposes.

In an electronic environment, it is desirable for a computer operated under the control of a merchant to obtain information offered by a customer and transmitted by a computer operating under the control of the customer over a publicly accessible packet-switched network (e.g., the Internet) to the computer operating under the control of the merchant, without risking the exposure of the information to interception by third parties that have access to the network, and to assure that the information is from an authentic source. It is further desirable for the payment processing to be flexible and able to negotiate with the client customer to select a mutually acceptable payment protocol and other payment options.

One such attempt to provide a secure transmission channel is a secure payment technology known as the Secure Electronic Transaction (SET), jointly developed by the Visa and MasterCard card associations. Other such secure payment technologies include Secure Transaction Technology (STT), Secure Electronic Payments Protocol (SEPP), Internet Keyed Payments (iKP), Net Trust, and Cybercash Credit Payment Protocol. Such secure payment technologies require the customer to operate software that is compliant with the secure payment technology, interacting with third-party certification authorities, thereby allowing the customer to transmit encoded information to a merchant, some of which may be decoded by the merchant, and some which can be decoded only by a payment gateway specified by the customer. Another attempt to provide a secure transmission channel is a general-purpose secure communication protocol known as Secure Sockets Layer (SSL) developed by Netscape, Inc. SSL provides a means for secure transmission between two computers. SSL has the advantage that it does not require special -purpose software to be installed on the customer's computer because it is already incorporated into widely available software that many people utilize as their standard Internet access medium, and does not require that the customer interact with any third- party certification authority. Instead, the support for SSL may be incorporated into software already in use by the customer, e.g., the Netscape Navigator browser. However, although a computer on an SSL connection may initiate a second SSL connection to another computer, a drawback to the SSL approach is each SSL connection supports only a two-computer connection. Therefore, SSL does not provide a mechanism for transmitting encoded information to a merchant for retransmission to a payment gateway such that a subset of the information is readable to the payment gateway but not to the merchant. Although SSL allows for robustly secure two-party data transmission, it does not meet the ultimate need of the electronic commerce market for robustly secure three-party data transmission. Other examples of general- purpose secure communication protocols include Private Communications Technology (PCT) from Microsoft, Inc., Secure HyperText Transport Protocol (SHTTP) from Theresa Systems.

Intemet-based payment solutions require security measures that are not found in conventional point-of-sale (POS) terminals. This additional requirement is necessitated because Internet communication is done over publicly accessible, unsecured communication lines, which is in stark contrast to the private, secure, dedicated phone or leased line service utilized between a traditional merchant and an acquiring bank. Thus, it is critical that any solution utilizing the Internet for a communication backbone employ some form of cryptography.

Prepaid instruments in use today are a variant of one of (or combination of several of) the following devices: prepaid phone and access cards, debit cards, and money orders and gift certificates. Most Debit Cards are predicated on a credit system or linked to an existing bank account. Internet purchase schemes are predominantly credit systems. In addition, a number of on-line purchase schemes utilize an electronic wallet that is filled (i.e., funded) and refilled from a credit source. This is synonymous to certain toll-road systems that debit a credit account periodically to pay in advance for toll road use that is often electronically sensed. Internet purchasing schemes to date are all credit or bank account based due to the inability to collect cash over the wire.

In view of the foregoing, there remains a need in the art for systems for managing financial transactions over the Internet in an efficient and anonymous manner.

BRIEF SUMMARY OF THE INVENTION According to a preferred embodiment, a management system manages transactions on a network such as the Internet by utilizing a prepaid instrument having specific information, such as a monetary value and a security code. The prepaid instrument is purchased by a customer from a distributor. The prepaid instrument enables the customer to make on-line purchases of goods and services with complete anonymity and in a cash-like manner. In operation, the management system receives the information of the prepaid instrument from the distributor via the network. Upon receiving the information, the management system triggers a transfer funds from the distributor based upon the monetary value of the instrument. When the funds are received from the distributor, an account specific to the prepaid instrument is enabled. The customer then sends an activation request associated with the prepaid instrument to the management system, which request includes the security code. The management system then prompts the consumer for a user identification (ID) and a password. The management system then activates the account by associating the user ID and the password with the security code of the prepaid instrument. The customer is now able to make purchases over the network with the prepaid instrument. In the course of a transaction between the customer and a web merchant, the management system receives a redirected query from a merchant regarding a purchase associated with the prepaid instrument. The management system prompts the consumer for the user ID and the password associated with the prepaid instrument, and then determines whether the account associated with the prepaid instrument has sufficient funds to cover the purchase. A signal is transmitted to the merchant indicative of whether the account has sufficient funds to cover the purchase. If the transaction is completed, a signal is then sent back to the management system from the merchant indicating the same. The management system then debits the account and transferred funds to the merchant based upon the value of the purchase. The management system of the present invention has a number of advantages over conventional on-line payment approaches. For example, consumers who have not yet established a credit capability and/or need a limited spending capability, such as teenagers, are able to shop on-line essentially equivalent to shopping with cash. In addition, consumers who are concerned about releasing personal information required for credit card purchases benefit from the present invention in that transactions are anonymous. Further, in countries where credit cards are not widely used, the present invention provides a means for consumers to shop on-line.

Additional benefits of the invention are related to the advantages that cash provides in the physical world. For example, with the prepaid monetary instruments of the present invention, no credit card or bank account is required to be a consumer. In addition, the transactions maintain complete anonymity of the consumer. And unlike a conventional money orders, a monetary instrument of the present invention be used at multiple merchants. Further, in contrast to conventional credit/bank account systems, the management system of the present invention is efficient for all transactions, regardless of the magnitude (e.g., 100 and up).

Other aspects, features, and advantages of the present invention will become apparent to those skilled in the art from a consideration of the following detailed description taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary e-commerce system according to the present invention in which prepaid monetary instruments are utilized by a system for managing transactions between consumers and e-merchants;

FIG. 2 is a schematic representation of a prepaid monetary instrument configured according to a preferred embodiment of the invention; FIG. 3 is a flow chart illustrating exemplary methodology for managing anonymous transactions over a network with prepaid monetary instruments in accordance with the present invention;

FIG. 4 is a block diagram of an management system configured in accordance with an exemplary embodiment of the present invention;

FIGS. 5 A and 5B are a schematic representations of Internet activation browser windows exemplifying principles of the present invention; and

FIG. 6 is a schematic representation of an e-merchant verification browser window exemplifying principles of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Referring more particularly to the drawings, an exemplary embodiment of an e-commerce system according to the present invention is shown in FIG. 1 and is indicated generally by reference numeral 50. Exemplary e-commerce system 50 includes a management system 52 that is configured to allow anonymous transactions to take place between consumers 54 and merchants 56 over a network 58 such as the Internet. More specifically, through the use of prepaid monetary instruments purchased at one or more distributors 60, exemplary management system 52 enable consumers 54 to purchase goods and services from the merchants 56 with complete anonymity. In addition, exemplary management system 52 guarantees that the merchants 56 receive funds for goods and services provided without the drawbacks of conventional financial-transaction instruments such as credit cards. In a preferred embodiment, the management system 52 of the present invention provides cash-like and real-time transactions for purchases made on the Internet.

An example of a prepaid monetary instrument configured in accordance with the present invention is illustrated in FIG. 2 and is indicated by reference numeral 62. Exemplary instrument 62 includes information specific thereto, for example, a denomination or monetary value 64 and a security code 66 such as a serial number. In a preferred embodiment, exemplary instrument 62 may include one or more enablement means, such as a barcode 72 and/or a magnetic strip 74, which will be discussed in more detail below. Preferably, the instrument 62 of the present invention also includes an area 76 for graphics and text. Although any tangible form may be used, exemplary instrument 62 is preferably configured on a card-like body 78 for easy transport and familiarity. Exemplary instrument 62 may be preprinted or, alternatively, may have the monetary value 64 and the security code 66 printed at the time and place of the sale.

With further reference to FIG. 1, to place the principles of the invention in context, exemplary e-commerce system 50 generally includes a plurality of consumers 54a, 54b, 54c, ..., 54k each with access to a computer 80a, 80b, 80c, ..., 80/ connected to the network 58. Each consumer 54 has direct access to a plurality of distributors 60a, 60b, 60c, ..., 60m of the instruments 62 and network access via a respective computer 80 to the management system 52 and a plurality of participating web merchants 56a, 56b, 56c, ..., 56«. The network 58 may include in the Internet 81 and an instrument services network 82, which is discussed in more detail below.

With additional reference to FIG. 3, each consumer 54 purchases the instrument 62 from any one of the distributors 60 (step 83). The plurality of distributors 60 may include retail establishments, convenience stores, department stores, post offices, dedicated kiosks, and so on. In addition, the plurality of distributors 60 may include unattended devices, such as vending machines. The distributor 60 making the sale of the instrument 62 receives funds (step 84) from the consumer 54 in the amount of a desired monetary value 64. An additional service charge may be added in the sale of the instrument 62.

The distributor 60 then enables the instrument 62 (step 86), which may be accomplished in any number of ways. For example, the barcode 72 may be optically scanned, or the magnetic strip 74 may be swiped through a reader such as a standard Verafone^® interface. By enabling the instrument 62, the information specific thereto, i.e., the monetary value 64 and the security code 66, is transmitted via the network 58 to the management system 52 (step 88). The enablement of the instrument 62 preferably takes place across the instrument services network 82 of the system network 58.

Referencing FIG. 4, the information transmitted by the distributor 60 is received by the management system 52 (step 90) at an instrument services gateway 92 which, in turn, sends the information to an enablement processor 94 which triggers an electronic transfer of funds (step 96). The distributor 60 electronically transfers funds (step 98) to the management system 52, and an enabled account is established (step 100) for the instrument 62 via an enablement application program interface (API) 102. Enablement of an instrument 62 changes an account specific to the instrument from a pending status to an enabled status. Data associated with instruments 62 with accounts having an enabled status (i.e., enabled accounts) may be stored on an instruments data structure 104, and data associated with the transfer of funds from the distributors 60 may be stored on a distributor data structure 106. In alternative embodiments, the distributor 60 may provide the monetary value 64 of the instrument 62, and the management system 52 may confirm the enablement of the instrument 62 with the distributor 60 and verify the monetary value 64. A consumer 54 with an enabled instrument 62 then needs to activate the instrument 62 (step 108). To do so, the consumer 54 accesses an activation website (step 110) with a computer 80. The activation website may be part of a general customer website 112 maintained by the management system 52. Alternatively, the activation website may be a frame within a website of a distributor. Referencing FIG. 5A, a first activation window 114 is displayed on the consumer's computer 80 which prompts the consumer 54 for the security code 66 of the instrument 62 (step 116). The first activation window 114 may include fields for this information, as indicated by reference numeral 118. The consumer 54 may then activate a SUBMIT icon 120 to provide the security code 66 to the management system 52 (step 122).

Upon receipt of the security code 66, the management system 52 causes a second activation window 124 as shown in FIG. 5B to be displayed on the consumer's computer 80 which prompts the consumer 54 for a user ID and a password (step 125). The second activation window 124 may include fields for this information, as indicated by reference numerals 126 and 127, respectively. In a preferred embodiment, the second activation window 124 also includes fields for prompting the consumer for a challenge phrase and a challenge response, as indicated by reference numerals 128 and 129, respectively, which will be discussed in more detail below. Upon entering the requested information, the consumer 54 may then activate a SUBMIT icon 130 to provide the user ID and the password to the management system 52 (step 131).

The management system 52 receives the user ID and the password by an account activator 132, as shown in FIG. 4. Through an activation API 134, the enabled account associated with the instrument 62 is activated (step 136); that is, the enabled status of the account is changed to an active status. Data associated with the activated account of the instrument 62 may be stored on an active accounts data structure 138. With the account associated with an instrument 62 activated, a consumer 54 is free to shop on-line at any merchant with a website connected to the network 58 and set up to accept payment with the instrument 62 of the present invention. To do so, the consumer 54 accesses a merchant website (step 140) to shop for goods and services. When the consumer 54 has decided upon a desired selection of goods and/or services, a purchase is initiated (step 142) from the merchant's website. When a purchase is initiated, the merchant 56 preferably redirects the consumer 54 to the management system 52 (step 143). A secure handshake between the customer 54 and the management system 52 may be established.

Referencing FIG. 6, when the purchase is initiated, a verification window 144 may be displayed on the consumer's computer 80 which prompts the consumer 54 for the user ID and the password (step 146). The verification window 144 may include fields for this information, as indicated by reference numerals 148 and 149, respectively. In alternative embodiments, for example, if a secure handshake is not established, the verification window 144 may also include a field for prompting the consumer for the challenge phrase and the challenge response, similar to that shown in FIG. 5B. This is particularly useful as added security if a prepaid instrument 62 is lost or stolen, or if the consumer is utilizing a computer 80 other than that used to activate the account associated with the prepaid instrument. The consumer 54 may then activate a SUBMIT icon 152 to provide the user ID and the password to the management system 52 (step 154).

Upon receiving the user ID and the password, the management system 52 generates and transmits a query to a transaction engine 160. Upon receipt of the query , the transaction engine 160 validates the user ID and the password and correlates this information with active account information in the active account data structure 138 through a prepaid transaction API 164. The funds in the account are then verified (step 166). A funds signal is generated and transmit (step 168) to the merchant 56. The funds signal contains information indicative of whether or not sufficient funds are in the account to cover the purchase.

Upon receipt of the funds signal (step 170), the merchant 56 proceeds with the transaction if sufficient funds are available (step 172). If sufficient funds are not available, the management system 52 may query the customer 54 for alternative or addition payment options, such as a credit card to cover the deficit. The merchant 56 then transmits a verification (step 174) to the customer 54 that the transaction has taken place. Upon receipt of the verification (step 176), the customer 54 may continue shopping with the instrument 62 if funds remain in the account (step 178).

Upon completing the transaction, the merchant 56 may send a purchase signal (step 180) to the management system 52 which, upon receipt (step 182), debits the account (step 184) of the instrument 62 associated with the transaction. The management system 52 may then transfer funds (step 186) to the merchant which, upon their receipt (step 188), completes the anonymous transaction between the customer 54 and the merchant 56. The amount of funds transferred to the merchant 56 is based upon the purchase price and may be reduced by a service charge of the management system. Alternatively, the management system 52 may debit the account of the prepaid instrument 62 prior to transmitting the funds signal in step 168.

One of the advantages of the management system 52 of the present invention is that purchases made by a customer may be batched or pre-authorized. According to this feature of the invention, a merchant 56 batches multiple purchases made during a single on-line session with a consumer 54. To do so, an advance is established by completing a secure handshake between the merchant 56 and the management system 52 and between the merchant 56 and the consumer 54. When the shopping session is complete, the total amount is communicated to the management system 52 and the consumer 54 to finalize the transaction. This embodiment is particularly useful for merchants who specialize as content or information providers. Such merchants require micropayments for various informational units. Micropayments are small payments that are not suitable for credit-based purchase schemes, examples of which include

$0.25 for a download of a piece of intellectual property and $1.50 for two viewing/use rights for an on-line service such as financial information from a financial website.

In a preferred embodiment, exemplary management system 52 is configured to allow the combining of the accounts of multiple instruments into a single account. For example, if a single consumer 54 has purchased several instruments and has used these instruments such that a small balance remains in the account of each, then the consumer 54 may combine these multiple accounts into a single account that can be used analogously to a new account. In other words, Account 1 through Account x may be combined into Account +1. Accounts 1 through x would then be empty and marked idle. This account combination feature of the management system 52 may be carried out by a customer query handler 190 and an account services API 192. A data structure 194 dedicated to quiet and closed accounts may be provided to house data associated with the accounts comprising the combined account. In addition to combining accounts, customer query handler 190 may be configured to enable a consumer to move or transfer funds from one account to another.

Conversely to the combination of accounts, the management system 52 of the present invention may be configured to allow the parsing or splitting of one account into several accounts. Parsing provides an effective way to disperse of a remaining balance in an account, and may be carried out by the customer query handler 190.

The management system 52 of the present invention may also include a data structure 196 for housing data relevant to each of the merchants 56 of the network 50. In doing so, the management system 52 may organize the merchant 56 into categories according to, for example, the type of goods or services being sold, the target consumer (e.g., teens, adult only, etc.), and the type of offerings (e.g., information, soft services, or hard goods). By classifying the merchants 56 in an object class library structure, the process of adding and grouping new merchants 56 is greatly simplified. This classification enables the creation of prepaid monetary instruments 62 that are valid only at certain specifiable classes of merchants 56.

For example, one of the most useful such class of merchants 56 would be suitable for preteens and teens. Accordingly, a "card for minors" may be enabled that is restricted to merchants 56 that have been so categorized. As new merchants 56 come on-line and meet the qualifications, they may be added to this category of merchants and available to the "cards for minors," as well as to all newly issued cards.

This categorization of merchants 56 is preferably monitored and maintained current. If an existing participating merchant changes its offerings goods and/or services in such a way that it would change its categorization, then such a change may be detected and updated for existing accounts, as well as new accounts. This monitoring and updating may be accomplished by the combination of the object class library classification and an automated "web crawling" of each merchant 56. This form of electronic inspection may be performed periodically (e.g., daily) against all participating merchants 56. The activated instruments 62 may then be enabled or disabled according to the current classes of merchants 56.

With further reference to FIG. 4, exemplary management system 52 may also provide a website 198 for access by the merchant 56 of the system 50. A merchant query handler 200 and a merchant SNC 202 in communication with the merchant data structure 196 may be configured to handle queries from merchants 56 as to status of there respective accounts with the system. The accounts of the management system 52 may be classified according to status. For example, accounts may be allocated by the security codes or a block of security codes to a particular distributor 60. The allocation of accounts within the management system 52 allows a distributor 60 to design and manufacture unique instruments 62. A pending account indicates an account that is on-line in the system 52 and awaiting enablement. An enabled account, as discussed above, indicates that the account has been purchased and enabled and is awaiting activation. An activated account, also as discussed above, indicates that the account has been activated by the consumer 54 on the customer website 112. An account may acquire a quiet status if the account balance goes to zero (or effective zero) and/or has seen not activity for a predetermined amount of time, for example, three months. In addition, an account may acquire a complete status if the account has been quiet for an extended predetermined amount of time, for example, at least 24 months with a balance or six months with no effective balance. The active accounts data structure 138 and the quiet/closed accounts data structure 194 may include data related to each of these accounts.

According to transaction-management methodology of the present invention, the enablement processor 94 processing a signal from a distributor 60 received via the network 58. The signal from the distributor 60 includes the information, i.e., the monetary value 64 and the security code 66, of the prepaid instrument 62. The enablement processor 94 then causes an account associated with the prepaid instrument to be enabled based upon the information. The account activator 132 then receives a signal from a customer 54 via the network 58. The signal from the customer 54 includes at least the security code, the user ID, and the password. The account activator 132 then causes the enabled account associated with the security code to be activated in association with the user ID and the password. The transaction engine 160 then processes a signal from including information regarding a purchase and a password. The transaction engine 160 causes a verification of funds in the active account associated with the received user ID and password and causes a signal to be generated and transmitted to the merchant 56 as to whether the account associated with the password has sufficient funds to cover the purchase. The transaction engine 160 then receives and processes a second signal from the merchant 56, with the second signal including information indicative of whether the purchase took place. The transaction engine 160 causes funds to be transferred to the merchant 56 based upon a value of the purchase.

The foregoing methodology may be implemented in software modules including a plurality of code segments. For example, the software may include code segments for processing the signal from the distributor and for enabling the account associated with the prepaid instrument 62 in the enablement processor 94. Other code segments may be configured to activate the account and associate the account with a user ID and a password received by the account activator 132. Additional code segments may be configured for processing the signal from the merchant 56 to the transaction engine 160, including code segments for prompting the consumer for the user ID and the password associated with the instrument, for verifying sufficient funds, for generating the signal, and for causing the signal to be transmitted to the merchant as to the same. The software may also include other code segments for processing the second signal from the merchant 56 and for causing funds to be transferred to the merchant based upon a value of the purchase. Those skilled in the art will understand that the present invention is not limited to the embodiments specifically illustrated in the drawings and described above. Rather, those skilled in the art will realize that the specific elements of the present invention may be modified and are capable of numerous alternatives without departing from the scope and spirit of the present invention. Accordingly, the scope of the present invention is determined by the terms of the appended claims and their legal equivalents and not by the specific exemplary embodiments shown and described herein.

Claims

CLAIMSWhat is claimed is:

1. A method for managing transactions on a network with a prepaid instrument having specific information including a monetary value and a security code, the prepaid instrument being sold by a distributor, the method comprising: a) receiving the information of the prepaid instrument from the distributor via the network; b) triggering a transfer of funds from the distributor; c) receiving funds from the distributor based upon the monetary value via the network; d) enabling an account specific to the prepaid instrument; e) receiving an activation request associated with the prepaid instrument, the activation request including the security code; f) receiving a user identification (ID) and a password associated with the prepaid instrument; g) activating the account by associating the user ID and the password with the security code of the prepaid instrument; h) receiving a query via the network regarding a purchase associated with the prepaid instrument and a merchant; i) determining whether the account specific to the prepaid instrument has sufficient funds to cover the purchase; j) transmitting a signal to the merchant via the network indicative of whether the account has sufficient funds to cover the purchase; k) updating the account of the prepaid instrument based upon the transferred funds; and 1) transferring funds to the merchant based upon a value of the purchase.

2. The method as claimed in claim 1 wherein steps (h) through (1) are repeated until the account of the prepaid instrument is depleted of funds.

3. The method as claimed in claim 1 wherein the network is the Internet.

4. The method as claimed in claim 1 wherein step (c) comprises: receiving funds from the distributor equal to the monetary value less a service charge.

5. The method as claimed in claim 1 wherein step (1) comprises: transferring funds to the merchant equal to a value of the purchase less a transaction fee.

6. A method for managing transactions on a network with a prepaid instrument having specific information including a monetary value and a security code, the prepaid instrument being sold by a distributor, the method comprising: a) enabling an account specific to the prepaid instrument; b) activating the account based on a user ID and a password; c) receiving a query via the network regarding a purchase associated with the account and a merchant based only on the user ID and the password; d) providing the merchant verification as to whether the account has sufficient funds to cover the purchase; e) receiving a signal from the merchant via the network that the purchase has taken place; f) debiting the account of the prepaid instrument based upon the transferred funds; and g) transferring funds to the merchant based upon a value of the purchase.

7. The method as claimed in claim 6 wherein step (a) comprises: receiving the information of the prepaid instrument from the distributor via the network; triggering a transfer of funds from the distributor; receiving funds from the distributor based upon the monetary value via the network; and establishing an account specific to the prepaid instrument.

8. The method as claimed in claim 6 wherein step (b) comprises: receiving an activation request associated with the prepaid instrument, the activation request including the security code; receiving a user ID and a password; and associating the user ID and the password with the security code of the prepaid instrument.

9. The method as claimed in claim 6 wherein step (d) comprises: determining whether the account specific to the prepaid instrument has sufficient funds to cover the purchase; and transmitting a signal to the merchant via the network indicative of whether the account has sufficient funds to cover the purchase.

10. A method for managing transactions on a network with a prepaid instrument having specific information including a monetary value and a security code, the prepaid instrument being sold by a distributor, the method comprising: a) establishing an account associated with the prepaid instrument, the account including funds transferred from the distributor based upon the monetary value of the prepaid instrument, the account being associated with a consumer; b) managing a transaction between a merchant and the user via the network such that the user remains anonymous to the merchant; and c) transferring funds from the account to the merchant based upon a value of the transaction.

11. A method for anonymously making purchases over a network, the method comprising: a) purchasing a prepaid instrument at a distributor, the prepaid instrument including a monetary value and a security code; b) activating the prepaid instrument via the network by causing an account to be established, the account being associated with the prepaid instrument and a password, the account including funds transferred from the distributor based upon the monetary value of the prepaid instrument; c) initiating a transaction with a merchant via the network by providing the password such that information associated with the account remains anonymous to the merchant; and d) causing funds to be transferred from the account to the merchant based upon a value of the transaction.

12. A method for anonymously making purchases over a network, the method comprising: a) purchasing a prepaid instrument at a distributor, the prepaid instrument including a monetary value and a security code; b) activating the prepaid instrument via the network by causing an account to be established, the account being associated with the prepaid instrument and a password, the account including funds transferred from the distributor based upon the monetary value of the prepaid instrument; c) initiating a transaction with a merchant via the network by providing the password such that information associated with the account remains anonymous to the merchant; and d) causing funds to be transferred from the account to the merchant based upon a value of the transaction.

13. A method for managing transactions on a network with a prepaid instrument having specific information including a monetary value and a security code, the prepaid instrument being sold by a distributor, the method comprising: a) processing a signal from the distributor received via the network, the signal from the distributor including the information of the prepaid instrument, the processing of the signal from the distributor causing an account associated with the prepaid instrument to be established based upon the information; b) processing a signal from a merchant received via the network, the signal from the merchant including information regarding a purchase associated with the prepaid instrument, the processing of the signal from the merchant causing a signal to be generated and transmitted to the merchant as to whether the account of the prepaid instrument has sufficient funds to cover the purchase; c) processing a second signal from the merchant received via the network, the second signal from the merchant including information indicative of whether the purchase took place, the processing of the second signal from the merchant causing funds to be transferred to the merchant based upon a value of the purchase.

14. Apparatus for managing transactions on a network carried out with a prepaid instrument having specific information including a monetary value and a security code, the prepaid instrument being enabled by a distributor, the method comprising: a) means for processing a signal from the distributor via the network, the signal from the distributor including the information of the prepaid instrument, the means for processing of the signal from the distributor causing an account associated with the prepaid instrument to be established based upon the information; b) means for processing a signal from a merchant received via the network, the signal from the merchant including information regarding a purchase associated with the prepaid instrument, the means for processing of the signal from the merchant causing a signal to be generated and transmitted to the merchant as to whether the account of the prepaid instrument has sufficient funds to cover the purchase; c) means for processing a second signal from the merchant received via the network, the second signal from the merchant including information indicative of whether the purchase took place, the means for processing of the second signal from the merchant causing funds to be transferred to the merchant based upon a value of the purchase.

15. A computer program embodied on a computer-readable medium for managing transactions on a network carried out with a prepaid instrument having specific information including a monetary value and a security code, the prepaid instrument being sold by a distributor, the method comprising: a) a code segment for processing a signal from the distributor via the network, the signal from the distributor including the information of the prepaid instrument, b) a code segment for establishing an account associated with the prepaid instrument to be established based upon the information; c) a code segment for processing a signal from a merchant received via the network, the signal from the merchant including information regarding a purchase associated with the prepaid instrument; d) a code segment for generating a signal and for causing the signal to be transmitted to the merchant as to whether the account of the prepaid instrument has sufficient funds to cover the purchase; e) a code segment for processing a second signal from the merchant received via the network, the second signal from the merchant including information indicative of whether the purchase took place; and f) a code segment for causing funds to be transferred to the merchant based upon a value of the purchase.