Method for customizing payment card transactions at the time of the transactions

Abstract

A user can customize use of a payment card, which can be an electronic card, by selecting a customization variable for any given transaction. The customization variable involves at least one of the following steps: (1) customizing generation of a one-time card number; (2) customizing a user identifier; or (3) inclusion of a customization variable with information transmitted to a verification agency for validation of the given use. Multiple payment card transactions can be processed differently depending upon which customization variable is chosen for a given transaction. Different customization variables can be used for different accounts, different types of transactions, or to classify the transactions. A user can receive one bill, or multiple bills. Different levels of privacy can be accorded to transactions that use different customization variables. A user may pay the issuer for increased security, or the user may be paid by the issuer to allow transaction data to be distributed to third parties.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation application of U.S. patent application Ser. No. 09/960,714, filed Sep. 21, 2001, which was a continuation-in-part application of U.S. application Ser. Nos. 09/667,081 and 09/667,089, filed Sep. 21, 2000, which are continuation-in-part applications of U.S. Ser. No. 09/659,434, filed Sep. 8, 2000, which is a continuation-in-part of U.S. Ser. No. 09/640,044, filed Aug. 15, 2000, which is a continuation-in-part of U.S. Ser. No. 09/619,859, filed Jul. 20, 2000, which is a continuation-in-part of U.S. Pat. No. 6,592,044, all of which disclosures are specifically incorporated herein by reference. The present application is also related to U.S. patent application Ser. Nos. 09/667,835, 09/667,089, and 09/667,082, all of which were filed on Sep. 21, 2000, and all of which are specifically incorporated herein by reference. The present application continues the subject matter previously set forth in U.S. Ser. No. 09/667,038.

FIELD OF THE INVENTION

The present invention is in the field of methods for making payments through payment cards.

BACKGROUND OF THE INVENTION

Three forms of money in widespread use today throughout the world are cash, checks and payment cards (debit or credit). Each has distinct advantages, and distinct disadvantages. Cash is readily accepted, easy to use and anonymous, but it does not earn interest, it can be lost or stolen, and it is not always readily accessible. Checks are not always accepted, but they offer many advantages, since they do not have to be written until the time of payment. However, they must be physically presented and they are not anonymous. Payment cards are readily, but not always, accepted, and they offer many advantages over checks. If the card is a credit card, payment can be deferred, but the transaction is not anonymous. If the card is a debit card, payment has usually been made prior to its use, but it is anonymous. Accordingly, it is apparent that different types of money have different advantages to different persons in different situations. This may be one reason why all these forms of money are still in widespread use, and are even used by the same persons at different times.

As society and international commerce have become more dependent upon electronic transactions, money has also become more electronic. Many attempts have been made to come up with suitable forms of electronic money that mimic the physical world, or even create new forms of electronic money. However, despite the enormous need for such money, and efforts by some of the best minds and most successful companies in the world, electronic money has suffered many setbacks and been far slower to materialize than many had hoped or predicted. The reasons are many and varied, but some of the obvious reasons are security, ease of use/operation, and unwillingness of the public and/or commerce to make radical changes or embrace new technology and/or procedures. As a result, many efforts, including several potentially promising efforts, have met with failure.

Even though new forms of electronic money have been slow to develop or gain widespread acceptance, electronic payments have still moved forward. Many banks now offer some form of electronic checking. And payment cards have been used for electronic transactions in e-commerce and m-commerce (mobile commerce). Still, there is widespread concern about the safety of such transactions, and recent news stories have uncovered widespread fraudulent activity associated with use of traditional credit card numbers in e-commerce over the Internet. In addition, there is growing concern about consumer privacy, or lack thereof, due to widespread electronic profiling of consumers who make electronic payments.

Although the media has been quick to cover fraud associated with use of credit cards over the Internet, it is often overlooked, at least by the public and the media (but not the credit card companies), that the majority of fraudulent activity concerning credit cards is not associated with e-commerce activity. Most fraud occurs in the “brick and mortar” world, and the numbers are daunting. Despite many attempts to combat unauthorized or fraudulent use of credit cards, it is estimated that credit card fraud now exceeds hundreds of millions, if not several billion, dollars per year. And this does not even count the cost of inconvenience to consumers, merchants and credit card issuer/providers, or the emotional distress caused to victims of such fraud, or the cost to society in terms of law enforcement and preventative activities.

Accordingly, there is a very real, long-felt need to reduce the amount of fraudulent activity that is associated with credit cards, and this need has only grown more acute as consumers and commerce search for better ways to purchase and sell goods and services via e-commerce and m-commerce. However, any solution needs to be something that is acceptable to the public at large. It should be easy to use. It should not be complicated or expensive to implement. Preferably, it should fit within the existing infrastructure, and not be something that requires a great deal of educational effort, or a radical change in behavior or habits of consumers. In other words, it should be user friendly, readily understandable and something that does not require a completely new infrastructure, which is a reason suggested by some as to why smart cards have not been widely accepted in the United States.

In addition, it is highly desirable that any solution to such problems be capable of widespread use, in many different platforms, for many different applications.

In U.S. Pat. No. 5,956,699 issued in September of 1999, Wong and Anderson were the first to introduce the methodology of a system for secure and anonymous credit card transactions on the Internet. This patent introduced a system which used an algorithm to use one's own selected Personal Identification Number or PIN as one's own de facto digital signature. The algorithm instructs the cardholder how to insert one's PIN into one's valid credit card number before using it for any transactions on the Internet. The resultant scrambled up credit card number, which is tailored by the algorithm to having the same number of digits as before, is rendered useless on the Internet because the PIN insertion algorithm is changed automatically after every transaction. This methodology is not only capable of drastically reducing credit card fraud on the Internet, it is also capable of safeguarding one's anonymity, and thus privacy, in credit card purchases on the Internet.

Since the issuance of U.S. Pat. No. 5,956,699, Wong and Anderson have also invented an anonymous electronic card for generating personal Coupons useful in commercial and security transactions, as well as a method for implementing anonymous credit card transactions using a fictitious account name. The present invention is an extension of these prior inventions that seeks to provide new methods for allowing a user to customize the use of one-time unique numbers that can be used in credit card transactions in the brick and mortar world, e-commerce, m-commerce and in many other applications. Because the methodology is well suited for use in hardware and software applications, it has widespread applicability to many different types of transactions. In addition, the present invention allows a user to categorize individual transactions. This new advantage can be used to simplify accounting procedures and consolidate multiple accounts in a single payment credit card. It also opens up many previously unknown possibilities, such as allowing a user to sell data, or protect data, relating to a given transaction.

SUMMARY OF THE INVENTION

The present invention is generally directed to a method for customizing payment card transactions by allowing a user of a payment card to select a customization variable for any given transaction involving use of the payment card. The customization variable is submitted with the payment card number and a user identifier to a verification agency for validation. The customization variable may be used in a method for processing a plurality of payment card transactions based upon the user's selection of various customization variables. The present invention is particularly well suited for use with electronic cards, but it can also be used in any method that uses a card number generator to generate a one-time card number.

In a first, separate aspect of the present invention, the customization variable may involve customization of the generation of a one-time payment card number. An example of one way in which this can be done is to allow the user to choose either a first or a second user key as the key that will be used by an algorithm of a card number generator to generate the one-time payment card number. The customization variable may also involve customization of a user identifier associated with the one-time payment card number. An example of one way in which this can be done is to allow the user to choose either a first or a second identifier. The customization variable may also involve inclusion of a customization variable with the one-time payment card number and the user identifier when they are submitted to the verification agency for validation.

In another, separate aspect of the present invention, an electronic card with a magnetic storage medium and an encoder is used, and the card is sized such that a standard magnetic stripe reader can read the magnetic storage medium. It is especially preferred that the magnetic storage medium be a magnetic stripe. The encoder can store the one-time payment card number, the user identifier or the customization variable on the magnetic stripe, including its second track.

In still another, separate aspect of the present invention, a plurality of handling options provide numerous options for processing payment card transactions. The handling options can include billing two separate accounts. The user can be sent a single bill for charges to the two separate accounts, even if the accounts are established with different entities, such as different credit card companies or banks, or the user can be sent a first bill for the first account and a separate bill for a second account. One of the accounts can be a credit account and another account can be a debit account.

In yet another, separate aspect of the present invention, the plurality of handling options can provide a mechanism for classifying the nature of the payment card transactions, such as using a first handling option for business transactions and a second handling option for personal transactions. They can also provide different mechanisms for controlling access to information concerning payment card transactions. One mechanism can be used to implement restrictions on distribution of information relating to payment card transactions or restrictions on distribution of personal information of the user to second entities. The user can be charged consideration for use of this mechanism. Another mechanism can be used to permit distribution of information relating to payment card transactions to third parties or permit distribution of personal information of the user to second entities. The user can be given consideration to use this mechanism.

Accordingly, it is a primary object of the present invention to provide a method for allowing a user to customize a given use of a payment card.

This and further objects and advantages will be apparent to those skilled in the art in connection with the detailed description of the preferred embodiments set forth below.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention is related to U.S. Pat. Nos. 5,913,203, 5,937,394 and 5,956,699, the disclosures of which are all specifically incorporated herein by reference.

The preferred embodiments of the present invention provide an unprecedented opportunity to customize use and processing of payment card transactions through use of one or more customization variables.

In the context of this description, a one-time payment card number refers to a payment card number of either a credit or a debit card, generated in accordance with the present invention, that is useful in financial transactions in the same fashion as a traditional payment card number.

Like a traditional payment card number, a one-time payment card number should be capable of being read by a standard magnetic stripe reader when it is part of a physical card used in traditional face-to-face transactions in which a user presents the physical card to a merchant for payment. However, like traditional payment card numbers, a one-time payment card number should also be capable of being used in a Mail Order Telephone Order (“MOTO”) credit card transaction between the user and a merchant. Thus, like a traditional payment card number, the one-time payment card number should fit within, and work with, present platforms and protocols for financial transactions involving payment cards, such as traditional credit cards. This versatility allows the one-time payment card number to be used with electronic cards, software programs used in network applications, or telephones (especially telephones used in what is now being referred to as m-commerce, or mobile commerce).

A traditional payment card number can be characterized as having three parts. First, there is a set of fixed variables. This contains numerals that represent certain specified data fields, such as a bank identifier and a month and year expiration date for a given payment card. (The “bank” may be any “money source” as that term has been defined in U.S. Pat. No. 5,937,394.) Second, there is a set of variable variables. This contains numerals that will vary for different payment cards issued by the same money source. In other words, this is the portion of the card number that will be specific to an individual entity or account for a given issuing money source. Third, there is a check sum digit. The value of the check sum digit is dictated by the other numerals in the card number.

In the context of the present invention, a user one-time payment card number is akin to a traditional payment card number, with certain exceptions. In a traditional payment card number, there might be a set of six fixed variables, followed by a set of nine variable variables, followed by a check sum digit and another set of four fixed variables representing the month and year. When a user uses this traditional payment card number to complete a given financial transaction, the transaction is always completed by using the same twenty digits for the payment card number. By contrast, if the user uses a one-time payment card number to complete any such given financial transaction, the transaction will not be completed by always using the same twenty digits for the payment card number. Instead, the twenty digits of the one-time payment card number will vary, and the degree to which they vary may depend upon user selection of a customization parameter. In addition, because the one-time payment card number varies with successive usage, the check sum digit will not necessarily be the same with successive usage, although it may be. Thus, the check sum digit must be recalculated for each new one-time payment card number, and this is why it shall be referred to as a “check sum variable” in the context of a one-time payment card number according to the present invention.

Another difference between a traditional payment card number and a one-time payment card number is the way that a given transaction using either number is validated by a verification agency, which may be a money source or an entity who processes payment card transactions. When a transaction involving a one-time payment card number is processed, the verification agency must verify that the one-time payment card number is valid for the user identifier for the particular given transaction, as opposed to any given transaction involving the user identifier. (The verification process must take into account how selection of the customization parameter may affect what the verification agency will receive for verification. Additional details regarding procedures that can be used to verify a one-time card number that can be customized are set forth in U.S. Pat. No. 6,609,654.) This difference is a reason why use of the one-time payment card number provides greater security and anonymity than can be obtained through use of a traditional payment card.

A card number generator generates a one-time payment card number. As already described, this could be hardware or software, but, in either case, it will preferably include a customer random number generator and a customer sequence number. It is especially preferred that the card number generator be part of an electronic card, and that the electronic card be of the type described in U.S. application Ser. No. 09/571,707 filed May 15, 2000 for Anonymous Electronic Card for Generating Personal Coupons Useful in Commercial and Security Transactions, or in U.S. application Ser. No. 09/667,835.

Several different methods that can be used to generate a one-time payment card number are described in detail in the applications that are identified in the Cross Reference to Related Applications above, and which are incorporated herein by reference, so the details of those methods will not be repeated here. No matter what method is used to generate a one-time payment card number, two successive one-time payment card numbers should be different. This can be accomplished by using a sequence number that is changed after each one-time payment card number is generated. (The present invention does not require that all theoretical possibilities will result in different one-time payment card numbers. Instead, it is preferred that there be a low probability of occurrence of identical one-time payment card numbers attributable to convergence of two different inputs leading to the same result due to operations performed on the inputs by the algorithm.)

The preferred embodiments allow a user to customize use of an electronic card having a card number that varies with each use by selecting at least one customization parameter to customize a given use of the electronic card. There are three general customization parameters that can be used to customize a given use.

First, the user can customize generation of the one-time card number. This can be done many different ways. An example of one way in which it can be done is to customize selection of a selected user key that is used to generate the one-time card number as is explained in U.S. Pat. No. 6,609,654. Another way in which it can be done is to include a customization variable in the one-time card number, or as an input into the algorithm used to generate the one-time card number.

Second, the user can customize the user identifier that is used to validate the one-time card number. This can be done many different ways. One way is to choose one of two or more preselected identifiers as a selected user identifier. Another way is to modify the user identifier. Still another way is to add a customization variable, such as a numeric character, to the user identifier at a preselected location.

Third, the user can include a customization variable with information transmitted to a verification agency for validation of the given use. Unlike the first two customization parameters, this parameter relies upon use of an additional field of data collected as part of the validation process for a given transaction, and this may require a change in established validation protocols. It is especially preferred that any such change be technically feasible within the confines of hardware that is being used to process traditional payment card transactions. In the context of an electronic card with a magnetic stripe, this means that it is preferred that the additional customization variable be stored in the magnetic stripe, and it is especially preferred that it be stored in the second track of the magnetic stripe. Additional details regarding inclusion of a customization variable in a magnetic stripe are set forth in U.S. Ser. No. 09/667,089.

Once it is recognized that using one or more of the foregoing customization parameters will customize a given transaction involving use of a one-time payment card number, and that such customization will seamlessly allow a user to transmit additional information to the money source processing such transaction, without loss of desired security or anonymity, the options for using such customization are virtually limitless.

After a one-time payment card number is validated for a given transaction, the money source can determine what customization parameter(s) was selected by the user for the given transaction, which allows the money source to determine what handling option should be used for the transaction involving the one-time payment card number. (It also allows the money source to determine what sequence number is associated with the one-time payment card number, so that its records can be synchronized as part of the validation process.)

One use of multiple handling options is to allow the money source to access multiple accounts. For example, a user might use one account as a credit card, and another account as a debit or checking card. By choosing which account should be used for a given transaction, the user could determine, at the point of use, whether to charge the transaction, or have it deducted from an existing account balance. The same idea could be used for multiple credit cards, whether they are from the same issuer or different issuers, or even different cards, such as Visa®, MasterCard®, Diner's Card®), Discover® or American Express®. In addition, the user might elect to have separate billing statements for separate accounts, or have all billing consolidated in a single statement.

Another use of multiple handling options is to allow identification of the person completing a transaction, or to allow multiple persons access to a single account, or place different restrictions on multiple persons on a single account. For example, a single account might be opened with an issuing bank, but an entire family might be authorized to use the account. Thus, a father and a mother might have their own customization parameter, a teenage child might have another customization parameter and a lower authorized spending limit, and a preteen child might have a fourth customization parameter, but only be authorized to engage in a certain limited number of transactions per time period with a maximum spending limit for each transaction. All the members of this family could use the same card number generator embedded within a PDA or mobile phone, or on a computer or in an electronic card. At the end of a specified billing cycle, all transactions completed by any member of this family could be consolidated in a single bill, and that bill could indicate who spent what when during the billing cycle, and what it was spent on.

Still another use of multiple handling options is to allow a user to classify the nature of a particular transaction at the time it is completed. For example, suppose an individual uses a single credit card for personal expenditures and business expenditures. By assigning one customization parameter to personal transactions, and a second customization parameter to business transactions, the user can simplify accounting for such transactions without the necessity of having and carrying two separate cards. If desired, the user could even receive two separate statements for such expenditures so that the personal expenditures would not be discernable from the documentation associated with the business expenditures. Individual transactions could also be classified according to a preselected set of criteria, and such criteria could be used in various financial programs. For example, a user might include a code classification system used in a money management system to create various reports that itemize categories of spending or assist in budgeting of finances.

Yet another use of multiple handling options is to allow a user to preselect how a particular transaction is treated in a subsequent bill. For example, an individual user might not want a billing statement to include information about the identity of second entities who provide certain goods or services, or when transactions with such entities take place, but still want to have the billing statement include such information for other transactions. By selecting two different customization parameters with these two different handling options, the user has the option of controlling what information it receives in billing statements about individual transactions.

Multiple handling options can also be used to guard privacy, or for commercial purposes that do not presently exist. For example, the user and the money source might enter into an agreement about how, and under what circumstances, the money source can distribute information about transactions of the user, depending upon which customization parameter is used in a given transaction. The agreement might provide different levels of confidentiality, and set up different levels or types of compensation tied to transactions falling within the different levels for a given time period.

One level of confidentiality might restrict distribution of any information concerning a transaction by the money source to any third party. For example, a user might want strict confidentiality of any transaction involving medical services, and would not want the money source to divulge that information to any party unless legally required to do so. Or, maybe the user does not want any third party to learn of any transaction that exceeds a certain dollar amount, for fear of a potential deluge of unsolicited advertising. A user might pay a monthly fee for use of this option, a transaction based fee, or no fee at all.

A second level of confidentiality might permit distribution of any information concerning a transaction by the money source to any third party. Such information is potentially valuable for purposes of advertising, and creating profiles for targeted marketing, and the money source might even pay the user for the right to sell such information.

Other levels of confidentiality might fall between those already noted. For example, a third level might permit distribution of certain information concerning a transaction (such as the payee, the amount of purchase, the date of purchase, and a profile of the user), but restrict distribution of other information concerning a transaction (such as the identity of the user). Another level of confidentiality might restrict distribution of information concerning a transaction to any third party, but allow the money source to use such information for its own marketing efforts directed to the user.

Although the foregoing detailed description is illustrative of preferred embodiments of the present invention, it is to be understood that additional embodiments thereof will be obvious to those skilled in the art. Further modifications are also possible in alternative embodiments without departing from the inventive concept.

Accordingly, it will be readily apparent to those skilled in the art that still further changes and modifications in the actual concepts described herein can readily be made without departing from the spirit and scope of the disclosed inventions as defined by the following claims.

Claims

1. A method for allowing customized use of an electronic card having a card number that varies with each use, comprising the steps of:

(1) allowing a user to customize either generation of a one-time card number or a user identifier;

(2) generating a user one-time card number through use of a card number generator;

(3) submitting the user one-time card number and the user identifier to a verification agency for validation; and

(4) verifying that the one-time card number is valid.

2. A method as recited in claim 1, wherein the electronic card is a payment card and the one-time card number is a one-time payment card number.

3. A method as recited in claim 2, wherein the card number generator generates a new card number by executing an algorithm that uses a selected user key to generate the new card number.

4. A method as recited in claim 3, wherein the user can customize generation of the one-time card number by choosing either a first user key or a second user key as the selected user key, and wherein the algorithm will generate a first one-time card number if the selected user key is the first user key or a second one-time card number if the selected user key is the second user key, the first and the second one-time card numbers being different, but both valid with the user identifier.

5. A method as recited in claim 3, wherein the electronic card is comprised of:

a card base;

a computer affixed to the card;

an input mechanism;

a magnetic storage medium affixed to the card that can be read by a standard magnetic stripe reader;

an encoder for generating a data packet that is stored in a designated portion of the magnetic storage medium and is readable by a standard magnetic stripe reader; and

a power source for supplying power to the computer and the encoder;

wherein the electronic card is sized such that the magnetic storage medium can be read by the standard magnetic stripe reader.

6. A method as recited in claim 5, wherein the magnetic storage medium is a magnetic stripe.

7. A method as recited in claim 6, wherein the user identifier is stored in the magnetic stripe.

8. A method as recited in claim 7, wherein the user identifier is stored in a second track of the magnetic stripe with the user one-time card number.

9. A method as recited in claim 8, wherein the data packet is comprised of the user one-time card number.

10. A method as recited in claim 9, wherein the data packet is further comprised of the user identifier.

11. A method as recited in claim 10, wherein the encoder generates the data packet by creating flux reversals in ferromagnetic particles contained in the magnetic stripe.

12. A method as recited in claim 5, wherein the user can change the user identifier through use of a special function switch.

13. A method as recited in claim 5, wherein the user can change the user identifier through use of a special function code input to the computer.

14. A method for allowing customized use of an electronic card having a card number that varies with each use, comprising the steps of:

(1) allowing a user to select a customization parameter to customize a given use of the electronic card by at least one of the following steps: (a) customizing generation of a one-time card number; (b) customizing a user identifier; or (c) inclusion of a customization variable with information transmitted to a verification agency for validation of the given use;

(2) generating a user one-time payment card number through use of a card number generator;

(3) submitting the user one-time payment card number and the user identifier to a verification agency for validation, and, if the user has selected step (1)(c), including the customization variable with the submission for the given use; and

(4) verifying that the one-time payment card number is valid for the given use.

15. A method as recited in claim 14, wherein the electronic card is comprised of:

a card base;

a computer affixed to the card;

an input mechanism;

a magnetic storage medium affixed to the card that can be read by a standard magnetic stripe reader;

an encoder for generating a data packet that is stored in a designated portion of the magnetic storage medium and is readable by a standard magnetic stripe reader; and

a power source for supplying power to the computer and the encoder;

wherein the electronic card is sized such that the magnetic storage medium can be read by the standard magnetic stripe reader.

16. A method as recited in claim 15, wherein the magnetic storage medium is a magnetic stripe.

17. A method as recited in claim 16, wherein the user identifier is stored in the magnetic stripe.

18. A method as recited in claim 17, wherein the user identifier is stored in a second track of the magnetic stripe with the user one-time payment card number.

19. A method as recited in claim 18, wherein the data packet is comprised of the user one-time payment card number.

20. A method as recited in claim 19, wherein the data packet is further comprised of the user identifier.

21. A method as recited in claim 15, wherein the data packet is further comprised of the customization variable.

22. A method as recited in claim 16, wherein the data packet is further comprised of the customization variable.

22. A method as recited in claim 17, wherein the data packet is further comprised of the customization variable.

22. A method as recited in claim 18, wherein the data packet is further comprised of the customization variable.

23. A method for processing a plurality of payment card transactions based upon a user's selection of a customization variable for each of the transactions, comprising the steps of:

(1) establishing a plurality of handling options between a money source and the user;

(2) providing the user with a card number generator;

(3) allowing the user to complete a plurality of payment card transactions within a time period in accordance with the following steps: (a) allowing the user to select a customization parameter to customize a given use of the card number generator by at least one of the following steps: (i) customizing generation of a one-time payment card number; (ii) customizing a user identifier; or (iii) inclusion of a customization variable with information transmitted to a verification agency for validation of the given use; (b) generating a user one-time payment card number through use of the card number generator; (c) verifying the validity of the given use by submitting the user one-time payment card number and the user identifier to a verification agency for validation, and, if the user has selected step (3)(a)(iii), including the customization variable with the submission; and (d) repeating steps (a) through (c) at least once within the time period; and

(4) processing each of the plurality of payment card transactions in accordance with one of the plurality of handling options based upon the customization parameter selected for each of the plurality of payment card transactions.

24. A method as recited in claim 23, wherein the card number generator is included within an electronic payment card.

25. A method as recited in claim 24, wherein the electronic payment card is comprised of:

a card base;

a computer affixed to the card;

a keypad for providing input to the computer, the keypad having ten numeric keys and at least one special function key that are touch-activated;

a magnetic storage medium affixed to the card that can be read by a standard magnetic stripe reader;

an encoder controlled by the computer for generating a data packet that is stored in a designated portion of the magnetic storage medium; and

a power source for supplying power to the computer and the encoder;

wherein the electronic card is sized such that the magnetic storage medium can be read by a standard magnetic stripe reader.

26. A method as recited in claim 23, wherein the first and the second handling options are mechanisms to bill two separate accounts.

27. A method as recited in claim 26, wherein the user is sent a single bill for charges to the two separate accounts.

28. A method as recited in claim 27, wherein one of the accounts is established with a first money source and the second account is established with a second money source that is different from the first money source.

29. A method as recited in claim 26, wherein one of the accounts is a credit account and the second account is a debit account.

30. A method as recited in claim 26, wherein the user is sent a first bill for the first account and a separate bill for the second account.

31. A method as recited in claim 23, wherein the first and the second handling options are a first and a second mechanism for dealing with distribution of information concerning the plurality of payment card transactions.

32. A method as recited in claim 31, wherein the first mechanism restricts the distribution from the money source to a third party of information relating to any payment card transaction in which the user payment card number was generated by use of the first user key.

33. A method as recited in claim 31, wherein the first mechanism restricts the distribution from the money source to the second entity of personal information of the user relating to any payment card transaction in which the user payment card number was generated by use of the first user key.

34. A method as recited in claim 32, wherein the user provides the money source with consideration for use of the first mechanism.

35. A method as recited in claim 31, wherein the second mechanism permits the distribution from the money source to a third party of information relating to any payment card transaction in which the user payment card number was generated by use of the second user key.

36. A method as recited in claim 35, wherein the second mechanism permits the distribution from the money source to the second entity of personal information of the user relating to any payment card transaction in which the user payment card number was generated by use of the second user key.

37. A method as recited in claim 35, wherein the money source provides the user with consideration for use of the second mechanism.

38. A method as recited in claim 23, wherein the first and the second handling options provide a mechanism for classifying the nature of the plurality of payment card transactions.

39. A method as recited in claim 38, wherein the first handling option is used for business transactions and the second handling option is used for personal transactions.

40. A method as recited in claim 23, wherein the first and the second handling options provide a mechanism for identifying either a first user or a second user as the user.

41. A method as recited in claim 40, wherein approval of a payment card transaction for the first user is subject to different restrictions than approval of a payment card transaction for the second user.

42. A method as recited in claim 23, wherein the first and the second handling options provide a mechanism for controlling what information is reported about the plurality of payment card transactions in a billing statement.