JP2001512863A - Method and system for processing e-commerce transactions - Google Patents

Abstract

SUMMARY A system and method for processing an electronic payment transaction accesses and stores information describing an item sold by a merchant on a commercial server. The merchant also defines payment processing rules that specify the payment methods allowed by the merchant. The merchant is provided with a reference that identifies the commercial server and the item. The merchant preferably places this reference on the merchant's website on a web page presenting the item for sale. A customer who views the merchant's website indicates a request to purchase the item by selecting this reference. As a result, the customer is connected to the commercial server, provided with information about the item from the commercial server, and presented with a list of payment options. The customer preferably selects a payment option and provides payment information, such as a credit card number, to the commercial server. In response, the commercial server contacts the selected payment system to complete the e-commerce transaction. The commercial server then notifies the customer and merchant of the outcome of the e-commerce transaction and delivers the item to the customer.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

FIELD OF THE INVENTION

The present invention relates generally to electronic commerce, and more particularly, to a method and apparatus for processing electronic payment transactions using the Internet.

[0002]

BACKGROUND OF THE INVENTION

Electronic commerce performed over the Internet has become increasingly important over the last decade. Online merchants sell or rent, including goods such as compact discs, books and clothing, as well as those related to intellectual property (Intellectual Property), such as the distribution of music, movies, and ebooks For goods and services. The goods can be sent to the customer by email or various other delivery means. In contrast, intellectual property may allow a customer to download via File Transfer Protocol (FTP), provide the customer with an access key, establish a Telnet session, or Through the form of electronic distribution
Can be delivered to customers.

[0003] Typically, these goods and services are displayed on the merchant's website, and potential buyers use web browsing software (web browsers) such as NETSCAPE NAVIGATOR ™. Then, look at those items, select and buy. The customer typically pays for the item by establishing a secure connection with the merchant's web server and sending payment information, such as a credit card number, to the merchant. In this case, the merchant verifies the payment information using back-end processing and receives the payment. For example, a merchant contacts a credit card issuer using a secure telephone line or network link before accepting a customer order. Eventually, the merchant and the credit card issuer process the payment,
Deliver goods or services to customers.

[0004] The difficulty with the above scenario is that each merchant must be equipped with a merchandise inventory and payment database, payment acceptance and verification system. For example, merchants must build and maintain a database that tracks sales, delivery, and payment information, as well as inventory of goods, to support an e-commerce system. Maintaining this database is enormous, and it is an extremely complex task, the difficulty of integrating it into traditional accounting and processing systems, and the lack of truly skilled workers. This problem is exacerbated. In addition, merchants must design the web page to securely accept order and payment information and implement features to verify payment. These tasks can be extremely difficult if the merchant accepts payment using many different methods, such as a credit card or electronic money transfer, or accepts payment in more than one currency. In addition, having many different payment accepting systems on the Internet provides more opportunities for fraud and abuse, as the flaws in each system can be exploited unfairly.

[0005] While Internet e-commerce clearinghouses are provided for processing transactions from many different groups, these clearinghouses do not provide a convenient interface for merchants. Absent. In addition, the merchant must again establish the payment, verification and database system described above.

Therefore, there is a need in the art for a method and system for processing electronic commerce on the Internet that reduces the amount of work that must be performed by online merchants. The method and system may enable merchants to easily and verifiably track inventory, sales, and deliveries, and transparently support different types of payments and currencies. preferable.

[0007]

SUMMARY OF THE INVENTION

The above request is to enable the merchant to easily sell tangible and intangible goods in combination, and to have the merchant set up an account on a commercial server (commerce server), thereby increasing sales and inventory. And a method and system for processing e-commerce transactions that supports delivery tracking and various payment systems. The commercial server provides an inventory, accounting, and order management system to the merchant. In addition, commercial servers allow merchants to process electronic commerce with other merchants and suppliers.

The commercial server includes a web server that provides a web page to a merchant. By using these web pages, merchants build accounts on commercial servers. Next, the merchant provides the commercial server with information on items for sale, such as air tickets, clothes, books, software products, or playing time of online games. The merchant also provides the commercial server with other attributes of the item that the customer can select, such as, for example, the amount of the item and the period of use. In addition, the merchant has a payment process that defines the merchant's acceptable payment options, such as what currencies and payment systems are available, and when and how often to bill the customer. Provide rules.

Preferably, the commercial server stores information received from the merchant in an entry in a database. In one embodiment, the entries in the database classify the item, such as a hard item, a soft item, or an online (delivery) item, depending on the delivery options available for the item. Further, the commercial server indicates a commercial server and includes a universal resource locator (information) that includes information that allows the commercial server to identify an entry in the database with which the payment button is associated.
URL) to the merchant. Merchants preferably provide a payment button on the merchant's website.

[0010] The customer selects the pay button when he wants to purchase the associated product. In response, the customer's computer is automatically connected to a web server managed by a commercial server and provided with the merchandise-entered item information. In addition, the customer is presented with payment options allowed by the merchant's payment processing rules. In this case, the customer preferably provides the payment information necessary for completing the transaction to the web server.

If the merchant's payment item specifies that payment is required, the commercial server identifies the remote payment system selected by the customer and contacts it to complete the e-commerce transaction. It is preferable to take Preferably, a module in the commercial server converts the calls generated by the commercial server into a format used by the selected payment system. Similarly, this module converts the response received from the payment system into a format used by the commercial server. The commercial server then notifies the customer and merchant of the outcome of the e-commerce transaction and, if appropriate, delivers the item using one of the delivery options specified in the database.

In accordance with the present invention, a method for processing e-commerce between a remote customer and a remote merchant comprises:
Receiving information identifying the item purchased by the customer, receiving payment information specifying the payment method used by the customer to purchase the item, and paying the transaction at a remote payment system specified by the payment information. And notifying customers and merchants of the outcome of the payment transaction.

[0013] Similarly, computer program instructions for processing an electronic commerce transaction according to the present invention include instructions for storing item information received from a merchant,
Instructions to issue a reference to the merchandise stored item information, instructions to receive from the customer an e-commerce transaction identifier including a reference to the stored item information issued to the merchant, and accept payment information from the customer Instruction,
And instructions for processing an e-commerce transaction with the remote payment system.

[0014]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

As used herein, "Internet" refers to a global network of interconnected computer systems, and "World Wide Web" (WWW) refers to a global hypertext system that uses the Internet as a transmission mechanism. “Universal Resource Locator (URL)” refers to a piece of information or software functionality on a computer connected to the Internet. A "web server" is a program that receives a request for information assembled according to the hypertext transfer protocol (HTTP). "Web page" is information provided by a web server in response to this request. The Common Gateway Interface (CGI) is a standard that describes how a web server accesses an external program, usually called a "CGI program" or "CGI script", called by a web page. Of course, the invention is not limited to the Internet, but can be used with any digital network that supports e-commerce. For non-Internet systems, the terms defined above also include the equivalent in non-Internet systems for communicating between the various entities described herein.

FIG. 1 shows a high-level block diagram of an electronic commerce system 100 according to an embodiment of the present invention. Here, a customer computer (sometimes described as “customer”) 1
10, a merchant web server (sometimes described as "merchant") 112 and a commercial server (CS) 114 are shown, all connected to the Internet 116. In an exemplary embodiment, customer computer 110 includes, among other things:
It is a personal computer including a processor, a memory, a storage device, and a monitor. Customer computer 110 is connected to Internet 116 by network connection 118. The network connection may be, for example, a modem connected to an analog telephone line, a digital subscriber line, a cable modem using the bandwidth of a cable television coaxial cable, a high-speed digital line, or any other communication medium. Can be. Web browsing software, such as NETSCAPE NAVIGATOR ™, runs on the client computer and preferably transmits data from the client computer 110 to the merchant web server 112 via the network connection 118 and the Internet 116. In another embodiment, the customer computer 110 communicates with the Internet 116 using radio waves.
Or a palmtop device or personal digital system that communicates with other electronic commerce systems.

The merchant web server 112 is preferably similar to the customer computer 110 except that it has the processing power and communication bandwidth to process multiple customer transactions simultaneously. The merchant 112 sells goods, such as products, information, intellectual property, and / or services via a website running on the merchant web server 112. Merchant website 112 may, for example, display a catalog of software available for purchase, enable customer 110 to view flight schedules and purchase tickets, or Play online games, download books and music, or access information databases.

As used herein, the terms “customer” and “merchant” depend on the particular transaction being processed. In a chain of commerce transactions, the "customer" in the first transaction may be the "merchant" in the next transaction. For example, customer 110 may use the e-commerce system described herein to:
Parts of the product can be purchased from a plurality of different sellers or merchants 112 and the combined product can be sold via the customer's own website and CS 114.

The merchant website displays at least one “pay button”. The payment button is a graphic button, larger graphic area, string, or other form of URL link that the customer 110 can select and "press" with a mouse, physical button, or other input device. It is. In another embodiment, the payment button may be used in an electronic commerce system that does not use the Internet. In such an embodiment, the payment button is considered "pressed" whenever the customer 110 indicates a request to purchase the item. As will be described below, if the customer 110 wishes to purchase and pay for the item displayed for sale on the merchant's website, the customer 110 presses a payment button. In a preferred embodiment, all types of items for sale on the merchant's website have individual payment buttons. When customer 110 wants to purchase a product, customer 110 presses a payment button associated with the product. Next, attributes such as the amount of goods and the period of use that the customer 110 wants to purchase are specified by the customer
Preferably, a menu that can be designated by 0 is presented to the customer 110.

In another embodiment, the merchant website has only one payment button, or only one payment button for each category of item for sale. In this embodiment, it is preferable to present a selection menu to the customer 110 after pressing the payment button. For example, the selection menu may require customer 110 to identify a particular product that customer 110 wants to purchase, or an attribute of the product, such as a color.

Every payment button has an associated UR indicating information in CS 114
There is L. Preferably, a database key uniquely identifying merchant 112 and / or the item for sale is encoded in the URL. When customer 110 presses the pay button, customer 110 is reconnected to the web page provided by CS 114 and specific to merchant 112 and / or the item.

In one embodiment, the CS 114 queries the customer 110 for the quantity or period of use of the item that the customer 110 wants to purchase, and payment information. CS 114 receives the customer response and processes the e-commerce transaction according to payment processing rules and delivery options specified by merchant 112. CS 114 records the transaction in a database and notifies customers and merchants whether the transaction was successfully executed. Accordingly, merchant 112 is relieved of processing electronic commerce transactions with customer 110.

FIG. 2 is a high-level block diagram illustrating functional components of CS 114 in accordance with a preferred embodiment of the present invention, and further includes remote payment system 222 and remote merchant (
A web server 223 is also shown. CS 114 has a customer 110 and a merchant 112 except that CS 114 has sufficient processing power and Internet 116 bandwidth to support multiple simultaneous payment button transactions as described herein. Desirably similar to a computer. The functions of CS 114 described herein may be performed by hardware or software modules within CS 114. In one embodiment of the present invention,
The functionality of CS114 is provided by software applications running on SPARC compatible hardware from INTEL x86 and SUN MICROSYSTEM under the control of UNIX operating system derivatives such as MICROSOFT WINDOWS NT and SOLARIS 2.5.1. In another embodiment of the present invention, the functionality of CS 114 is provided by a distributed computing system described below.

Preferably, the remote payment system 222 is a third party payment gateway or system. The gateway or system is preferably connected to an accounting transaction network, and thus typically connects to a computer at a bank or other financial institution for approval and settlement of e-commerce transactions. A typical gateway or system is CYBERCASH, e
-Can include CASH, MONDEX or SET. FIG. 2 shows a payment system 222.
Although only one is shown, the CS 114 may communicate with many different remote payment systems 222 via either a secure link on the Internet 116 or a dedicated secure link. Each payment system has an application programming interface (API). By using the API, CS 114 communicates with payment system 222 to perform secure and verifiable payment transactions.

[0024] The remote merchant 223 is preferably a merchant who sells goods via a website as described above. Remote merchant 223 may have an account at CS 114 or may have an interface for selling items similar to remote payment system 222. In general, remote merchant 223 is described in FIG. 2 to illustrate that customer 110's e-commerce transactions performed by CS 114 can contact remote payment system 222 and / or remote merchant 223. are doing.

The CS 114 includes a payment button transaction engine 210 coupled to a database 212 and a web server 214. Firewall 216
It is located between the web server 214 and the transaction engine 210. Although these functional components are shown in FIG. 2 as separate entities, the CS 114 comprises a plurality of engines, databases, and web servers, which cooperate with one another herein. It can also be performed on a distributed computer system that performs the functions described. For example, one implementation of CS 114 uses multiple transaction engines 210 and web server 214 and a single distributed database 212, thereby providing scalability to CS 114. The number of web servers 214 and transaction engines 210 depends on the actual system load and the need to achieve better performance by balancing the transaction load of the entire system.

The payment button transaction engine 210 includes a rules module 218 that controls the interaction and flow of information needed to complete a payment transaction. Further, the transaction engine 210 preferably includes a payment application programming interface (PAPI) module 220 that enables communication between the CS 114 and the remote payment system 222 and merchant 223. The PAPI module 220 includes each payment system 222 and merchant 2
The 23 different APIs are configured into a single, higher-level PAPI that can interface with each payment system 222 and merchant 223. Transaction engine 210 performs payment transactions with payment system 222 or merchant 223 by making a call to PAPI. PAPI abstraction (abstract
The ion) module 220 translates these calls into the payment system 222 or merchant 223 specific API used for the transaction. PAPI abstraction module 220 also converts data received from payment system 222 or merchant 223 into a format used by transaction engine 210. Thus, the PAPI abstraction module 220 simply generates a new PAPI for the payment system or merchant API and maps it to the PAPI abstraction module 220 to create a new payment system 222 and merchant 223.
Can be added to CS 114.

A payment button storage module (PB storage) 224 is coupled to the web server 214 to enable the merchant 112 to obtain a payment button. Web server 214
Is preferably an industry standard web server such as a NETSCAPE ENTERPRISE SERVER or APACHE web server. Web server 214 preferably provides secure communication with customer 110 and uses industry standard technologies, including Hypertext Markup Language (HTML), and HTTP to deliver information to customer 110. In addition, to ensure the confidentiality of communications with the customer 110, the web server preferably uses industry standard encryption techniques, including Secure HTTP (S-HTTP) and Secure Sockets Layer (SSL). . The firewall 216 allows only authorized communication between the web server 214 and the transaction engine 210, and reliably prevents malicious users from accessing or modifying the transaction engine 210.

The PB store 224 allows a merchant to obtain a payment button and add product description, merchant type, and other information to the database 212. In a preferred embodiment of the present invention, merchant 112 accesses the PB store via a website on web server 214. The PB storage module 224 captures the actions of the merchant 112 of the web server 214 and creates an appropriate entry in the database 212.

In one embodiment of the invention, the PB store website describes the payment button mechanism, the services provided by the payment button vendor, and the cost of the services. In addition, the website includes a merchant registration form 226 for registering a new merchant, a merchant update form 228 for updating a merchant registration, and a payment button generation form 230 for issuing a payment button to the registered merchant. It is preferred to have. These forms preferably comprise a CGI program for performing the functions described herein.

The merchant registration form 226 allows the merchant 112 to enter information identifying the merchant 112 and includes a payment button that allows the merchant 112 to pay a registration fee. Once the payment has been verified, merchant 112 is preferably issued a login / password pair and an account for CS 114, which allows merchant 112 to access the payment button generation form and access the merchant's account. Can be maintained. Similarly, Merchant Update Form 2
Preferably, 28 comprises a payment button that allows the merchant 112 to pay the renewal fee.

The payment button generation form 230 provides merchant 112 with product description data such as item name and description, price, type and delivery options, and supported payment cards such as credit card, payment system, and currency. To be able to enter. Further, the payment processing rules classify the payment system according to priority, describe when payment is to be charged (eg, a merchant can require charging after 90 days), and / or Alternatively, the quantity or use period of the article that can be obtained at a predetermined price is described. In one embodiment of the invention, merchant 112 enters item description data and payment processing rules by uploading a file in a standardized format to a website with information.

When the input of the data is completed, the payment button generation form 230 transmits the data to the transaction engine 210 and
Reference numeral 10 stores the information at a position designated by a key in the database 212. The transaction engine 210 returns the key to the PB storage website, which presents the merchant with a payment button download page that displays the results of the payment button generation transaction. If the transaction has been successfully completed, the payment button download page will have a payment button issued to merchant 112. This payment button has an associated URL that specifies the key. Accordingly, little or no technical effort is required to maintain each quotient in CS 114.

In one embodiment of the present invention, there are multiple PB-stored websites that communicate with database 212 via transaction engine 210. When the payment button is created, the transaction engine 210 creates a field in the database 212 entry that specifies the PB store that created the payment button. Thus, the payment buttons can be "branded" between different payment button vendors.

The database 212 is preferably a robust relational database. The preferred embodiment of the present invention uses ORACLE 7 to perform the functions described in the present invention. The database 212 includes a description of the item, payment processing rules, and
Stores other information needed to complete the payment transaction on behalf of merchant 112. This merchant information is preferably accessed in the database by using a key assigned to each merchant 112 and / or the item for sale. Database 212 is also used as a storage location for transaction information, including authorization logs, payment status and completion records, and other information required by merchant 112 and CS 114.

FIG. 3 is a high-level block diagram showing functional components in database 212. The illustrated database entry 300 comprises a first (main) entry 310 linked to at least one of three types of item entries 312, 314, 316. First entry 310 is an entry identified by a key provided to merchant 112. Thus, the first entry 310
When the merchant 112 provides the key while using the PB store website, or when the customer 110 purchases the item identified in the database entry 310 using the URL provided by the payment button Is generally accessed at one of the times.

The first entry 310 includes a field 318 that stores payment processing rules for an item specified by the merchant 112 via PB storage. The first entry 310 also includes a field 320 that holds information on the type of item specified by the merchant 112. The item type information preferably describes the attribute of the item input by the merchant 112. In addition, the item type information field 320 contains other database entries 31 that describe the item's delivery options.
Preferably, at least one link is provided for 2,314,316.

The delivery options available for an item depend on the type of item. FIG. 3 shows three database entries 312, 314, 316 describing delivery options for hard, soft, and online goods. However, one embodiment of the present invention can have many different types of items and corresponding delivery options. Hard articles are generally mass-produced physical products such as clothing, books, or mechanical parts. Accordingly, entry 312, which holds delivery option 322, describes (a list of) various shipping methods and companies available for delivering the hard goods to customer 110.

[0038] In contrast, soft goods are typically intangible intellectual property, such as music, electronic books, or software. For example, the software article may be a streaming music file that the customer 110 can play. Thus, entry 314, which holds delivery option 324, can list (a list of) URLs or electronic keys that can be provided to the customer to perform the purchase. For example, option 324 may send instructions to customer 110's computer system to initiate an FTP session to download the purchased software item.

An online item is typically an online service or customer 110
Access to other software that runs remotely. For example, an online item refers to accessing an electronic information database or an online game. Accordingly, the entry 316 holding the delivery option 326 preferably comprises instructions for allowing the customer 110 to access the online item. For example, option 326 may provide instructions for launching a telnet session with an electronic database for a time limit.

FIG. 4 is a flow diagram illustrating the interaction between customer 110, merchant 112, CS 114, database 212, and payment system 222 when completing a payment transaction in accordance with a preferred embodiment of the present invention. . In the flow chart,
Time elapses from the top to the bottom of the figure, with horizontal lines representing communications between the various entities. FIG. 4 shows only the main interactions between the entities, and thus does not represent all the interactions. Further, FIG. 4 illustrates a simple example of the present invention, in which the payment processing rules of merchant 112 must process the payment transaction when customer 110 receives an order. Specifies that it must not.

Initially, the customer 110 browses the merchant's website and decides to purchase the item by pressing 410 a payment button associated with the item to be purchased. In response to this press, merchant's web server 112 redirects the customer's browser to a location on CS 114 specified by the URL associated with the payment button (412). The customer's browser renders the referenced page CS1
Fetch from 14 (fetch).

The CS 114 analyzes the URL received from the customer 110 for the key of the database 212 corresponding to the item that the customer 110 wants to purchase. Using this key, the CS 114 accesses the database 212 (416) and
12 dynamically generates a web page indicating the attributes of the item and the payment options available, as defined by. Further, CS 114 preferably determines the language used by customer 110 and the currency supported by merchant 112 and modifies the web page accordingly. This generated web page,
Sent to the customer 110 (418). FIG. 5 shows an exemplary screen display 500 of a web page for obtaining payment information from a customer 110.

The customer selects desired item attributes and payment service, inputs necessary payment information such as a credit card and account number, and transmits these data to CS 114 (420). CS 114 stores the received data in database 212 (422) and contacts the selected payment system 222. As mentioned above,
The CS 114 uses the PAPI module 220 to execute the transaction engine 2
10 to the selected payment system 22
It is preferable to convert to API 2. CS 114 preferably stores 426 all records of communications with payment system 222, customer 110, and merchant 112 in database 212. By doing so, the database 212 can be used to reconstruct the history of transactions to provide error tracking and accounting services. If payment system 222 rejects the transaction, CS 114 issues a web page to the customer displaying this result and presenting an alternative payment method, if any (this interaction is not shown in FIG. 4). ).

If the payment system 222 authorizes the transaction, the CS dynamically generates a web page containing payment status information and sends this information to the customer 110 (428). This page contains the receipt (reception) generated by CS114
Preferably, a number or approval number is included. In a preferred embodiment of the present invention,
The authorization number is a unique number that encodes the transaction, session, merchant identification, and time and date stamp. This authorization number is a key to a database entry that holds transaction information, confirms payment, queries CS 114 for payment status information, and uses CS 114 to provide the payment system with account status information. Merchant 112 and customer 110 to query
Is preferably one that can be used later. The web page also contains the merchant 11
2 preferably includes any other information required and a link to an approval page on the merchant website 112. FIG. 6 shows a typical screen display 600 of an order approval web page.

The CS 114 also notifies the merchant 112 that the payment has been accepted (428) and sends the same receipt or authorization number sent to the customer 110.
In one embodiment, this notification is performed by a secure email message. Thus, both the customer 110 and the merchant 112 are notified that the purchase has been made.

Finally, the customer 110 fetches (430) an approval web page on the merchant's website. Preferably, this web page contains additional information about the purchase,
Or, provide the customer 110 with any other information that the merchant 112 wishes to provide.

In summary, the present invention is a system, method, and computer program instructions for processing e-commerce transactions via the Internet or any electronic communication system. The merchant 112 opens an account on the CS 114 and provides information about the items that the merchant 112 sells. CS 114 stores this information in database 212 and issues a URL to merchant 112 that includes the key to the database entry. The merchant 112 provides this URL to the customer who wants to purchase the item, and connects the customer 110 to the CS 114. CS 114 collects payment information from customer 110, processes the e-commerce transaction at remote payment system 222, and notifies customer 110 and merchant 112 of the results.

[Brief description of the drawings]

FIG. 1 is a high-level block diagram of an e-commerce system according to one embodiment of the present invention.

FIG. 2 is a high-level block diagram illustrating functional components of a commercial server according to one embodiment of the present invention.

FIG. 3 is a high-level block diagram illustrating entries in a database associated with a commercial server according to one embodiment of the present invention.

FIG. 4 is a flowchart illustrating interactions between a customer, a merchant, a commercial server, and a payment system when completing a payment transaction according to one embodiment of the present invention.

FIG. 5 shows an exemplary screen display of a web page for obtaining payment information from a customer.

FIG. 6 shows a typical screen display of an order confirmation web page.

──────────────────────────────────────────────────続 き Continued on the front page (51) Int.Cl. ⁷ Identification symbol FI Theme coat ゛ (Reference) G06F 17/60 504 G06F 17/60 504 (81) Designated country EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE), OA (BF, BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, GM, KE, LS, MW, SD, SZ, UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ) , TM), AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, I, GB, GE, GH, GM, HR, HU, ID, IL, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MD, MG , MK, MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, UA, UG, UZ, VN, YU, ZW

Claims (17)

[Claims] 1. A computer system for supporting e-commerce transactions between a customer and a remote merchant, the computer system comprising: merchant information identifying an item provided for sale by the remote merchant. An electronic commerce transaction that communicates with the database and a remote payment system to perform an electronic commerce transaction, the transaction engine specifying, from a customer, an entry in the database. A first module for receiving an identifier of the remote payment system from a customer; and a second module for receiving the remote payment system using the payment information received from the customer. And a third module for performing an electronic commerce transaction by stem, a computer system. 2. The transaction engine further includes a fourth module for notifying the remote merchant and the customer of the result of the e-commerce transaction.
The computer system of claim 1. 3. A web server that communicates with the transaction engine to communicate with the remote merchant and the customer; and a web server and the transaction engine to secure communication between the web server and the transaction engine. The computer system of claim 1, further comprising a firewall between 4. The fifth module for dynamically generating a web page from an entry in the database and providing the web page to the customer via the web server. Wherein the web page comprises a fifth module comprising: providing information about an item offered for sale by the remote merchant and facilitating the collection of payment information from the customer. The computer system according to claim 3. 5. A method for receiving merchandise information identifying an item provided for sale by the remote merchant via the web server, generating a database entry for holding the merchandise information, and 4. The computer system of claim 3, further comprising a sixth module for providing a merchant with a reference to the database entry. 6. The computer system of claim 1, wherein the e-commerce transaction identifier is a URL that identifies the computer system and includes a key to an entry in the database. 7. The database further includes: an entry specifying payment processing rules defined by the remote merchant; and an entry specifying delivery options for an item offered for sale by the remote merchant. The computer system of claim 1. 8. There is a plurality of available remote payment systems, wherein said second module for receiving payment information from a customer receives payment information identifying one of said available remote payment systems. The computer system of claim 1 wherein: 9. The computer system of claim 1, wherein said transaction engine is executed by a plurality of distributed computer systems. 10. A method for processing an e-commerce transaction between a remote customer and a remote merchant, the method comprising: receiving information identifying an item to be purchased by the remote customer; Receiving payment information specifying a payment method used by a remote customer; processing a payment transaction with a remote payment system specified by the payment information; and providing the remote customer and the remote merchant with: Providing the result of the payment transaction. 11. Receiving information about the item to be purchased from the remote merchant; storing the information about the item to be purchased at a specified location; and providing the remote merchant with the specified location. 11. The method of claim 10, further comprising: providing a reference to: 12. The method of claim 11, wherein in response to the remote customer's request to purchase an item, the remote merchant provides a reference to the specified location to the remote customer. 13. The method of claim 10, further comprising providing the remote customer with a list of item attributes that can be selected by the remote customer. 14. The method of claim 1, further comprising: receiving payment processing rules specifying payment options available to purchase the item; receiving information identifying items to be purchased by the remote customer; 11. The method of claim 10, comprising receiving a delivery option. 15. A computer readable medium having encoded computer instructions for processing an electronic commerce transaction between a remote merchant and a remote customer, wherein the computer instructions are received from the remote merchant. Instructions for issuing a reference to the stored merchandise information to the remote merchant; and a reference to stored merchandise information issued to the remote merchant. Instructions for receiving an e-commerce transaction identifier from the remote customer; receiving instructions from the remote customer for payment information identifying a remote payment system; and receiving the payment information received from the remote customer. Use to process e-commerce transactions with the remote payment system. It consists of the instructions for. 16. The computer-readable medium of claim 15, wherein the instructions further comprise: instructions for notifying the remote merchant and the remote customer of the results of an e-commerce transaction. 17. The instructions for storing item information received from the remote merchant, the instructions for receiving payment processing rules specifying payment options for an e-commerce transaction from the remote merchant; 16. The computer-readable medium of claim 15, including instructions for receiving delivery rules specifying delivery options for an e-commerce transaction from the remote merchant.