Abstract:
A system receives a request for value from a user. The risk involved in providing the value to the user is evaluated using information accessible to the transaction system, the information includes contact information associated with the user. The request is selectively approved based on evaluating the risk involved and value is distributed to the user via a network. The contact information may comprise address information associated with the user, such as a residential street address of the user, a city of residence of the user, a state of residence of the user, a zip code of residence of the user, a telephone number associated with the user, and checking account information.

Description:
RELATED APPLICATIONS 
       [0001]    The present application is a continuation of U.S. patent application Ser. No. 13/569,883, filed Aug. 8, 2012, which is a continuation of U.S. patent application Ser. No. 12/397,244, filed Mar. 3, 2009, now U.S. Pat. No. 8,255,325, which is a continuation of U.S. patent application Ser. No. 11/332,068 filed Jan. 13, 2006, now U.S. Pat. No. 7,899,712, which is a continuation of U.S. patent application Ser. No. 09/577,434, filed May 22, 2000, now U.S. Pat. No. 7,499,875, which claims the benefit of the filing date of U.S. Prov. Pat. App. Ser. No. 60/190,420, filed Mar. 17, 2000, the applications of which are incorporated herein by reference in their entirety. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The present invention relates generally to the field of e-commerce and, more specifically, to facilitating online payment transactions in a network-based transaction facility using multiple payment instructions. 
       BACKGROUND OF THE INVENTION 
       [0003]    For users of a network-based transaction facility, a reliable and convenient payment mechanism is particularly important for enhancing user trust in the transaction facility. A typical network-based transaction facility, however, does not ensure the expedient and secure completion of payment transactions. Instead, payment transactions between traders of an online trading community are typically conducted in a conventional, time-consuming manner using paper checks and money orders. Accordingly, such payment transactions delay payments to sellers and delivery of purchased goods to buyers. In addition, sellers are expected to bear the risk of bounced checks and buyers are running the risk of not receiving the goods after sending the money. 
         [0004]    The above problems are typically faced by individuals or small businesses who cannot afford to build or buy the infrastructure to accept credit card payments from buyers in the network-based transaction facility. However, even a seller who does accept credit card payments can still lose those buyers who appreciate the convenience of online payments but do not have access to credit cards. In addition, a buyer may prefer not to disclose his or her credit card information over the Internet in general, or to a certain seller in particular. Further, credit card payments may not always be desirable for sellers because of their charge back recourse to buyers. 
         [0005]    Therefore, it will be advantageous to provide traders with an efficient and secure mechanism for facilitating online payment transactions via a variety of payment instruments. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0006]    The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: 
           [0007]      FIG. 1  is a block diagram of one embodiment of a system for processing online payment transactions between participants in a network-based transaction facility; 
           [0008]      FIG. 2  is a block diagram of one embodiment of a network-based transaction facility; 
           [0009]      FIG. 3  is a block diagram of one embodiment of an online payment service; 
           [0010]      FIG. 4  is a block diagram of an exemplary online payment service supporting multiple data centers; 
           [0011]      FIG. 5  is a flow chart of an exemplary method for facilitating online payment transactions using multiple payment instruments; 
           [0012]      FIG. 6  is a block diagram of one embodiment of a database maintained by an online payment service; 
           [0013]      FIG. 7  is a block diagram of one embodiment of a process flow for evaluating risks involved in an online payment transaction; 
           [0014]      FIG. 8  is a block diagram of one embodiment of an interface sequence implemented to facilitate online payment transactions through multiple payment instruments; 
           [0015]      FIG. 9  is a flow chart of an exemplary method for facilitating online payment transactions through multiple payment instruments using risk analysis; 
           [0016]      FIGS. 10-19  are exemplary representations of various interfaces included in the sequence of interfaces shown in  FIG. 8 ; and 
           [0017]      FIG. 20  is a block diagram of one embodiment of a computer system.  FIG. 1  shows a system for targeted commerce in network broadcasting, according to some embodiments. 
       
    
    
     DETAILED DESCRIPTION 
       [0018]    A method and apparatus for facilitating online payment transactions in a network-based transaction facility using various payment instruments are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details. 
       System for Processing Online Payment Transactions 
       [0019]      FIG. 1  is a block diagram of one embodiment of a system for processing online payment transactions between participants in a network-based transaction facility. In this embodiment, a client  100  is coupled to a transaction facility  130  via a communications network, including a wide area network  110  such as, for example, the Internet. Other examples of networks that the client may utilize to access the transaction facility  130  include a local area network (LAN), a wireless network (e.g., a cellular network), or the Plain Old Telephone Service (POTS) network. 
         [0020]    The client  100  represents a device that allows a user to participate in a transaction facility  130 . The transaction facility  130  handles all transactions between various participants including the user of the client computer  100 . In one embodiment, the transaction facility  130  may be an online auction facility represented by an auction web site visited by various participants including the user of the client computer  100 . An exemplary auction facility is described in greater detail in conjunction with  FIG. 2 . Alternatively, the transaction facility  130  may be an online retailer or wholesaler facility represented by a retailer or wholesaler web site visited by various buyers including the user of the client computer  100 . In yet other embodiments, the transactions facility  130  may be any other online environment used by a participant to conduct business transactions. 
         [0021]    The transaction facility  130  is coupled to an online payment service  120 . In one embodiment, the transaction facility  130  is coupled to the online payment service  120  via a communications network such as, for example, an internal network, the wide area network  110 , a wireless network (e.g., a cellular network), or the Plain Old Telephone Service (POTS) network. Alternatively, the online payment service  120  is integrated with the transaction facility  130  and it is a part of the transaction facility  130 . The online payment service  120  is also coupled to the client  100  via any of the described above communications networks. The online payment service  120  is a service for enabling online payment transactions between participants of the transaction facility  130 , including the user of the client computer  100 . 
         [0022]    In one embodiment, the online payments service  120  enables the participants to make online payments in the course of business conducted in the transaction facility  130  using multiple payment instructions. These payment instructions may include, for example, credit cards, debit cards, wire transfers, electronic funds transfers (EFT), transfers from internal accounts within the transaction facility  130  or the online payment service  120 , loan financing, lines of credit, coupon or gift certificates, etc. In this embodiment, the transaction facility  130  facilitates business transaction between the user of the client  110  and other participants. The client  110  presents user interface information to the user. The user interface information identifies multiple payment instruments available for processing payment transactions pertaining to corresponding business transactions. 
         [0023]    In one embodiment, the user selects one or more payments instruments from the available payments instruments. The client  110  then communicates payment option information of the user to the transaction facility  130 . The payment option information indicates the willingness of the user to accept payments from other participants via the selected payment instruments. The online payment service  120  receives the payment option information from the transaction facility  130 , communicates the payment option information to a participant conducting business with the user, and enables the participant to choose a preferred instrument from the payment instruments selected by the user. The online payment service  120  then accepts personal billing information concerning the preferred payment instrument from the participant to facilitate the payment transaction between the participant and the user. 
       Transaction Facility 
       [0024]      FIG. 2  is a block diagram illustrating an exemplary network-based transaction facility in the form of an Internet-based auction facility  200 . While an exemplary embodiment of the present invention is described within the context of an auction facility, it will be appreciated by those skilled in the art that the invention will find application in many different types of computer-based, and network-based, commerce facilities. 
         [0025]    The auction facility  200  includes one or more of a number of types of front-end servers, namely page servers  212  that deliver web pages (e markup language documents), picture servers  214  that dynamically deliver images to be displayed within Web pages, listing servers  216 , CGI servers  218  that provide an intelligent interface to the back-end of facility  210 , and search servers  220  that handle search requests to the facility  10 . E-mail servers  221  provide, inter aria, automated e-mail communications to users of the facility  200 . 
         [0026]    The back-end servers include a database engine server  222 , a search index server  224  and a credit card database server  226 , each of which maintains and facilitates access to a respective database. 
         [0027]    The Internet-based auction facility  200  may be accessed by a client program, such as a browser (e.g., the Internet Explorer distributed by Microsoft Corp. of Redmond, Wash.) that executes on the client computer  100  and accesses the facility  200  via the communications network  110 . 
       Online Payment Service 
       [0028]      FIG. 3  is a block diagram of one embodiment of an online payment service  120 . The online payment service  120  includes a firewall  300 , one or more web servers  310 , a firewall  315 , a set of application servers  320 , and one or more databases  330 . The firewall  300  isolates the online payment service  120  from external Internet accesses. The firewall  310  enhances security within the online payment service  120  by preventing internal access to information stored in the database  330 . The only access permitted to the database is from applications servers  320 , making valid database requests. 
         [0029]    The web servers  310  facilitate the exchange of information between the online payment service  120 , the transaction facility  130  and the participants of the transaction facility  130 , including the user of the client  100 . In one embodiment, the web servers  310  encrypt data outgoing from the online payment service  120  using a secure protocol (e.g., a secure socket layer (SSL) protocol, a secure HTTP protocol, etc.). In one embodiment, a digital signature mechanism is implemented to prevent tampering of data prior to the encryption stage. 
         [0030]    The application servers  320  handle various tasks executed within the online payment service  120 . Each application server  320  is responsible for a certain pre-assigned task. These tasks may include, for example, executing payment transactions, registering participant accounts, maintaining account statuses for each user, providing customer service, delivering emails, providing analysis (e.g., risk analysis) and reporting, processing electronic fund transfers EFTs, and other application services. The applications servers  320  access the database  330  to enter or retrieve various data. The database  330  is described in greater detail below in conjunction with  FIG. 6 . 
         [0031]    In one embodiment, the online payment service  120  is coupled, via a network, to multiple external payment processors to complete various types of online payment transactions. For example, the online payment service  120  may be coupled to a credit card processor to process credit card payments. The online payment service is  120  may also by coupled to an EFT processor to process electronic checks and money order payments. Other external payment processor may include, for example, a wire transfer processor, a loan financing processor, a line of credit processor, a coupon or gift certificate processor, etc. 
         [0032]      FIG. 6  is a database diagram illustrating an exemplary database  600  supported by the online payment service  120 . The database  600  may, in one embodiment, be implemented as a relational database, and includes a number of tables having entries, or records, that are linked by indices and keys. In an alternative embodiment, the database  600  may be implemented as collection of objects in an object-oriented database. 
         [0033]    Central to the database  600  is a user table  610 , which contains a record for each user of the online payment service  120 . A user may operate as a seller, buyer, or both, within the transaction facility  130 . A seller table  620  is linked to the user table  610  and includes more detailed information about each seller. A buyer table  630  which is also linked to the user table  410  includes detailed information about each buyer. The database  600  also includes payment instruments tables  670  that may be linked to the user table  610 . Each payment instrument table  670  pertains to an individual payment instrument available for use in the transaction facility  130 . Available payment instruments may include, for example, credit cards, debit cards, automated clearing house (ACH) transfers using electronic checks and money orders, wire transfers, transfers from an internal account within the online payment service  120  or the transaction facility  130 , loan financing, lines of credit, coupons or gift certificates, etc. Each payment instrument table  670  includes corresponding billing information provided by a user. A user record in the user table  610  may be linked to a payment instrument record in multiple payment instrument tables  670  if the user provides billing information on more than one payment instrument. 
         [0034]    The database  600  also includes a payment transaction table  640  which is linked to the seller table  620  and the buyer table  630 . The payment transaction table  640  contains information on each financial exchange between a buyer and a seller. A payment transaction in the transaction table  640  may be represented by one or more accounting records in an accounting record table  650 . The accounting records support an accounting system of the online payment service  120  and contain various accounting information, such as, for example, information on debits and credits to buyers, sellers, the online payment service, or other third parties participating in payment transaction. A payment transaction that does not correspond to any accounting record may indicate that the transaction was not completed successfully (e.g., the buyer&#39;s credit card was invalid). 
         [0035]    A ledger table  660  is linked to the accounting record table  650 , the user table  610  and the payment instrument tables  670 . A ledger record contains information on an actual fund transfer between a user and the online payment service  120 . The funds transfer may be a debit (e.g., a charge to a buyer&#39;s credit card) or a credit (e.g., a disbursement to a seller&#39;s checking account). The funds transfer is conducted through a particular payment instrument selected by the buyer and seller and approved by the online payment service  120  in a manner described in more detail below. 
         [0036]    One embodiment of an architecture of the online payment service  120  will now be described in more detail. In this embodiment, the online payment service  120  supports a large number of buyers and sellers who are distributed across the globe, executing transactions at any time of day and night. In order to provide stable physical environment and reliable application architecture, online payment service clusters are installed at several different geographical locations. If a single data center location goes down, transaction volume can be processed by clusters at the remaining locations. Each cluster, in turn, may consist of multiple machines with redundant service. 
         [0037]      FIG. 4  is a block diagram of an exemplary online payment service  120  supporting multiple data centers. In this embodiment, clusters  400 ,  410  and  420  reside in different data centers. The same web servers  310  and application servers  320  are included in both clusters  400  and  410 . The application servers  320  of the clusters  400  and  410  perform transaction management functions, such as, for example, transaction execution, account registration, account status, customer service, e-mail delivery, etc. In one embodiment, in each of the clusters  400  and  410 , multiple instances of every application server run in parallel to balance the system load between the different functions. Application servers can be installed on different physical machines to increase reliability of the system. In one embodiment, each of the clusters  400  and  410  has external connections with one or more payment processors (e.g., a credit card processor, an EFT processor, a wire transfer processor, etc.). 
         [0038]    In one embodiment, each of the clusters  400  and  410  includes a production database  330 . Shared data (e.g., buyer and seller profile information) in the production database  330  may be dynamically replicated to both data centers. Transaction data (e.g., current account statement information) may not need to be replicated as it can be constructed in a variety of other ways using the production data. For example, upon a user request for an online account statement, a query (e.g., an SQL query) may be run to build a complete transaction record. 
         [0039]    In one embodiment, analysis and reporting functions may be separated from the transaction activity because these functions are time consuming That is, analysis and reporting functions may be executed by the warehouse cluster  420  located separately from the clusters  400  and  410 . The analysis and reporting functions may include, for example, risk or fraud analysis, standard reporting, online analytical processing (OLAP) providing database indexing to enhance quick access to data EFT processing, etc. The analysis and reporting functions may be carried out against a separate data warehouse system, such as a data warehouse  450 . Data pertaining to the analysis and reporting may be extracted from the production database  330  at predefined time intervals and stored in the data warehouse  450 . As a result, user transaction activity is not impacted by execution of time-consuming analysis and reporting functions. 
       Multiple Payment Instruments 
       [0040]    In order to provide participants of the transaction facility  130  with an effective and secure mechanism of conducting online payment transactions, one embodiment of the present invention proposes a method and system whereby the participants may conveniently use multiple payment instruments to make online payments for products obtained in the course of their commercial activity in the transaction facility  130 . 
         [0041]      FIG. 5  is a flow chart illustrating an exemplary method  500  of facilitating online payment transactions using multiple payment instruments. The method  500  may be performed by processing logic, which may comprise hardware, software, or a combination of both. The processing logic may be either in the online payment service  120 , or partially or entirely in a separate device and/or system(s). 
         [0042]    Referring to  FIG. 5 , the method  500  begins with the online payment service  120  communicating user interface information to a first participant via a communications network (processing block  506 ). The user interface information identifies multiple payment instruments available for processing payment transactions in the transaction facility  130 . 
         [0043]    At processing block  508 , processing logic in the online payment service  120  receives payment option information from the first participant via the communications network. The payment option information indicates a willingness of the first participant to accept payments from a second participant through one or more available payment instruments. As described above, available payment instruments may include, for example, credit cards, debit cards, wire transfers, electronic checks and money orders. In addition, the online payment service  120  may permit payments through direct transfers from an internal account which is maintained for a participant within the transaction facility  130  or the online payment service  120 . 
         [0044]    In one embodiment, payment instruments may also include loan financing and lines of credit. In this embodiment, the online payment service  120  may cooperate with a third party processor (e.g., a financial institution) to process loan financing and to create or extend a line of credit for a participant. Other payment instruments may include coupons and gift certificates, or any other U.S. or international vehicles. In the cases of coupons and gift certificates, the online payment service  120  (in cooperation with a third party or internally) determines whether a coupon or a gift certificate is valid. 
         [0045]    Next, processing logic in the online payment service  120  passes the payment option information to the second participant via the communications network (processing block  510 ). Afterwards, at processing block  512 , processing logic in the online payment service accepts personal billing information of the second participant to facilitate a payment transaction between the first participant and the second participant. The personal billing information transferred over the communications network pertains to a payment instrument selected by the second participant from the payment instruments specified by the first participant. 
         [0046]    In one embodiment, processing logic in the online payment system  120  communicates the personal billing information of the second participant, via the communications network, to a financial institution to process the payment transaction. Alternatively, the personal billing information may be processed internally (e.g., when a payment is made using a direct transfer from an internal account within the online payment system  120  or the transaction facility  130 ). Afterwards, when the payment transaction completes, the first participant is notified. In one embodiment, notification may be sent immediately after accepting the personal billing information (e.g., when a payment is made using a credit card). Alternatively, notification is sent after a certain time period expires (e.g., when a payment is made using an electronic check). 
         [0047]    In one embodiment, at various stages of the payment transaction between the first participant and the second participant, risk involved in the payment transactions is evaluated by a risk analysis system of the online payment system  120 . The various stages may include, for example, the time the payment transaction is initiated, the time either the first or second participant registers with the online payment service  120 , the time the first participant provides invoice information, the time the second participant provides personal billing information pertaining to a particular payment instrument, the time funds are disbursed to the first participant, etc. Based on the involved risk, the payment transaction between the first and second participants may be interrupted or restricted (e.g., preventing a participant from accepting or paying with a certain payment instrument). The risk analysis system is described in greater detail below in conjunction with  FIG. 7 . 
         [0048]    In one embodiment, processing logic in the online payment service  120  accepts multiple payments owed to the first participants by other participants in the course of business transactions conducted by the first participant in the transaction facility  130 . The multiple payments are accepted via the communications network and may be made using various payment instruments. Next, processing logic in the online payment service  120  accumulates these payments over a period of time and then distributes a single disbursement which includes the accumulated payments to the first participant. 
         [0049]    In one embodiment, the online payment service  120  accepts a payment from the second participant in one currency and distributes the payment to the first participant in different currency. The above online payment options address time-consuming and unreliable paper-based payment methods and provide an efficient and secure mechanism to conduct payment transactions within the transaction facility  130 . 
         [0050]      FIG. 7  is a block diagram of one embodiment of a process flow for evaluating risks involved in an online payment transaction. As described above, the involved risks are evaluated at various stages of the payment transaction. The involved risks may concern, for example, a buyer&#39;s ability to pay, a likelihood that a buyer or a seller may be fraudulent (e.g., a buyer uses a stolen credit card, or a seller lists goods for sale online with no intent or ability to deliver the purchased goods), a seller&#39;s ability to fulfill purchase orders promptly, etc. Based on the risk evaluation, the online payment service  120  may reject or restrict a payment transaction between a buyer and a seller in a manner described below. In one embodiment, the risk evaluation is performed in real time and enables an uninterrupted processing of the payment transaction. 
         [0051]    In one embodiment, the online payment service  120  contains a payment processing system  710  and a risk management system  720 . The payment processing system  710  is responsible for executing payment transactions. Specifically, the payment processing system  710  receives information from the transaction facility, stores some or all of this information for historical purposes in a local database (i.e., a payment transaction data store  730 ), and determines what information to pass to the risk management system  720 . The risk management system  720  utilizes this information to deter nine a risk level involved in the payment transaction. In one embodiment, the risk management system  720  may also use input from one or more third party risk analysis providers  740  to evaluate the risk level of the payment transaction. The results of the evaluation are passed back to the payment processing system  710  which continues processing the payment transaction based on the evaluation results. 
         [0052]    In one embodiment, payment transactions are initiated in the transaction facility  130 . The transaction facility  130  passes a variety of information concerning a payment transaction and its participants (a buyer and a seller) to the payment processing system  710 . The payment transaction information may include, for example, a payment transaction amount, currency in which the payment transaction is to be conducted, description of the goods or services being exchanged, etc. The participant information may include, for example, identifying information of both a buyer and a seller (e.g., names, identification codes, contact information) and information pertaining to their business participation in the transaction facility  130 . For instance, the transaction facility  130  may pass to the payment processing system  710  information on how long both the buyer and the seller have been registered with the transaction facility  130 , their historical business activity within the transaction facility  130  (e.g., number of prior transactions, gross sales, average amount of a sale), user classification schemes and peer rating schemes used in the transaction facility  130  (e.g. user feedback ratings), third party trust ratings carried out by the transaction facility  130  (e.g. credit reports), etc. It should be noted that a wide variety of information other than the information described above may be passed to the payment processing system  710  from the transaction facility  130  for evaluating potential risk involved in the payment transaction. 
         [0053]    In another embodiment, the payment processing system  710  itself may initiate a payment transaction (e.g., if the payment processing system  710  is notified that a buyer and a seller agreed that a payment would take place on a future date). In this embodiment, the payment processing system  710  then requests relevant information (including any or all of the above information) from the transaction facility  130 . 
         [0054]    The payment processing system  710  passes any or all of the above information to the risk management system  720 . In addition, the payment processing system  710  may pass certain internal transaction data (e.g., response codes from a credit card processor) to the risk management system  720 . The risk management system  720  uses the above information to determine the risk level of the payment transaction. In addition, the risk management system  720  may include in its analysis data stored in the payment transaction data store  730  (e.g. historical transaction activity of the seller and the buyer) and information collected by system operation staff related to either the buyer or the seller (e.g., customer service responses, “blacklists” identifying fraudulent customers, etc.). 
         [0055]    In one embodiment, the risk management system  720  also includes in its analysis external risk analysis results. In this embodiment, the risk management system  720  may request one or more third party risk analysis providers  740  to provide an additional evaluation of the risk involved in the payment transaction. For instance, a financial institution may provide additional levels of screening to identify potentially fraudulent participants. The risk management system  720  may transmit to the third party risk analysis providers  740  any or all of the information collected for the payment transaction. The third party risk analysis providers  740  analyze this information and information obtained from their own sources to determine a risk assessment for the payment transaction. The risk assessment information is then sent back to the risk management system  720 . 
         [0056]    Based on the information received from various external and internal sources, the risk management system  720  determines the risk level of the payment transaction using a scoring algorithm. It should be noted that any scoring algorithm known in the art may be used by the risk management system  720  without loss of generality. The risk management system  720  produces a consolidated risk response and passes it to the payment processing system  710 . The risk response may include, for example, information indicating that service should be denied to a participant due to high likelihood of fraud, information on a recommended service fee for processing the payment transaction, information on recommended restrictions on payment instruments to be used by either the buyer or the seller, information on recommended restrictions on disbursing funds to the seller, etc. 
         [0057]    The payment processing system  710  receives the risk response from the risk management system  720  and makes a final determination concerning the payment transaction. That is, the payment processing system  710  may reject the payment transaction (or deny service to either the buyer or the seller entirely), process the payment transaction without any changes, or restrict the timing and/or the manner in which the payment transaction is conducted. For example, the payment processing system  710  may limit payment instruments offered for use in the payment transaction, may assign or modify a fee for processing the payment transaction, may restrict the time or the manner in which funds are disbursed to the seller, etc. 
       User Interfaces 
       [0058]    Functions of the online payment service  120  pertaining to payments through multiple payment instruments will now be described within the context of user interfaces, according to one embodiment of the present invention.  FIG. 8  shows an interface sequence  800 , according to an exemplary embodiment of the present invention, that may be implemented by the transaction facility  130  and the online payment service  120  for the purposes of providing multiple online payment options to participants in the transaction facility  130 . Exemplary representations of the various interfaces included within the sequence  800  are shown in  FIGS. 10-19 . While exemplary interfaces are described within the context of an auction facility, it will be appreciated by those skilled in the art that they may be implemented in many different types of computer-based, and network-based, transaction facilities. 
         [0059]    The interface sequence  800  commences with a seller registration interface  802  through which a seller may specify what online payment instruments the seller will accept from various buyers. The seller registration interface  802  is generated by the transaction facility  130  and may be accessed at any time during a business transaction (e.g., during an auction) or upon an end of the business transaction (e.g., upon en and of auction). The seller needs to go through the seller registration interface  802  only once unless the seller wants to modify the payment instruments specified initially. 
         [0060]    Upon the end of the business transaction, an end of business transaction interface  804  is displayed by the transaction facility  130 . The end of business transaction interface  804  identifies a seller and a buyer and the payment instruments acceptable to the seller. If the payment transaction is initiated by the seller, the seller is then presented with a seller login interface  806  which allows the seller to login to the online payment service  120  by entering the seller&#39;s password. Subsequently, the seller is presented with an invoice form interface  808 . The invoice form interface  808  displays an explanation of the payment process and requests the seller to enter the invoice terms. 
         [0061]    After the seller confirms that the invoice terms are correct, the buyer receives an email with a link to a buyer login interface  810 . Alternatively, if the payment transaction is initiated by the buyer, the invoice is not generated and the buyer does not need to wait for the above email. Instead the buyer can directly access the buyer login interface  810  which enables the buyer to login to the online payment service  120 . 
         [0062]    Next, the buyer is presented with a payment option interface  812  which allows the buyer to select a particular payment instrument for use in this payment transaction. In addition, the payment option interface  812  enables the buyer to avoid entering the buyer&#39;s personal billing information in a personal billing information interface  814  if the buyer has previously registered with the online payment service  120 . If so, the buyer is presented with a revision of billing and shipping information interface  813  and then with an order placing interface  818 . By clicking a place order button on the order placing interface  818 , the buyer authorizes the online payment service to execute the payment transaction (e.g., charging the buyer&#39;s credit card, initiating an electronic funds transfer, etc.). Further, the buyer is presented with a confirmation interface  820  confirming that the buyer&#39;s purchase is complete. In case of an electronic funds transfer, the confirmation interface  820  notifies the buyer that the online payment service  120  has initiated the buyer&#39;s electronic check payment. 
         [0063]    If the buyer has not previously registered with the online payment service  120 , the buyer is presented with the personal billing information interface  814  which requests the buyer to enter billing information pertaining to the payment instrument selected by the buyer. Next, the buyer is presented with a shipping information interface  816  which requests the buyer to enter shipping information for this order and then with an order placing interface  818  and then with the confirmation interface  820 . Afterwards, the buyer is invited to register with the online payment service  120  using a buyer registration interface  822 . By registering, the buyer permits the online payment service  120  to store the buyer&#39;s personal billing information so that the buyer does not need to enter it every time the buyer pays for the goods through a corresponding payment instrument. The personal billing information of the buyer is kept confidential and is not communicated to the seller. 
         [0064]    The interfaces  802 - 820  will now be described within the context of a method  900 , according to one embodiment of the present invention, of facilitating payment transactions through multiple payment instruments using risk analysis. The method  900  is illustrated by the flow chart indicated in  FIG. 9 . The method  900  is performed by processing logic, which may comprise hardware, software, or a combination of both. The processing logic may be either in the online payment service  120 , or partially or entirely in a separate device and/or system(s). 
         [0065]    The method  900  commences with providing the seller registration interface  802  to the seller at block  904 . The seller registration interface presents to the seller available payment instruments that can be used for conducting payment transactions in the transaction facility  130 . 
         [0066]    At block  906 , processing logic in the online payment service  120  receives information on payment instruments selected by the seller from the list of available payment instruments. At block  908 , processing logic in the online payment option  120  determines whether the seller is qualified to use the payment instruments selected by the seller. This determination is performed using the risk management system  720  as described above in conjunction with  FIG. 7 . 
         [0067]    The method  900  continues with providing the end of business transaction interface  804  which specifies those payment instruments selected by the seller that were approved during the risk analysis process (block  910 ). Next, at decision box  912 , a determination is made as to whether an initiator of the payment transaction is the seller or the buyer. If the seller initiates the payment transaction, the seller is provided with the seller login interface  806  to enable the seller to login to the online payment service (block  914 ). At block  916 , the seller is presented with the invoice form interface  916 . 
         [0068]    Next, at block  918 , processing logic in the online payment service  120  receives invoice information entered by the seller through the invoice form interface  808  and then, at block  920 , determines whether the seller is qualified to submit the payment transaction described by the invoice information. That is, the risk management system  720  is used to evaluate a likelihood of the seller&#39;s ability to fulfill the purchase according to the invoice terms. If processing logic in the online payment service  120  determines that the seller is qualified to submit this payment transaction, the buyer is sent an e-mail which contains a link to begin payment. The link enables the buyer to access the buyer login interface  810  (block  922 ). 
         [0069]    Alternatively, if the initiator of the payment transaction is the buyer, the method  900  proceeds directly to block  922 , at which the buyer is presented with the buyer login interface  810 . The buyer login interface  810  includes information instructing the buyer to notify the seller (e.g., by e-mail using included e-mail template) about the buyer&#39;s willingness to conduct the payment transaction through one of the available payment instruments. 
         [0070]    Further, after the buyer successfully logs in to the online payment service  120 , at decision box  924 , a determination is made as to whether the buyer is registered with the online payment service  120 . If the buyer is not registered, the buyer is requested to specify a preferred payment method for this payment transaction through the payment option interface  810 . If the buyer initiated the payment transaction, the preferred payment method may be selected from multiple payment instruments available for conducting payment transactions in the transaction facility  130 . Alternatively, if the initiator of the payment transaction was the seller, the preferred payment method may be selected from the payment instruments approved in the qualification process described above. 
         [0071]    At decision box  928 , a determination is made as whether the buyer is qualified to use the preferred payment instrument using the risk evaluation process described above. If the buyer is not qualified to use this payment instrument, the method  900  returns to block  926 , at which the buyer is asked to select another payment instrument. Alternatively, if the buyer is qualified, at block  930 , the buyer&#39;s personal billing information pertaining to the preferred billing instrument is received from the buyer through the personal billing information interface  814 . Information included in the personal billing information interface  814  varies depending on the payment instrument selected by the buyer. In addition, the buyer may be requested to enter the buyer&#39;s shipping information through the shipping information interface  816 . 
         [0072]    Next, at block  934 , processing logic in the online payment service  120  processes the buyer&#39;s payment and generates the confirmation interface  820  notifying the buyer either that the purchase is complete (e.g., the payment is made through a credit card) or that the buyer&#39;s payment has been initiated (e.g., the payment is made through an electronic funds transfer). Further, the buyer is presented with the buyer registration interface  822  which enables the buyer to store the buyer&#39;s personal billing information and shipping information in an account maintained for the buyer by the online payment service  120 . The method  900  then proceeds to block  936 . 
         [0073]    In an alternate embodiment, in which the buyer is already registered with the online payment service  120 , the method  900  proceeds to block  927 , at which the buyer is invited to revise his or her billing and/or shipping information through the revision of billing and shipping information interface  813 . Then, the method  900  proceeds to block  934  and further to block  934 . 
         [0074]    At block  934 , processing logic in the online payment service  120  disburses funds to the seller. In one embodiment, multiple payments made by various buyers using the same or different payment instruments are accumulated on behalf of the seller over a certain period of time and then a single disbursement (in the amount equal to the accumulated payments minus an appropriate service fee) is distributed to the seller, in one embodiment, the time of disbursement, the manner of disbursement (e.g., a payment instrument to be used for disbursement) and the amount of the service fee are determined based on the risk evaluation process described above in conjunction with  FIG. 7 . 
         [0075]    Exemplary user interfaces will now be further described with reference to  FIGS. 10-19 . While the exemplary interfaces are described as comprising markup language documents displayed by a browser, it will be appreciated that the described interfaces could comprise user interfaces presented by any Windows™ client application or stand-alone application, and need not necessarily comprise markup language documents. In addition, it will be appreciated by those skilled in the art that, although the exemplary interfaces are described in the context of an auction facility, they may be implemented in a wide variety of different types of computer-based, and network-based, transaction facilities. 
         [0076]      FIG. 10  illustrates an exemplary seller registration interface  802  that enables the seller to specify various options concerning business transactions that are conducted in the environment of the transaction facility  130 . Some of the various options pertain to payment options, such as payment methods  1010  and online payments  1020 . The online payments  1020  specify multiple payment instruments. Although  FIG. 10  illustrates only credit card and electronic check payment instruments, the seller registration interface may identify a wide variety of other payment instruments as described above. Using one or more check boxes corresponding to the payment instruments (e.g. check box  1022  and  1024 ), the seller may specify what payment instruments he or she will accept in payment transactions with various buyers. 
         [0077]      FIG. 11  illustrates an exemplary end of business transaction interface  804  which in this example indicates the end of auction. The end of business transaction interface specifies payment instruments selected by the seller (e.g. a credit card  1110  and an electronic check  1120 ) and enables either the seller or the buyer to initiate the payment transaction by using a corresponding link (i.e., a seller link  1124  or a buyer link  1124 ). 
         [0078]      FIG. 12  is an exemplary seller login interface  806  which enables the seller to login to the online payment service  120  by providing the seller&#39;s password  1230 . The seller login interface  806  also includes links to explanations on how to use online payments (e.g., a link  1210  to an explanation for a first step of sending an invoice and a link  1220  to an explanation for a second step of shipping an item). 
         [0079]      FIG. 13  is an exemplary invoice form interface  808  which includes input fields for entering various invoice information (e.g., a final auction price  1330 , shipping insurance  1340 , sales tax  1350 , a message  1386 , and a return policy  1388 ). The invoice interface also specifies payment instruments  1380  that are acceptable for this transaction (e.g., credit card  1382  and electronic check  1384 ) and provides information on how the payment transaction will be processed. For example, if the buyer chooses to pay with a credit card, the seller will be notified that the payment is processed once the buyer&#39;s credit card information is received. If the buyer pays with an electronic check, the seller will be notified about the completion of the payment transaction after the expiration of a certain time period (e.g. in 3-5 days). 
         [0080]      FIG. 14  is an exemplary buyer login interface  810  which enables the buyer to login to the online payment service  120  by providing the buyer&#39;s user identifier  1414  and password  1416 . In addition, the buyer login interface  810  includes information indicating that the payment transaction must be either initiated by the seller  230  (text  1410 ) or the buyer (text  1412 ). 
         [0081]      FIG. 15  is an exemplary payment option interface  812  which includes invoice information  1510  and asks the buyer to select one of the online payment methods (e.g., a credit card  1530  or an electronic check  1540 ) by using either a “pay with credit card” button  1550  or a “pay with electronic check” button  1560 . The payment option interface also allows the buyer to pay in one step using a link  1520  if the buyer is registered with the online payment service  120 . 
         [0082]      FIG. 16  is an exemplary billing information interface  814  generated in response to a buyer request to pay with a credit card payment instrument. The interface  814  includes input fields  1620  pertaining to the buyer&#39;s credit card information. In addition, the interface  814  includes information indicating that the buyer&#39;s billing information is kept confidential and will not be disclosed to the seller. 
         [0083]      FIG. 17  is an exemplary billing information interface  814  generated in response to a buyer request to pay with an electronic check payment instrument. The interface  814  includes the buyer&#39;s checking account information including a bank name  1710 , a bank routing number  1720 , a checking account  1730 , and a buyer&#39;s name and a checking account address  1750 . In one embodiment, in order to prevent potential fraudulent activity, the interface  814  includes secondary form of identification input fields  1762 - 1768 . 
         [0084]      FIG. 18  is an exemplary buyer registration interface  822  including input fields  1810 - 1850  enabling the buyer to register with the online payment service  120  for storing his or her billing information in an account maintained by the online payment service  120 . 
         [0085]      FIG. 19  is an exemplary confirmation interface  820  notifying the user that the payment transaction has been initiated. 
         [0086]    In summary, it will be appreciated that the above described interfaces, and underlying technologies, provide a convenient vehicle for facilitating payment transactions in a transaction facility using multiple payment instruments. 
         [0087]      FIG. 20  shows a diagrammatic representation of machine in the exemplary form of a computer system  2000  within which a set of instructions, for causing the machine to perform any one of the methodologies discussed above, may be executed. In alternative embodiments, the machine may comprise a network router, a network switch, a network bridge, Personal Digital Assistant (PDA), a cellular telephone, a web appliance or any machine capable of executing a sequence of instructions that specify actions to be taken by that machine. 
         [0088]    The computer system  2000  includes a processor  2002 , a main memory  2004  and a static memory  2006 , which communicate with each other via a bus  2008 . The computer system  2000  may further include a video display unit  2010  (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system  2000  also includes an alpha-numeric input device  2012  (e.g., a keyboard), a cursor control device  2014  (e.g., a mouse), a disk drive unit  2016 , a signal generation device  2020  (e.g., a speaker) and a network interface device  2022 . 
         [0089]    The disk drive unit  2016  includes a computer-readable medium  2024  on which is stored a set of instructions (i.e., software)  2026  embodying any one, or all, of the methodologies described above. The software  2026  is also shown to reside, completely or at least partially, within the main memory  2004  and/or within the processor  2002 . The software  2026  may further be transmitted or received via the network interface device  2022 . For the purposes of this specification, the term “computer-readable medium” shall be taken to include any medium that is capable of storing or encoding a sequence of instructions for execution by the computer and that cause the computer to perform any one of the methodologies of the present invention. The term “computer-readable medium” shall accordingly be taken to included, but not be limited to, solid-state memories, optical and magnetic disks, and carrier wave signals. 
         [0090]    Thus, a method and apparatus for facilitating online payment transactions in a network-based transaction facility using multiple payment instruments have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.