CN1791887A - Method and architecture for facilitating payment to e-commerce merchants via a payment service - Google Patents

Abstract

A method and architecture for facilitating payments to e-commerce merchants via a payment service are disclosed. The method enables a customer user of an electronic storefront hosted by a merchant to make purchases via the payment service, wherein the interaction between the electronic storefront and the payment service is transparent to the user. In response to a user's checkout request, the user's browser is directed to a payment service website. Information from which authorization to use the payment service can be determined can be passed to the payment service. The payment service then returns the browser to a selected checkout process hosted by the electronic storefront, wherein if the user and the merchant are authorized to use the payment service, the checkout process offers an option to use the payment service; otherwise, the checkout process does not include the payment service option. In one embodiment, an application programming interface (API) provided by the payment service is used by the electronic storefront to facilitate transactions with the payment service.

Description

Method and architecture for facilitating payment to e-commerce merchants via a payment service

Cross References to Related Applications

This application is based upon co-pending provisional application Serial No. 60/456,504, filed March 21, 2003, entitled "METHOD AND ARCHITECTURE FOR FACILITATINT PAYMENT TOE-COMMERCE MERCHANTS VIA A PAYMENT SERVICE", hereby pursuant to 35U. S.C. §119(e) claims the benefit of its filing date.

technical field

The field of the invention relates generally to electronic commerce, and more specifically, but not exclusively, to a method and architecture for providing an Provides a mechanism for customer payment.

Background technique

The past decade has seen a huge growth in the use of the World Wide Web for online purchase of products and services. Such products are available via websites provided by e-commerce merchants such as e-tailers. Typically, an e-commerce website is built on a set of web pages that together form an "e-storefront." The web page typically includes an electronic catalog (and prices) of the products offered by the merchant, and a product selection often corresponding to a "shopping cart model". To obtain a shopping "experience," a customer is presented with one or more pages that correspond to a "checkout" or purchasing transaction process. At this point, the customer is typically required to enter payment information such as a credit card number and billing address. In some cases, all or part of this information may have been stored from a previous visit and recalled based on user identification, such as through a login process. After entering the payment information, the user is able to complete the transaction via a confirmation operation such as activating a "confirm purchase" button displayed on the corresponding web page.

In most cases, the only payment mechanism offered by e-commerce merchants to retail customers is via credit card. There are many reasons for this, including increased likelihood of receiving payment for goods, fraud prevention, and simplicity of accounting. However, credit card payments do not come without costs. For merchants, a transaction fee is subtracted by the credit card operator (eg a bank), which typically consists of a base amount plus a second amount based on some percentage (eg 1.5-2%) of the entire purchase price. This results in considerable expense for larger merchants. From a customer perspective, there are also many disadvantages associated with credit card payments. Many customers are tired of entering credit card information online and may not make a purchase from an e-commerce merchant. Additionally, many customers prefer not to purchase with a credit card, or do not have a credit card available. Accordingly, it would be advantageous to provide an alternative payment mechanism to e-commerce merchants and customers. Ideally, such an alternative payment mechanism should be easy to implement with existing network infrastructure.

Contents of the invention

According to aspects of the present invention, there is provided a method and architecture for facilitating payment to an e-commerce merchant via a payment service. The method enables customer users of an electronic storefront owned by a merchant to make purchases via the payment service, wherein the interaction between the electronic storefront and the payment service is transparent to the user. In response to the user's checkout request, the user's browser is directed to the payment service website. Information from which authorization to use the payment service can be determined may be communicated to the payment service. The payment service then returns the browser to the selected checkout flow hosted by the electronic storefront, wherein the checkout flow provides the option to use the payment service if the user and merchant are authorized to use the payment service, otherwise the checkout flow does not include the payment service option.

In another aspect of the invention, an application programming interface (API) provided by the payment service is used by the electronic storefront to facilitate transactions with the payment service.

Description of drawings

The foregoing aspects and many attendant advantages of the present invention may be better understood, and thus more readily appreciated, best understood, and thus more readily appreciated, by reference to the following detailed description when taken in conjunction with the accompanying drawings, in which like numerals refer to like numerals in the various views, unless otherwise indicated. part:

The architecture and network flow diagram of FIG. 1 corresponds to a first scheme for facilitating e-commerce merchant payment via a third-party payment service according to one embodiment of the present invention;

The flowchart of FIG. 2 shows further details of the operations performed by the architecture of FIG. 1 during a purchase by a customer from an e-commerce site;

Figure 3 illustrates a web page via which a merchant may specify one or more URLs corresponding to web pages to which a customer is redirected during the purchase checkout process;

Figure 4 is a schematic diagram illustrating a conventional computer server suitable for implementing embodiments of the invention disclosed herein.

Detailed ways

Embodiments of methods and architectures for facilitating electronic payments for goods and services purchased online are disclosed herein. In the following description, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the invention. However, one skilled in the art will recognize that the invention may be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring the technical aspects of the invention.

Throughout this specification, reference to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout the specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

In accordance with aspects of the invention, disclosed herein are methods and architectures for facilitating payment for goods or services via a third-party electronic payment service (ie, "payment service" or simply "service"). More specifically, these architectures provide efficient mechanisms for enabling payment for goods and services provided by e-commerce merchants via payment services on an individual customer basis. These mechanisms enable e-commerce merchants to easily add payment via service as an option for authorized customers and seamlessly integrate transactions via payment service into the merchant's checkout process. Additionally, the architecture enables the identification of customers who are authorized to use payment services without requiring the service to distribute any customer lists, etc. to e-commerce merchants using these mechanisms.

In one embodiment, this mechanism is facilitated via an application programming interface (API) and corresponding cookies related to usage of the API and payment services. When a customer logs into the payment service's website, a service cookie is sent to (and subsequently stored on) the customer's computer. For example, when a customer registers to use a payment service, a service cookie is sent back to the customer's device (such as a computer) to be stored on that device by the browser. This cookie is then used to facilitate future transactions via the service. Based on the presence of a service cookie, the service can determine whether the customer has ever successfully logged into the service website. If the appropriate cookie has been sent to the customer (actually the device), indicating that the customer is authorized to use the service, the service will advise the merchant via the API to allow the customer to use the payment service for the current purchase. Accordingly, the merchant will provide a checkout process suitable for using the service as a payment option.

An architecture and process flow diagram 100 corresponding to one embodiment of the present invention is shown in FIG. 1 , while a flow diagram further describing operations performed via the architecture is shown in FIG. 2 . The process begins at block 200, where the merchant enters into an agreement with the payment service to use the payment service API to facilitate payment by customers via the service. The administrator at the payment service, etc. then enables API access for the merchant. In one embodiment, merchant API access is enabled via an administrative tool for managing user accounts.

Next, in block 202, the merchant specifies a return URL for its website. In one embodiment, users of payment services, including merchants, are allowed to provide one or more return URLs to various sites operated by merchants via a user profile page hosted by the service that The page is shown in Figure 3. As described in more detail below, the merchant simply enters the URL address of each web page to which the merchant wishes the process to be redirected from the payment service site.

As shown in block 204, the final step of enabling use of the API is complete when the merchant incorporates the payment service's API into the appropriate pages on its website. These web pages typically include one or more pages that lead to the site's checkout process. The one or more pages are collectively represented by Merchant Page 1 in FIG. 1 - it should be understood that the provisions discussed below corresponding to Merchant Page 1 should be included in each web page corresponding to the initial portion of the checkout process. At this point, the merchant and service websites are configured to facilitate customer payments via the payment service.

During ongoing operations thereafter, various customers are allowed to provide payment for products purchased from the merchant via the payment service in the following manner. Generally, a customer will access a merchant website via a web-enabled device, such as a Macintosh computer 102, a personal computer (PC) 104, and a laptop computer 106 shown in FIG. 1 . Note that these are only typical web-enabled devices available to customers, other devices include but are not limited to PDAs, laptop PCs, web-enabled phones, workstations, and the like. For clarity, enhancements to the network architecture to support non-HTML browsers, such as the microbrowsers used in PDAs and web-enabled phones, are not shown or discussed here; for extending web access to such devices The infrastructure is well known in the art.

Continuing in block 206, the customer operating the web-enabled device visits the merchant's website and selects one or more products to purchase, such as by "dropping" the products in an electronic shopping cart. The customer then initiates the site's checkout process by activating the appropriate button displayed on the merchant page 1 (eg, "Checkout" button 108). In response, a set of operations corresponding to blocks 208, 210, 212, and 214 are performed almost immediately and in a manner transparent to the customer.

First, in block 208, the customer (ie, the browser on the customer's device) is directed to the merchant page 1.3, which includes a blank page (as far as visible content is concerned). Merchant page 1.3 is embedded with code to redirect the device's browser to page 1.6 hosted by the payment service. During this operation, information identifying the merchant (eg, a merchant ID) is passed from the merchant's web server to the service's server. For example, in one embodiment, the browser is redirected to the server of the service with a URL having the following format:

https://<service_web_address>/cgi-bin/webscr? cmd=_user-check&MID=x@Y.com&URL=http://www.Y.com/cgi-bin/checkoutpg2

Where <service_web_address> is the address of the payment service's homepage and "MID" is the merchant ID to and from the payment service, which in the current example includes the merchant's primary email address (X@Y.com). "URL" is the return URL of the web page to which the patron user will be redirected.

In block 210, upon receiving the merchant ID, the service server checks its user profile data to verify that the merchant is allowed to use the API. In one embodiment, the data embedded in the aforementioned URL format provides a built-in security measure where the MID and URL values are checked against the merchant's user profile to authenticate the request. Therefore, if the merchant decides to rename its "Page 2" URL, the merchant will need to update the corresponding URL entered in the user profile described above with reference to block 202 and FIG. 3 . If the merchant is not permitted to use the API, an indicator is sent back to the merchant server via the reply discussed below to indicate this.

Once it is verified that the merchant is allowed to use the API, a CGI (Common Gateway Interface) command (script) is executed on the server of the service to interpret the customer's service cookie. In conjunction with the redirection to the service URL described above, the browser on the customer's device automatically forwards a copy of the cookie back to the service server. This is a process that is done automatically by modern browsers that support cookies in response to being directed to the website that issued the cookie, and does not require any client (ie, customer device) side modifications. Essentially, a cookie is nothing more than a bunch of text that a web server sends to a client (such as a browser running on a customer's device) to be stored on the client for later use. Each cookie contains information including name-value pairs that can be used by the website that issued the cookie to convey information to the site during subsequent interactions with the site, without requiring the user to complete any action. Typically such information includes user IDs and the like.

Based on the merchant's return URL, the CGI command redirects the browser back to the merchant's web server and back to merchant page 2, which begins the enhanced checkout process. In conjunction with this, a reply is passed to the server (eg embedded as a variable in the pre-formatted URL in one embodiment) indicating whether the customer is authorized to use the payment service. In one embodiment, the respective reply variable values are also used to indicate that authentication failed and that the cookie could not be interpreted.

The merchant server extracts the response variable passed from the service page 1.6, and dynamically changes the flow of the checkout process starting from the merchant page 2. For example, if no cookie is received from the customer's device, the customer is not authorized to use the payment service. Accordingly, the reply will indicate this, and the portion of the checkout process that begins with Merchant Page 2 will continue with the checkout process without offering the customer the option to pay via the payment service. Conversely, if the reply indicates that the customer is an authorized user, Merchant Page 2 will lead to one or more subsequent pages (not shown) that will enable the user to pay for the purchase via the payment service. Typically, these pages will be coded by the merchant to fit the particular checkout process preferred by the merchant. In general, the checkout process will perform background interactions with the payment service to complete the payment transaction in response to the customer authorizing payment for a product using the payment service. Further details of this process are known in the art and thus not disclosed here.

The foregoing schemes provide an efficient mechanism for enabling e-commerce merchants to offer payment for purchases via third-party payment services. This is beneficial to both merchants and customers. For most payment service transactions, the fees associated with credit card transaction fees are eliminated. Similar to credit cards, payments issued by payment services are trusted. Customers also enjoy the benefit of being able to purchase products online in a secure manner that does not require the disclosure of credit card information or even require the customer to have a credit card.

typical server computer system

Referring to Figure 4, there is shown a generally conventional computer server 400 suitable for use in connection with implementing the embodiments of the invention described above. For example, the computer server 400 can be used to run software modules and components on the merchant's web server and service server to implement the operations in the flowchart above. Examples of computer systems suitable for these purposes include stand-alone servers and enterprise servers operating UNIX-based and LINUX-based operating systems, and servers running Windows NT or Windows 2000 Server operating systems.

As is generally known to those skilled in the art, computer server 400 includes a chassis 402 into which is mounted a motherboard 404 populated with appropriate integrated circuits, including one or more processors 406 and memory (e.g., DIMMs or SIMMs) 408 . A monitor 408 is included for displaying graphics and text generated by software programs and program modules run by the computer server. A mouse 412 (or other pointing device) can be connected to a serial port (or bus port or USB port) on the rear of the chassis 402, and signals from the mouse 412 are sent to the motherboard to control the cursor on the display and select Software programs and modules executing on the monitor 410 display text, menu options, and graphical components on the monitor 410. Additionally, a keyboard 414 is coupled to the motherboard for user input of text and commands that affect the operation of software programs executing on the computer. Computer server 400 also includes a network interface card (NIC) 416 or equivalent built into the motherboard to enable the server to send and receive data over a network 418 such as the Internet to enable the server to connect to the World Wide Web.

The text system storage device used to store data on the server side, such as user configuration information, electronic directories, CGI scripts, etc., can be implemented via a plurality of hard disks 420 stored inside the chassis 402, and/or stored in an external disk array 422 Implemented with multiple hard drives in an external disk array accessible via a SCSI card 424 built into the motherboard or equivalent SCSI circuitry. Optionally, disk array 422 is accessible via a Fiber Channel link by utilizing an appropriate Fiber Channel interface card (not shown) or built-in circuitry. Other hard disk interfaces can also be used.

Computer server 400 may generally include a compact disc read-only memory (CD-ROM) drive 426 into which a CD-ROM disc may be inserted so that executable files and data on the disc may be read for is transferred to memory 408 and/or to a storage device on hard disk 420 . Other mass storage devices, such as optical recording media or DVD drives, may also be included. Machine instructions, including software components that cause processor 406 to implement the operations of the above-discussed embodiments, will typically be distributed on floppy disk 430 or CD-ROM 432 (or other storage medium) and stored on one or more hard disks 420 until loaded into memory 408 for execution by processor 406 . Optionally, the machine instructions may be loaded via network 418 as a carrier file.

Thus, embodiments of the present invention may be used as, or in support of, a software program that is executed on some form of processing core (such as a CPU or computer) or that is stored on or in a machine-readable medium implemented or realized in other ways. A machine-readable medium includes any medium for storing or transmitting information in a form readable by a machine (eg, a computer). For example, a machine-readable medium may include, for example, read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; Additionally, a machine-readable medium may include a propagated signal, such as an electrical, optical, acoustic, or other form of propagated signal (eg, carrier wave, infrared signal, digital signal, etc.).

The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are disclosed herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.

These modifications can be made to the invention in light of the above detailed description. The terms used in the appended claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and claims. Rather, the scope of the invention is to be determined solely by the appended claims, which are to be construed in accordance with established doctrines of claim interpretation.

Claims (29)

1. A method comprising: receiving a checkout request from a customer user of the electronic storefront to purchase one or more products from the electronic storefront; determining whether the customer user is authorized to use the payment service to make purchases from the electronic storefront; providing a web-based checkout interface to a browser client used by the customer user, the checkout interface including an option that enables the customer user to use the payment service via The payment service makes payment for the one or more products. 2. The method of claim 1, further comprising: sending a service cookie from the payment service to the browser client containing information identifying the patron client; passing the service cookie to the payment service via the browser client in response to a prompt from the electronic storefront; and The patron user is identified via the service cookie. 3. The method of claim 1, further comprising authenticating the electronic storefront to the payment service. 4. The method of claim 3, wherein the electronic storefront is authenticated by: selecting a merchant identity (ID) for the electronic storefront to use for transactions involving the payment service; providing a merchant ID from the electronic storefront to the payment service; and The provided merchant ID is compared to the merchant ID selected to authenticate the user. 5. The method of claim 4, wherein the merchant ID is provided to the payment service via a URL (Uniform Resource Locator). 6. The method of claim 1, further comprising generating the web-based checkout interface by employing an application programming interface (API) provided by the payment service to the electronic storefront. 7. The method of claim 1 , further comprising providing a web-based checkout interface to the browser client if it is determined that the user is not authorized to use the payment service to make a purchase from the electronic storefront, The interface does not include an option to enable the customer user to make payment for the one or more products via the payment service. 8. The method of claim 1, wherein determining whether the customer user is authorized to use the payment service to make purchases from an electronic storefront is performed in a manner transparent to the customer user. 9. The method of claim 1, further comprising: providing a first web page via the electronic storefront, the first web page including visible content including checkout options; providing a second web page via the electronic storefront, the second web page containing hidden content including information redirecting the browser client to a web page hosted by the payment service website, the redirecting to the web page causing The browser client returns the service cookie stored by the browser client to the payment service website; Extract user identification information from the service cookie to determine the identity of the customer user; determining whether the customer user is authorized to use the payment service by checking the corresponding user profile information; and The client browser is redirected to a third web page hosted by the electronic storefront. 10. The method of claim 9, further comprising: storing at the payment service website information identifying a return URL (Uniform Resource Locator) corresponding to the third web page; extracting a return URL embedded in the message to redirect the browser client to a web page hosted by the payment service website; and The extracted return URL is compared with the return URL corresponding to the third web page to determine whether redirection to the third web page should be performed. 11. The method of claim 10, further comprising embedding information indicating whether the user is authorized to use the payment service in the URL of the third web page. 12. The method of claim 10, further comprising providing an interface enabling an administrator of the electronic storefront to register one or more return URLs with the payment service. 13. A method comprising: Provide a webpage hosted by an electronic storefront website that includes a checkout option; Responsive to the customer user activating the checkout option, redirecting the browser from the web page to the payment service website; sending information identifying a merchant hosting the electronic storefront from the electronic storefront website to the payment service website; processing information received at the electronic storefront website from the payment service website indicating whether the customer user is authorized to purchase products offered by the electronic storefront with payment via the payment service; and providing one or more web pages for the customer-user to provide a checkout process, if the customer-user is authorized to utilize the payment service to purchase a product, the one or more web pages include using the payment service to complete a checkout process corresponding to the Purchased options for the checkout process. 14. The method of claim 13, wherein the browser is redirected to the payment service website and information identifying the merchant is sent by: Generate a URL (Uniform Resource Locator) containing the embedded merchant identifier; and The URL is sent to the browser. 15. The method of claim 14 , further comprising embedding a return URL within a URL for redirecting the browser to the payment service website, the return URL for redirecting the browser to The first page in the checkout flow. 16. The method of claim 13, further comprising incorporating an Application Programming Interface (API) provided by the payment service to facilitate transactions with the payment service. 17. A method comprising: extracting a merchant identifier (ID) corresponding to the operator of the electronic storefront from the URL (Uniform Resource Locator) used to direct the browser to the payment service website; authenticating the merchant's use of the payment service based on the extracted merchant identifier; and If the merchant is authenticated, generating a return URL for redirecting the browser to the first web page in a checkout process hosted by the electronic storefront, the checkout process comprising transferring information from the Option to purchase product on electronic storefront. 18. The method of claim 17, further comprising: Issue a service cookie to registered users of said payment service; sending information to said browser to retrieve a service cookie stored on a client that hosts said browser, said client being operated by a customer user of said electronic storefront; receive a serving cookie from said browser; and Determining whether the patron user is authorized to use the payment service is based on information contained in the service cookie. 19. The method of claim 17, further comprising: extract the return URL embedded in the URL used to direct the browser to the payment service website; and It is determined whether the extracted return URL matches a return URL that the merchant has registered with the payment service. 20. The method of claim 19, further comprising: A web-based interface is generated to enable an administrator of the merchant to register one or more return URLs with the payment service. 21. A machine-readable medium for providing instructions that, when executed, perform the following operations: redirecting the browser from the electronic storefront website to the payment service website in response to the customer user activating a checkout option; sending information identifying a merchant hosting the electronic storefront from the electronic storefront website to the payment service website; processing information received at the electronic storefront website from the payment service website indicating whether the customer user is authorized to purchase products offered by the electronic storefront with payment via a third party service; and selecting a checkout flow comprising one or more web pages to provide to the browser, the selected checkout flow including an option to make a purchase with the payment service if the customer-user is authorized to use the payment service, otherwise selected The checkout process does not include the option to make purchases with said payment service. 22. The machine-readable medium of claim 21 , further providing instructions for: embedding in a URL (Uniform Resource Locator) for redirecting the browser to the payment service website Merchant identifier. 23. The machine-readable medium of claim 22, further providing instructions embodied as an application programming interface (API) used by an electronic storefront to effectuate a transaction with the payment service. 24. The machine-readable medium of claim 21 , further providing instructions for: embedding a return URL (Uniform Resource Locator) within a URL for redirecting the browser to the payment service website character), the return URL is used to redirect the browser to a web page that includes or does not include the option to make a purchase using the payment service. 25. A machine-readable medium for providing instructions that, when executed, perform the following operations: extracting a merchant identifier (ID) corresponding to the operator of the electronic storefront from the URL (Uniform Resource Locator) used to direct the browser to the payment service website; authenticating the merchant's use of the payment service based on the extracted merchant identifier; and If the merchant is authenticated, a return URL is generated to redirect the browser to a checkout page hosted by the electronic storefront. 26. The machine-readable medium of claim 25, further providing instructions for: receiving a service cookie from a customer user of the electronic storefront; Determining whether the patron user is authorized to use the payment service is based on information contained in the service cookie. 27. The machine-readable medium of claim 25, further providing instructions for: extract the return URL embedded in the URL used to direct the browser to the payment service website; and It is determined whether the extracted return URL matches a return URL that the merchant has registered with the payment service. 28. The machine-readable medium of claim 25, further providing instructions for: A web-based interface is generated to enable an administrator of the merchant to register one or more return URLs with the payment service. 29. The machine-readable medium of claim 25, wherein at least a portion of the instructions are embodied as a Common Gateway Interface (CGI) script.