WO1999010850A1

WO1999010850A1 - Apparatus and method for automated processing of product purchases and purchase transaction validations

Info

Publication number: WO1999010850A1
Application number: PCT/US1998/014490
Authority: WO
Inventors: Sanford A. Brumley; Robert W. Kramer; Fred G. Slavin; Melchijah Spragins
Original assignee: The Chase Manhattan Bank
Priority date: 1997-08-26
Filing date: 1998-07-13
Publication date: 1999-03-04
Also published as: AU8400098A; EP1010149A1

Abstract

An electronic commerce system and method that enables products to be purchased based on transaction charges that are posted to virtual credit cards. The electronic commerce system of the invention utilizes the advantages of proven credit card transaction handling technology in the context of non-credit card transactions. In one embodiment, the system consists of a first subsystem and a second subsystem. The first subsystem includes a merchant product database listing and describing plurality of products available to be purchased. A software search engine allows a user to search through the product database, designate products to be purchased, and develop a shopping list. The second subsystem is electronically linked with the first subsystem and includes a credit card transaction facility which is designed to receive the shopping list from the first subsystem and to debit charges against a virtual credit card that is associated with the potential purchaser. A billing facility of the second subsystem creates billing reports that are communicated from the second subsystem to the first subsystem. These billing reports develop usage charges solely on the basis of the number of commercial transactions and in a manner which leaves credit risks associated with the electronic commerce transactions with the merchant. Thereby, the electronic commerce system of the present invention is able to use existing credit card charging infrastructures for executing transactions which inherently are non-credit card transactions.

Description

APPARATUS AND METHOD FOR AUTOMATED

PROCESSING OF PRODUCT PURCHASES

AND PURCHASE TRANSACTION VALIDATIONS

BACKGROUND OF THE INVENTION The present invention is generally directed to electronic commerce and, more particularly, to electronic commerce which advantageously utilizes the existing credit card charging infrastructure to take advantage of the enormous economy of scale, proven technology and reliability of existing electronic commerce networks.

Practically throughout the world, commercial transactions between buyers and sellers are completed via the world-wide and highly-reliable system of credit card charging networks. Thus, merchants, service providers and numerous other organizations such as governments and non-profit entities complete commercial transactions by supplying their products and services and obtaining payments therefor through the network of credit card service providers. These credit card service providers include such famous organizations as Visa, MasterCard, Discover, American Express, etc. Over the years, the vast networks of communication systems have allowed merchants to efficiently and rapidly check the credit worthiness of and set credit limitations for various individuals, businesses, organizations, etc., validate purchases, and receive payments for merchandise and services in a streamlined, widely applicable and relatively efficient manner.

The services provided by the credit card processors are not inexpensive to merchants. Merchants that accept credit card charges typically pay bank interchange fees which are on the order of from about 1 % to 2%% of the price of the transaction. As a result, for merchants which sell tens or hundreds of millions of dollars of goods, the 1%% to 2 % service charge represents a huge outlay of money which has to be absorbed as the cost of doing business. To avoid credit card service charges, many business such as product manufacturers and the like conduct business directly with their customers, to whom they provide products on a net-30 day payment basis, i.e. customers are expected to pay within 30 days of receipt of invoice. While these businesses bear the risk that some customers might default on their payments, they enjoy the benefit of avoiding the steep 1%% to 2 % credit card bank interchange fees.

With the advent of the Internet, several business organizations have set up Internet accessible computer systems which provide publicly searchable product databases that describe the particular merchant's products. Such database may describe hundreds, thousands or even tens of thousands of different products. In addition to describing the products, the typical database includes such information as expected delivery dates, prices per unit, volume discounts, etc. To process customer orders placed via such company owned computer systems, absent an automated process these companies would require large staffs to process the computer generated orders, control the company's inventory and delivery of products, generate invoices and communicate with customers .

At present, product and service merchants are left to choose between running their own large, bureaucratic organizations to bypass the credit card establishment, or availing themselves of the credit card services to simplify their internal operations, but at the cost of paying the bank interchange fees.

SUMMARY OF THE INVENTION

Accordingly, it is an object of the present invention to provide an electronic commerce system which utilizes the advantages of credit card charging networks without incurring the typical costs associated therewith. It is another object of the present invention to provide an electronic commerce system which is simple to use and operate and which also conforms to existing modes of completing electronic commerce transactions from the point of view of the public at large.

It is yet another object of the present invention to provide an electronic commerce system which avoids some of the disadvantages of existing systems. It is yet another object of the present invention to utilize the credit card charging mechanisms that are part of the present crop of commercially available web merchant server systems.

The foregoing and other objects of the invention are realized by a system and method which utilizes the advantages of both existing credit card transaction handling infrastructures and the in-house computer network capabilities of merchant companies to provide to the public Internet accessible databases describing the company's various products and services, all the way through to completing the purchase. The invention allows merchants to enjoy the benefits of the credit card infrastructure without incurring the full bank interchange fees associated with such infrastructures . The invention achieves its objective by utilizing the existing credit card infrastructure through the creation of a special bureau or agency that creates and uses virtual credit card labels that are then assigned to individual purchasers on a transaction-by- transaction basis or, alternatively, on a purchaser identity basis. While the transaction appears to be a typical credit card transaction, the merchant is not subjected to the usual fees associated with credit card transactions, which are based on the size of the commercial transaction. Rather, a fixed fee is charged which is based primarily on the numbers of transactions being handled on behalf of the merchant, without regard to the dollar amount or size of the transaction. More specifically, the invention comprises the method and system for electronic commerce which implicates first and second subsystems which operate as follows.

The first subsystem includes a merchant-based product database that contains a list of various products of the merchant. The first subsystem also includes a search engine which enables a user to search through the product database to designate products to be purchased and to develop a report defining a "shopping list" of products to be purchased. It is preferred that access to the various merchant-based databases be controlled through the registration of first time users in a customer database which solicits and records personal data such as the user's business identity, credit history, method of payment and the like. The owner of a database can then authorize businesses and/or individuals to access the product database for the purpose of ordering various products therefrom. The first subsystems further includes an electronic link to the second subsystem typically run and controlled by a single financial institution which regulates and handles commercial transactions received from various merchants.

The second subsystem includes a credit card transaction handling facility which includes means for receiving purchase orders from the various merchants, authorizing and validating purchase orders to proceed and informing the various merchants that shipments of products may proceed. The second subsystem also includes a software facility and credit handling processor that creates the aforementioned virtual credit cards using existing credit card charging technology, solely in order to generate debit statements to purchasers of products, to collect funds and to track and log commercial transactions. In fact, unlike typical commercial credit card transactions, the financial institution which operates the second subsystem is not meant to operate in the manner of typical credit card processors which supply goods on credit. Instead, the credit risk of the commercial transaction remains with the merchant. This is accomplished by creating a private label credit card account where no physical credit card is used. The credit card transaction is merely a transaction against this virtual credit card which allows the system to utilize existing credit card infrastructures. Purchasers of products are billed by the financial institution and are expected to tender payment within a preset time period, usually thirty days. When customers tender payment, the financial institution credits the received funds to the bank account of the merchant, which account may be a bank account located at the financial institution or at a different financial institution (not involved in operating the second subsystem). Thereby, the present invention enables the use of existing credit card charging systems for executing non-credit card transactions .

Preferably, the system and method of the present invention also provide at the second subsystem the option to process commercial transactions via conventional credit cards. Thus, purchasers are able to choose to pay for products via conventional credit cards or on a net 30-day basis, when authorized by the merchant to purchase products in that fashion. Still further, the present invention provides a facility for aggregating accounts receivable collected in connection with thousands of commercial transactions into accounts receivable portfolios, which can be then purchased by lenders known as "factors" that are electronically connected to the second subsystem. The invention permits factors to participate in the financing of commercial transactions by selecting portfolios of accounts receivable and tendering discounted payments thereof to the merchants. In this fashion, the transfer of funds to the merchants can be speeded up for merchants that desire to improve their cash flow and reduce their credit risk.

Other features and advantages of the present invention will become apparent from the following description of the invention which refers to the accompanying drawings .

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram of an existing system for taking customer orders using the Internet. Figure 2 is a block diagram of a typical prior art electronic commerce system that uses the credit card billing infrastructure.

Figure 3 is a block diagram of the system of the present invention.

Figure 4 is a block diagram of the system of Figure 3 adapted for use with a plurality of merchants.

Figure 5 is a block diagram of a further embodiment of the system of Figure 4. Figures 6A-6C are flow-charts describing various aspects of the software facilities associated with the system of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Prior art Figure 1 diagrammatically illustrates an Internet-accessible product ordering system 10 of a typical manufacturing company, for example the fictitious Easybuy, Inc. company. To access the product ordering system 10, a typical Easybuy customer 14, running such program as Netscape's Navigator™ Program or the Microsoft Explorer™ Program on its computer network 16 or personal computer 12, accesses the Internet's World Wide Web 18 to establish a connection through a corporate computer network 26 to a product database 22 which lists all (or a portion) of the products of the Easybuy company. The database 22 may comprise a large memory managed by a database software facility, such as Oracle™ or Sybase™. The hardware and software blocks associated with the database 22 are well known and have been reduced to practice to store a huge number of parts, for example tens of thousands of parts such as nuts and bolts and the like.

The prior art allows the potential customer 14 to examine and search through the parts database 22 by flipping through HTML pages presented by a search engine 24 such as Saqqara™ which is installed on the web server 26 of the Easybuy company. In this manner, the customer is able to narrow the search by selecting different parameters that describe the product (s) he or she is searching for.

When the customer has found the desired products, the customer can click on an "order" icon which causes the computer system 26 to invoke a process running on an order generating facility 28, such as a commerce server that may be implemented, for example, as an IBM Commerce.Net server, OM Transact, MS Merchant Server or Netscape Commerce Server, that places the order in a "shopping basket". Once the customer has assembled a complete order containing all of the parts or products he or she wishes to purchase, the commerce server software facility formats a digitally encoded shopping list which lists all of the products to be purchased, as well as the accompanying tax and shipping charges, etc. The description below distinguishes between the merchants 15, e.g. Easybuy Inc., and the merchants' buying facility service or system 17, which comprises the elements 22, 24, 26 and 28 in Fig. 1.

Once the digitally encoded order has been logged, the typical company such as Easybuy deploys a large manual labor pool 30 to place the orders, prepare billing statements 32, manage the shipment of products to customers, handle collections 34 and communicate with customers concerning defects, irregularities in billing, complaints, returns and the host of other issues that arise in the normal course of business (as designated generally by the block 36) .

The system described above with reference to Fig. 1 is more typical of manufacturing concerns which deal with a smaller universe of customers who repeatedly buy products or parts for business rather than personal needs. For example, Easybuy Inc. may be an electrical parts manufacturing company or an automobile parts manufacturer which produces parts for the entire gamut of needs presented by an industry. The customers therefore are able to establish closer relationships with the merchants/sellers of parts, which builds up trust and confidence. Hence, it is not uncommon for the sellers to ship products on a net-30 days payment schedule. It is not necessary for the electrical-connector manufacturing company to sell products through credit card payment methods and to incur the steep 1%% to 2%% charges that are incurred by sellers of consumer products such as department stores and the like.

In contrast — see Figure 2 — department stores and other sellers of consumer oriented products, which do not typically develop close business relationships with a limited number of buyers, almost universally avail themselves of the services of credit card charging networks. In Figure 2, a typical credit card transaction is initiated through an electronic device or service, e.g. a VeriFone™ credit bureau calling device (not shown) , which calls a credit card processing center 40 which thereafter calls one or another of several credit card processors 42a, 42b, 42c, 42d that regulate and control transactions for different credit cards. These credit card processors or facilities may be a Visa credit card processor 42a, a MasterCard processor 42b, a Discover credit card processor 42c or any other such processor. Each of these credit card processors then initiates a call to one or another of different issuing banks 44a, 44b, 44c or 44d which has issued the particular credit card to check the credit limit or availability of the particular purchaser and to receive an authorization to proceed with the transaction. The issuing banks also prepare and mail billing statements 46 to customers, collect payments and handle customer complaints 48.

Conducting business via the system of Fig. 2 is very efficient and highly streamlined. But as noted previously, the credit card based system of Fig. 2 charges the merchants 15 fees that are calculated as a percentage of each transaction. In a nation such as the United States where commercial trade amounts to hundreds or even thousands of billions of dollars, the cost of the credit card infrastructure to business establishments adds up to billions of dollars.

Reference is now made to Fig. 3, which depicts the layout of a system and method which delivers the benefits of both the system of prior art Fig. 1 and prior art Fig. 2, while avoiding a substantial portion of the expenses associated with the credit card charging system of Fig. 2. Fig. 3 combines the merchant-based, customer interface and products searching system 17 of Fig. 1 with the credit card charging infrastructure 19 of Fig. 2, with some modifications. First, note that the corporate computer network 26 communicates in this configuration, via the system 28, which handles order generation and external communications, with the credit card infrastructure 19. The system 28 preferably comprises a commercially available, commerce server software and hardware system which communicates via telephone or satellite lines 49 with a special credit card processor, for example the merchant services system 50 of the Chase Manhattan Bank, the assignee of the present invention. The merchant services system 50 electronically receives all orders generated by the corporate network 26 of the merchant 15, in a manner identical to any other credit card transaction processor.

However, in departure from the prior art, the merchant services system 50 communicates with a special private label charging processor 52. This private label charging processor 52 has been especially set up to generate and use what are in effect virtual credit cards, for handling exclusively commercial transactions received from the merchant 15. However, unlike a typical credit card transaction, in which the credit card issuer bears the risk of purchaser default, the risk of non-payment by customers remains with the merchant 15.

The private label charging processor 52 prepares private label credit cards for the customers 14 of merchant 15 based on information which is provided by the merchant. Thus, the corporate computer network provides to the processor 52, such information as the personal data of the various customers, the credit limit for each customer, mode of payment which may, for example, be cash on a net 30-day basis or through a customer's bank and other information which pertains to and defines how funds will be collected in payment for merchandise delivered to the customers 14. With the above information in its database, the private label charging processor 52 proceeds, upon receiving a report of a transaction to be handled, by issuing a customer billing statement via block 46, which block 46 is configured to automatically prepare and mail statements to the customers 14. When the customer remits payments to the statement/collection group 46, receipt of those funds is reported by the private label charging processor 52 to the merchant services system 50, which deposits the funds in the merchant's bank account 54 (which may be a Chase Manhattan Bank account or a bank account at another financial institution) .

Alternatively, the private label charging processor 52 may be set up to communicate the commercial transaction to an electronic funds transfer group 56 which is configured and programmed to communicate with the customer's bank 58. In this instance, the arrangement contemplates that the customer's bank will pay the billing statement submitted via the private label charging processor 52 in due course, not unlike existing systems in which customer banks are set up to pay their depositors' utility bills, home mortgages and other monthly bills. In this arrangement, the system relies on the customer's bank to prepare and issue billing statements to the customer as indicated by flow-chart line 60.

At such time as the customer's bank 58 transfers funds in payment for the transaction through the electronic fund transfer group 56, receipt of such funds is reported to the private label charging processor 52 which in turn notifies merchant services 50 to credit the received funds to the merchant's bank account 54.

The merchants 15 corporate computer network 26 is also set up to communicate with merchant services 50 via a computer-based communication link that uses standard commercial communication protocols, for example the legacy system 62, through which the financial institution 19 is able to report to the merchant 15 information concerning receipt of funds from customers, the balance in the merchant's bank account 54 and other information that are necessary for administering the overall system of the present invention. Typically, information pertaining directly to the ordering and paying for products flows over the communication link 49 while financial information concerning balance of merchants' accounts and other more general information is communicated via the link 63.

It should be appreciated that the electronic funds charging and collection system comprising merchant services 50, private label charging processor 52, electronic fund transfer group 56 and the statement/collection group 46 does not entail the costly creation or construction of novel or new elaborate hardware and software systems. Rather, each of the systems such as the system 50, 52, 56, 58 are essentially hardware/software facilities which are known and exist per se and which already serve for and carry out such functions as tracking commercial transactions in a manner similar to the existing infrastructure that serves the needs of the credit processor establishments. In this respect, the setting up of the private label charging processor and the mode of transferring and crediting of funds and controlling commercial transactions between customers and merchants is similar to existing credit card charging systems and does not entail investments in engineering and erecting a new infrastructure. As a result, a financial institution which implements, runs and supervises the system of Fig. 3 is able to charge merchants 15 a comparatively modest, fixed fee per each commercial transaction, which does not vary with the size of the transaction. The same service fee can be charged to handle a $200 transaction as one involving $1,000,000. The fee can be set purely on the basis of the cost of running the operation, since the financial institution represented by block 19 does not bear any of the risk of non-payment which is left with the merchants 15.

Fig. 4 shows a further enhancement of the system of Fig. 3 which differs only in that it is able to handle a plurality of merchants 15a, 15b... 15N, rather than a single merchant. Thus, in accordance with a broader scope of the invention, customers 14 which may be located throughout the world are able to contact a variety of merchants, and have their orders placed with different merchants to be handled by a single financial institution 19 having the system of the present invention. It is expected that when the system of the financial institution 19 is fully implemented, the private label charging processor 52 will assign different private label credit cards to customers, so that each customer private label card will correspond to and facilitate commerce with a different one of the merchants 15a, 15b... 15N.

A still more elaborate implementation of the system of Fig. 4 is depicted in Fig. 5. Here, the universe of customers (designated by block 64) is shown communicating with various merchants (whose computerized parts ordering systems are collectively represented by block 66) . The financial institution 19 which operates the private label based system comprises the merchant interface block 68 which corresponds to the merchant services group 50 of Fig. 4 and handles conventional credit card transactions in block 70 and 72 as well as private label transactions in block 74. The customer interface block 76 provides a communication path to the universe of customers 64. Fig. 5 differs from Fig. 4 in that it provides a facility — namely the syndication and factoring interface 78 — that permits the financial institution 19 to speed up and facilitate the delivery of funds to the merchants 66 as explained below. The function of factors in commercial transactions is well known. Factors are financial institutions that study and analyze account receivables portfolios of various merchants for the purpose of purchasing the right to collect these receivables. The merchants receive an immediate cash payment which is discounted from the face value of the receivables. In this manner, a merchant that is owed for example $1,000,000 from a large group of customers is able to sell to a factor the $1,000,000 worth of accounts receivable at a discounted price, e.g. $900,000 or $950,000 etc. The existence of factors often helps merchants ease their cash flow problems. While the merchant receives less than the full value of the debt, the merchant gains by being freed of any further credit risk.

The system of the present invention allows commercial transactions recorded on the books of the private label charging processor 52 to be lumped and aggregated into various groups of accounts receivable portfolios. Those portfolios are posted on a database or a web page of the system 19 as indicated by the block 78. The different factors such as the factors 80a, 80b... 80N are now able to communicate with the syndication and factoring interface of the financial institution 19 to examine and optionally purchase one or another or several of these portfolios. As soon as those portfolios are purchased, the funds are transferred to the financial institution 19 which then immediately credits those funds to the merchants' bank accounts 54. These portfolios may be grouped on a merchant-by-merchant basis or on the basis of the character, size or kind of the receivables and, indeed, in any manner agreed to by the merchants 66 and the financial institution 19.

Other features and aspects of the system of the present invention can be discerned from the software and overall system flow-charts of Figs. 6A-6C. Assume that the merchant is company X that manufactures electrical components for the electrical/electronic industry, and that the financial institution 19 is the Chase Manhattan Bank, software flow block 90 shows that an X company customer, running one of the standard browser packages on its PC, is able to access a Connect program resident in the merchant's computer network 26 which enables the customer to run a search engine and set up customer data as indicated in block 92. This enables the customer to search through the product database 22, assemble a shopping list as indicated in block 94 and specify a payment mode as indicated at block 96. The Connect system then establishes an external communication path, as indicated at block 98, with the financial transaction facilitator 100 which in this case represents the Chase Manhattan Bank. Using the computer software system previously described, the Chase Manhattan Bank is able to complete the financial transaction and to communicate with the Connect system 26 through a protocol that is represented by block 102 of Fig. 6A.

The major software components of the transactions/events taking place at the Chase Manhattan Bank institution are depicted in Fig. 6B. The financial transaction facilitator program 104 includes a software facility 106 which serves to establish communication with merchants and a further facility 108 that receives and processes orders for various products. At decision block 110, the software determines whether payment for the commercial transaction will be via a conventional credit card or on a net 30-day basis.

If the transaction is to be processed in accordance with conventional credit card procedures, the software proceeds to software facility 112 which contacts the card issuer, e.g. Visa, MasterCard, etc., which in turn contacts the issuing bank as indicated in block 114. If the particular customer has sufficient credit available to him/her, decisional block 116 routes the software to block 118 which issues an authorization that allows the commercial transaction to proceed. This authorization is communicated to the merchant's computer network — see Fig. 6A — via the transaction reporting interface 102. Alternatively, if the customer does not have sufficient credit with the merchant as tracked by the charging processor to cover the commercial transaction, the program issues a rejection as indicated in block 120 and the software program returns to handle other system tasks as indicated at block 122.

If, on the other hand, the Chase Manhattan Bank has received an indication that the particular commercial transaction is to proceed on a net 30-day payment basis, the software proceeds to decisional block 110, i.e. to the private label generating software block 124 which is responsible for handling the creation and the charging of orders to private label cards. Once such a transaction has been received, the decisional block 126 determines, based on inputs received from the merchant, whether the size of the commercial transaction exceeds the credit available to the particular customer as of the time of the transaction. If there is insufficient credit, then a rejection is issued at block 128 and the program continues through the return block 122. On the other hand, if sufficient credit is available, an authorization is returned to block 122 and a charge is registered at block 130 and the software determines whether the funds in payment for the transaction are to come from the customer's bank or from the customer directly. If from the customer's bank, decision block 132 proceeds to post the necessary ACH debit by interfacing with the customer's bank as indicated at block 134. Alternatively, invoices are issued and funds are collected directly from the X company customers as indicated by block 136.

As a general note, it is assumed herein that the reader understands that the process of transferring funds in the banking industry distinguishes between an "authorization" phase and a "settlement" phase. The authorization phase checks if a purchaser has available the necessary funds to consummate the transaction. If yes, the authorization phase locks up the required amount in the purchaser's account. The "settlement" phase transfers the funds to the receiving party, usually the seller of the merchandise, which in this case is the financial institution which acts as the intermediary between the purchasers and the merchants 15. In the present invention, it is preferred that the financial institution settles with the merchants on a monthly basis. This means that the financial institution actually transfers the funds by accrediting the merchant's account with the moneys that the financial institution had collected during the previous month from customers of the merchant. Rejection of a commercial transaction can also be based on the size of the transaction. For example, the system may be set up to be used only for transactions that exceed a certain dollar value, for example $50. Or the software may limit certain customers to transactions which must be prepaid, in which case the transaction would be allowed to be completed only by directing the program to the customer's bank for immediate collection of funds. In any case, as soon as the software block of Fig. 6B has determined that the commercial transaction can proceed, appropriate authorization is issued to the merchant, i.e. to the Connect program so that Connect may arrange for the shipping of the purchased merchandise. Other functions performed by the software facility of the financial institution are shown in Fig. 6C. Thus, the financial transaction facilitator program 104 also handles funds received from customers. When such funds are received, decisional block 136 determines whether those funds were received in connection with commercial transactions that were consummated under the private label scheme of the present invention. If so, decisional block 138 proceeds to block 140 and credits the merchant's account with the funds that were received directly from the customers. On the other hand, if such funds were collected from the purchaser's bank, then an ACH credit report is issued as indicated by block 142 and the program proceeds to credit the received funds to the merchant's credit account 140. In either case, whenever funds are received, a report is issued to the merchant as indicated at block 144 and the program returns at 146.

At decisional block 136 is also determined whether other functions are to be executed. Thus, if decisional block 148 determines that there are no other functions to be performed then the program returns at block 146. Otherwise, the program queries whether it should handle factoring requests from the factors 80a, 80b... 80N as previously described. If so, decisional block 150 directs the program to the software facility 152 which handles the communications with the factors through external communication links. If no factoring is required, the program proceeds from decisional block 150 to query whether any other administrative tasks are to be performed. If the answer is negative, the program returns. However, if such administrative tasks exist then the program turns to handle the tasks as indicated generally by block 154.

Although the present invention has been described in relation to particular embodiments thereof, many other variations and modifications and other uses will become apparent to those skilled in the art. It is preferred, therefore, that the present invention be limited not by the specific disclosure herein, but only by the appended claims.

Claims

WHAT IS CLAIMED IS:

1. An electronic commerce system for enabling products to be purchased via public communication links, the electronic commerce system comprising: a first subsystem and a second subsystem; the first subsystem including:

(a) at least one merchant product database listing and describing a plurality of products available to be purchased, the product database being associated with a merchant; (b) a software search engine for enabling a user to search through the product database, for designating products to be purchased, and for developing a report defining a shopping list of products to be purchased; (c) a public access facility for enabling authorized purchasers to access the product database and to create said shopping list; and

(d) linking software for establishing a link between the first subsystem and the second subsystem; the second subsystem comprising:

(a) a credit card transaction facility including a software facility for receiving the report from the first subsystem, for authorizing shipments of purchased products and for debiting charges against a credit card associated with the purchaser;

(b) a software facility for creating said credit card as a virtual credit card that exists solely for the purpose of generating debit statements to said purchaser; and

(c) a billing facility for creating billing reports that are communicated from the second subsystem to the first subsystem, the billing reports defining usage charges calculated on the basis of the number of commercial transactions and in a manner which leaves credit risks associated with electronic commerce transactions with the merchants; whereby the electronic commerce system enables use of existing credit card charging infrastructures for executing transactions which inherently are non-credit card transactions.

2. The electronic commerce system of claim 1, in which the first subsystem includes an authorization facility for authorizing members of the public to become authorized purchasers.

3. The electronic commerce system of claim 1, in which the second subsystem includes a merchant services facility through which communication is established with the linking software of the first subsystem.

4. The electronic commerce system of claim 3, including a credit limiting facility for establishing credit limits for each authorized purchases and means in the second subsystem for communicating with the credit limiting facility before allowing commercial transactions to be completed.

5. The electronic commerce system of claim 4, in which the second subsystem includes an electronic fund transfer facility for enabling the transfer of funds from a customer's bank to a merchant's bank account, at a predetermined time after the completion of a transaction.

6. The electronic commerce system of claim 5, in which the predetermined time is equal to about 30 days.

7. The electronic commerce system of claim 3, including an interface between the authorized purchasers and the first subsystem.

8. The electronic commerce system of claim 7, in which the interface is configured to utilize the Internet.

9. The electronic commerce system of claim 3, in which the second subsystem comprises a facility that enables a purchaser to pay for commercial transactions via conventional credit cards.

10. The electronic commerce system of claim 3, further comprising a plurality of the first subsystems, each first subsystem being associated with a different merchant of products.

11. The electronic commerce system of claim 3, in which the first subsystem comprises a firewall between the authorized purchasers and the first subsystem.

12. The electronic commerce system of claim 3, in which the second subsystem comprises a syndication and factoring interface for handling communication with a plurality of factors.

13. The electronic commerce system of claim 12, including a facility for aggregating accounts receivable recorded by the second subsystem into separate portfolios of accounts receivable and for posting the portfolios of accounts receivable on a network electronically accessible by the plurality of factors.

14. The electronic commerce system of claim 9, in which the conventional credit cards include one or more of a Visa, MasterCard, Discover and American Express credit cards.

15. A method of operating and controlling an electronic commerce system, the method comprising the steps of: providing a first subsystem including: at least one merchant product database, a software search engine and a public access facility; listing and describing on the product database a plurality of products available to be purchased and associating the product database with a predetermined merchant; using the software search engine to designate products to be purchased and for developing a report defining a shopping list of products to be purchased; enabling members of the public to access the product database and the software search engine through remotely operable devices and via public communications lines; electronically linking the first subsystem with a second subsystem; operating at the second subsystem a credit card transaction facility and receiving thereat the report from the first subsystem; authorizing shipments of purchased products and debiting charges against a credit card associated with the purchaser; using the credit card to record transactions which serve solely the purpose of generating debit statements to the members of the public; creating billing reports and communicating those billing reports from the second subsystem to the first subsystem, the billing reports defining usage charges calculated on the basis of the number of commercial transactions and in a manner which leaves credit risks associated with electronic commerce transactions with the merchant; whereby the electronic commerce method enables use of existing credit card charging infrastructures for executing transactions which inherently are non-credit card transactions.

16. The method of claim 15, further including authorizing members of the public to become authorized purchasers.

17. The method of claim 15, including providing at the second subsystem a merchant services facility and using the merchant services facility to communicate with the first subsystem.

18. The method of claim 17, including establishing credit limits for each authorized purchaser and rejecting commercial transaction which attempt to exceed the credit limit.

19. The method of claim 17, including providing an electronic fund transfer facility and enabling the transfer of funds from a customer's bank to a merchant's bank account at a predetermined time after the completion of a transaction.

20. The method of claim 19, in which the predetermined time is equal to about thirty days.

21. The method of claim 17, including enabling purchasers to communicate with the first subsystem via the Internet.

22. The method of claim 17, including providing in the second subsystem a facility that enables a purchaser to pay for commercial transaction via a conventional credit card.

23. The method of claim 17, including establishing for each purchaser a unique and different virtual credit card associated with different merchants.

24. The method of claim 17, including providing an interface for communicating from the second subsystem with a plurality of factors.

25. The method of claim 24, including aggregating accounts receivable recorded by the second subsystem into separate portfolios of accounts receivable and posting portfolios of the accounts receivable on a network electronically accessible by the plurality of factors.