Patent Publication Number: US-2019197503-A1

Title: Release of funds based on criteria

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. patent application Ser. No. 14/257,827, filed on Apr. 21, 2014, now U.S. Pat. No. 10,223,676, issued on Mar. 5, 2019; which is a continuation of U.S. patent application Ser. No. 11/238,359, filed on Sep. 29, 2005, now U.S. Pat. No. 8,706,618, issued on Apr. 22, 2014; the disclosures of both of these applications and patents are incorporated by reference herein. 
    
    
     TECHNICAL FIELD 
     The disclosed subject matter relates generally to the technical field of data processing and, in one example embodiment, to a method and system of releasing funds associated with a network-based commerce transaction based on criteria. 
     BACKGROUND 
     For users of a network-based commerce transaction, 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. For network-based commerce transactions, often the seller is directly paid by the buyer. This is risky for buyers because the buyers may receive a defective product, a misrepresented product, or not receive the product at all. Further, disreputable sellers may not be motivated to resolve any dispute because they have already received funds. 
     For some markets, buyers and sellers may instead agree to use an escrow account for the buyer to deposit funds. The buyer may instruct the escrow holder to release the funds to the seller upon satisfactory receipt of the item. However, the seller may wait a prohibitively long time to receive funds, that is, until the buyer receives the item and approves of funds release. 
     Accordingly, current payment transactions may delay payments to sellers and delivery of purchased goods to buyers. 
     SUMMARY 
     According to one embodiment, a system and a method to transfer payment to a seller of a network-based commerce transaction are described herein. The method includes generating a risk model based on seller-specific criteria, and releasing funds from a holding account to the seller based on the risk model. 
     Other features will be apparent from the accompanying drawings and from the detailed description that follows. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Embodiments of the present invention are 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: 
         FIG. 1  illustrates a network diagram depicting a system, according to an example embodiment of the present invention, having a client-server architecture. 
         FIG. 2  illustrates a block diagram showing an application server in an example embodiment of the present invention. 
         FIG. 3  illustrates a high-level entity-relationship diagram, illustrating various tables that may be maintained within one or more databases, according to an example embodiment. 
         FIG. 4  illustrates an interaction/flow chart according to an example embodiment. 
         FIG. 5  illustrates a block diagram showing an application server in an example embodiment of the present invention. 
         FIG. 6  illustrates a diagrammatic representation of a machine in the form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed, according to an example embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     Embodiments describe a method and a system to transfer payment to a seller of a network-based commerce transaction. The method includes generating a risk model based on seller-specific criteria, and releasing funds from a holding account to the seller based on the risk model. 
     In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present invention. It will be evident, however, to one skilled in the art that embodiments of the present invention may be practiced without these specific details. 
     Platform Architecture 
       FIG. 1  illustrates a network diagram depicting a system  100  having a client-server architecture, according to an example embodiment of the present invention. The system  100  includes a client machine  102 , such as a buyer&#39;s machine, a client machine  104 , such as a seller&#39;s machine, and a network-based system  112 , such as a network-based commerce system, coupled by a network  114 . A system, in the example form of the network-based system  112 , provides server-side functionality, via the network  114  to one or more clients. 
     The network  114  may, for example, be the Internet, a public or private telephone network (wireline or wireless), a private wireless network using technologies such as Bluetooth or IEEE 802.11x or other networks. The network  114  may include a mobile telephone network, a wireless wide area network (WWAN), a wireline telephone network, a wireless local area network (wireless LAN or WLAN), a wireless Metropolitan Area Network (MAN), and/or a wireless personal area network (PAN) (e.g., a Bluetooth® network). Other network-based technologies that may be used to connect include PON, VSAT satellite, Micro-impulse Radar, Radio Frequency identification (RFID), UltraWide Band, and/or Infrared. The network-based device may connect to the web using mobile internet exchange, e.g. Wireless Application Protocol (WAP) and/or Hypertext Transport Protocol (HTTP). 
     The client machines  102 ,  104  may include any network-based device, such as a mobile device, a palmtop computer, a laptop computer, a desktop computer, a personal digital assistant, a cellular telephone, a communications device, a wireless telephone, a land-line telephone, a control system, a camera, a scanner, a television, television cable, a telephone with a web browser, a facsimile machine, a printer, a pager, and/or a personal trusted device. The device may be browser-enabled. 
       FIG. 1  further illustrates, for example, a client  116  (e.g., a web client such as a web browser, Internet Explorer ® browser developed by Microsoft ®, and/or a programmatic client) that may execute on the client machine  102 ,  104 . 
     Turning specifically to the network-based system  112 , a server  124 , such as a Application Program Interface (API) server, a Short Messaging Service (SMS) Gateway Server, a web server, or an Interactive Voice Response (IVR) server may be coupled to, and may provide programmatic, SMS, web, and IVR interfaces, respectively, to one or more application servers  128 . The machines  102 ,  104  may use one or more of these interfaces to access the application server(s)  128 . 
     Further, while the system  100  shown in  FIG. 1  employs a client-server architecture, embodiments are of course not limited to such an architecture, and could equally well find applications in a distributed, or peer-to-peer, architecture system. 
     The application server(s)  128  may host one or more payment application(s)  132 . The application server(s)  128  are, in turn, shown to be coupled to one or more database servers  134  that facilitate access to one or more databases  136 . 
     The payment application(s)  132  may provide a number of payment services and functions to users, such as client users, for example: vendors or sellers and buyers. The payment application(s)  132  may allow users to accumulate value (e.g., in a commercial currency, such as the U.S. dollar, or a proprietary currency, such as “points”) in accounts, and then later to redeem the accumulated value for an offer (e.g., goods, services, promotions, or donation opportunities). The payment applications may also extend credit to user, and/or may also have access to other funding sources to complete transactions—e.g. a credit card, a bank account, and/or a credit line. A financial service provider may operate as a money transmitter or a bank, for instance, and may operate using the payment application(s)  132 . 
     The payment application(s)  132  may have an infrastructure to pay a plurality of vendors for a plurality of transactions each day. The payment application(s)  132  may also be implemented as a standalone software program, which does not necessarily have networking capabilities. 
     The payment application(s)  132  may have access to the database  136  having, for example, the personal user account information through, for example, the database server(s)  134 . The user account information may include payment information associated with the seller and a shipping address of the buyer, for example. The programmatic or web client  116  may operate a program supported by the one or more database server(s)  34 . The database server(s)  134  may support one or more account information links on a user interface of the machine  102  or  104 , for example, using the client  116 . By accessing the database server(s)  134 , the client user may add, amend or delete account information of the client user, among other information. One of the default payment methods may include direct transfers from system account balances, internal credit, a gift certificate, a bank account, a debit card, buyer credit, and/or a credit card into a holding account  150  of the payment application(s)  132 , as shown in  FIG. 2  or into an escrow account  450  of the payment application(s)  452 , as shown in  FIG. 5 . 
     Application Server(s) 
       FIG. 2  illustrates a block diagram showing application server(s) that are part of the network-based system  112 , in an example embodiment of the present invention. In this embodiment, the payment application(s)  132  may be hosted by the application server(s)  128  of the network-based system  112 . 
     The payment application(s)  132  may include a payment transfer module  142 , fraud prevention application(s)  144 , funds release application(s)  146  (such as a funds release module), dispute resolution application(s)  148 , and/or holding account(s)  150 . 
     The payment transfer module  142  may be responsible for executing payment transactions in transferring a payment from the buyer (e.g., buyer account) to the seller (e.g., seller account) via the payment application(s) and/or the financial service provider. The payment may be automatically transferred directly or may transfer through one of the holding accounts  150  between parties of the commerce transaction. 
     The payment application(s)  132  receives information from the transaction facility, stores some or all of this information for historical purposes in the database  136 , and determines what information to pass to the fraud prevention application(s)  144  and the funds release application(s)  146 . The fraud prevention application(s)  144  and the funds release application(s)  146  may each utilize this information to determine a risk level involved in the payment transaction. In one embodiment, input from one or more third party risk analysis providers (e.g., credit rating agencies) may be used to evaluate the risk level of the payment transaction. The results of the evaluation are passed back to the funds release application(s)  146  and/or the fraud prevention application(s)  144 , which continue processing the payment transaction based on the evaluation results. 
     The fraud prevention application(s)  144  may implement various fraud detection and prevention mechanisms to reduce the occurrence of fraud within the system  112 . The fraud prevention application(s) may prevent fraud with respect to the third party and/or the client user in relation to any part of the request, payment, information flows and/or request fulfillment. Fraud may occur with respect to unauthorized use of financial instruments, non-delivery of goods, and abuse of personal information. The fraud prevention application(s)  144  may also work closely with (and/or similarly to) the funds release application(s)  146 , and vice versa. 
     The funds release application(s)  146  may include a risk model  147 . The risk model  147  may be generated using data from the database(s)  136 , which may include data tables  200  of  FIG. 3 . The data tables  200  of  FIG. 3  may include a transaction-specific table  210 , a buyer-specific table  220 , and/or the seller-specific table  230  to track data regarding the transaction, data regarding the buyer, and data regarding the seller, respectively. 
     The risk model  147  may evaluate the accumulated data at various stages of the payment transaction to assess potential involved risks. The involved risks may concern, for example, a likelihood that a seller may be fraudulent (e.g., a seller lists goods for sale online with no intent or ability to deliver the purchased goods), or a seller&#39;s ability to fulfill purchase orders promptly. Based on the risk evaluation, the payment application(s)  132  may restrict a payment transaction between a buyer and a seller. In one embodiment, the risk evaluation is performed in real time and may enable an uninterrupted processing of the payment transaction. 
     Based on the information received from various sources, the risk model  147  may determine 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 model  147  without loss of generality. The risk model  147  may produce a consolidated risk response and passes it to the payment transfer module  142 . 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, and/or information on recommended restrictions on disbursing funds to the seller. 
     The payment transfer module  142  receives the risk response and acts according to the information provided. That is, the payment transfer module  142  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 (timing, and/or amount) the payment or manner in which the payment transaction is conducted. For example, the payment transfer module  142  may limit payment instruments offered for use in the payment transaction, may assign or modify a fee for processing the payment transaction, or may restrict the time, amount, or the manner in which funds are disbursed to the seller. 
     The amount of funds released from the holding account  150  (or the escrow account  450 ) may vary according to the risk model assessment. The funds may be released from the holding account  150  (or the escrow account  450 ) to the seller based on the assessment by the risk model  147 . For example, 95% of the funds may be released within or at 30 days. In another example, a certain percentage of a seller&#39;s average monthly transactions may be released immediately. 
     In addition, or alternatively, the timing for release of the funds from the holding account  150  (or the escrow account  450 ) may vary according to the risk model assessment. For example, the funds may be released at a time, e.g. 0 days, 15 days, or 30 days, after the funds are received into the account  150  (or  450 ). The funds release may be partial or full at the specified time, depending upon the circumstances or specifications of the funds release application(s). The release of the funds to the seller may thus be completed in a plurality of stages over a period of time, wherein the plurality of stages and the period of time is determined by the risk model assessment. For example, half of the funds may be released at 0 days, 25% may be released at 15 days, and the remaining percentage may be released at 30 days. 
     The funds release application(s)  146  may continuously (or on a periodic basis) trace transactions, e.g., a seller&#39;s transactions on a daily basis, and therefore the variable time or variable amount release may dynamically change. For instance, if the seller has a substantially large increase in velocity of trade and thus has a large amount of funds held in a holding account, funds may be released much more quickly. 
     In an additional embodiment, the seller may have given the payment application(s)  132  assurances, such as a security proxy or collateral, in exchange for minimizing the amount of funds held and/or for minimizing the time the funds are held. For example, if the seller has given the payment application(s) a valid social security number, financial services provider account information (e.g., bank account number, credit card account number, PayPal account access), a large amount of cash or some other proxy of security, the amount of time and amount of funds held may be minimized for that seller. The security proxy may also be considered a factor in the risk model  147  of the funds release application(s). 
     In one embodiment, the payment application(s)  132  may charge fees that vary according to the risk model assessment for each seller. For example, the fees may be reduced for more “trusted” sellers. In an additional embodiment, the seller may be considered a top tier seller in the network-based commerce system (e.g. an eBay® PowerSeller™) and/or in the payment application(s). This top tier status may result in paying lower fees of the payment application(s), and/or in having quicker access to funds in holding accounts. This top tier status may be dynamic and may also depend on other factors, such as those factors considered by the risk model  147 . 
     From a system point of view, the risk model  147  may aid in controlling risk exposure associated with the payment application(s)  132 . For example, the risk model  147  evaluates the risk that the buyer will not receive the item paid for, or will receive an unacceptable item, and that the seller will have an unsatisfactory response. In this instance, if the seller is not able to reimburse the buyer (or the payment application(s)), or refuses to make the reimbursement, the payment application(s) may then reimburse the buyer, thus affecting the risk exposure associated with the payment application(s). In this embodiment, the buyer is assured of “safe payments.” In alternate embodiments, the buyer may absorb the risk. 
     The dispute resolution application(s)  148  may provide mechanisms whereby disputes arising between transacting parties may be resolved. For example, the dispute resolution applications  148  may provide guided procedures whereby the parties are guided through a number of steps in an attempt to settle a dispute. In the event that the dispute cannot be settled via the guided procedures, the dispute may be escalated to a mediator or arbitrator. In an event where the seller and buyer do not come to an agreement and the buyer never received the item, or received a defective item, the payment application(s) may reimburse the buyer. If the funds in the holding account  150  have not yet been released to the seller, the funds in the account may be given back to the buyer. 
     The holding account  150  may be a transaction-specific holding account, and/or the holding account  150  may be a general seller-specific holding account associated with pending seller transactions, with or without sub-accounts for specific transactions. In any instance, the seller may associate collateral with the holding account directly or through another seller account associated with the payment application(s). 
     Data Structures 
       FIG. 3  illustrates a high-level entity-relationship diagram, illustrating various tables  200  that may be maintained within the database(s)  136  according to an example embodiment. The tables  200  may be utilized by and support the application(s) of the application server(s). The database(s)  136  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(s)  136  may be implemented as collection of objects in an object-oriented database. 
     The tables  200  may include a transaction-specific table  210 , a buyer-specific table  220 , and a seller-specific table  230 . The transaction-specific table  210 , the buyer-specific table  220 , and the seller-specific table  230  may each include a record for each transaction, each buyer, and each seller, respectively, of the network-based system  112 . A user may, it will be appreciated, operate as a seller, a buyer, or both, within the network-based system  112 . 
     The transaction-specific table  210  may include a record for the specific transaction (e.g., a purchase transaction) under consideration in the risk model  147 . The transaction-specific table  210  may include information such as the buyer, the seller, the description of the item, the price paid, the date, the quantity sold, the item identification number, the item category, and other transaction-related information. 
     The buyer-specific table  220  may include the buyer identification number, the buyer site identification, such as the IP address of the associated machine, the buyer country, and other buyer-related information. 
     The seller-specific table  230  may include the seller identification number, the seller site identification, such as the IP address of the associated machine, the seller country, the seller tier category, a tenure time associated with the network-based commerce system, security proxy, such as collateral associated with the holding account from the seller, a social security number of the seller, or a financial services provider account number of the seller, and other seller-related information, such as consistent volume sales, a high percentage total positive feedback for a minimum number of ratings, network-based marketplace policy compliance, a payment application account in good financial standing, and averaging a minimum monetary amount in sales per month for a minimum number of consecutive months. 
     The seller-specific table  230  may further be associated with a transaction history table  232  of the seller, a feedback table  236  of the seller, and a velocity of trade table  234  of the seller. The transaction history table  232  may include an item identification number, a sale amount, a date, a buyer identification number, a description, a quantity sold, and an item category for each transaction with which the seller is associated. The feedback table  236  may include peer review and a complaint rate related to the seller for various network-based transactions. The velocity of trade table  234  may include a volume of trade per month for items that the seller sells on the network-based commerce system. 
     Interaction/Flow Chart 
       FIG. 4  illustrates an interaction/flow chart of a method  300 , according to an example embodiment of the present invention. The interaction chart is divided into several categories, including the seller, the funds release application(s)  146 , and the buyer, representing actions taken by or at that user or application. 
     At block  310 , seller places an item in commerce. The item may be placed in the network-based system  112  for sale. The item may be offered for sale in an auction sale, or may be offered for sale at a fixed-price. 
     At block  320 , the buyer indicates intent to purchase the item placed in commerce. The item may have been won in the auction or the buyer may have indicated, in another way, intent to purchase the item offered at the fixed-price. The buyer may then transfer funds into the holding account  150 . 
     At block  330 , the funds release application(s) determines the amount of funds to hold back from the seller in the holding account, and/or determines for how long to hold back the funds, based on the risk model assessment using the criteria gathered from the database. 
     At block  340 , funds from the holding (or escrow) account are released to the seller by the payment transfer module  142  per the assessment from the risk model  147  of the funds release application(s)  146 . 
     At block  350 , the item is sent to the buyer at the direction of the seller. The item may be sent after or before funds are released to the seller or even during funds release. 
     At block  360 , the buyer receives the item sent at block  350 . 
     At block  370 , the buyer approves the item received at block  360  and the transaction is completed. It will be appreciated that the funds may or may not have been released to the seller before buyer approval. However, upon buyer approval, the funds may be released, if not done so already. 
     At block  380 , alternative to block  370 , the buyer initiates the dispute resolution process, for example, when the buyer does not approve of the item (e.g., the item is not as described, or is defective), or if the buyer does not receive the item. The dispute resolution process may start with a simple communication to the seller of the issue. The buyer and seller may use the dispute resolution application(s)  148  to resolve the issue. 
     Another Embodiment of an Application Server(s) 
       FIG. 5  illustrates a block diagram showing application server(s)  400  in an example embodiment of the present invention. The application server(s)  400  may replace the application server(s)  128  of the network-based system  112  of  FIG. 1  in certain environments. In this embodiment, the application server(s)  400  may host one or more marketplace application(s)  410 , and one or more payment application(s)  452  (similar to payment application(s)  132 , except application(s)  452  has an escrow account  450  rather than a holding account  150 ). 
     The buyer may “shop” or search, using one or more marketplace application(s)  410 , for an offer associated with the seller. The marketplace application(s)  410  may provide a number of marketplace functions and services to buyers, sellers, and/or to third parties, who access the system  112 . The marketplace applications  410  may provide a number of offering mechanisms and price-setting mechanisms; whereby a seller may list goods or services for sale, a promotion or a donation opportunity, a seller may promote their offers, a buyer can express interest in or indicate a desire to purchase such goods or services or to donate, and a price can be set for a transaction pertaining to the goods or services, or donation opportunity. 
     The marketplace applications  410  may include one or more store applications  414 . In an embodiment, the store applications  414  allow sellers to group their offers within a virtual store, which may be otherwise personalized by and for the sellers. Such a store may also offer promotions, incentives and features that are specific to and personalized by the respective seller. 
     Navigation of the network-based system  112 , including through the store application(s)  414 , may be facilitated by one or more navigation applications  416 . The one or more navigation application(s) may include a search module  418 . The navigation application(s) may enable key word searches of products/services/promotions/donations published via the system  112 . A browse application allows users to browse various category (e.g. music, books, offer price, shipping price), catalogue, or inventory data structures according to which products/services/promotions/donation may be classified within the system  112 . Various other navigation applications may be provided to supplement the search and browsing applications. 
     The marketplace applications  410  may include one or more fixed-price application(s)  420 . The fixed-price applications  420  support fixed-price offer formats and buyout-type offers. The fixed-price offer format may include, for example, the traditional classified advertisement-type offer, a catalogue offer, a television advertisement offer, a magazine offer, a website offer, an SMS offer, a data services offer, a billboard offer, a banner ad offer, or any other type of virtual or physical marketplace medium. The fixed-price offer in any of these listed formats may be considered the point of sale. In an additional embodiment, the client user may use the navigation application(s) to find the fixed-price offer. 
     In an embodiment, buyout-type offers (e.g., including the Buy-It-Now (BIN) technology developed by eBay Inc., of San Jose, California) may be offered in conjunction with an auction-format offer. The buyout-type offer may allow a buyer to purchase goods or services or make a donation, which are also being offered for sale via an auction, for a fixed-price that may be higher than the starting price of the auction. The buyout-type offer in any of these listed formats may be published in any virtual or physical marketplace medium and may be considered the point of sale. The offer may be accepted by the client user by indicating consent to the offer. In an additional embodiment, the client user may use the navigation application(s) to find the buyout-type offer. 
     The marketplace applications  410  may include one or more auction applications  422  that support various auction-format offer and price setting mechanisms (e.g., English, Dutch, Vickrey, Chinese, Double, Reverse auctions, etc.). The various auction applications  422  may also provide a number of features in support of such auction-format offers, such as a reserve price feature whereby a seller may specify a reserve price in connection with an offer and a proxy-bidding feature, whereby a bidder may invoke automated proxy bidding. The auction-format offer in any format may be published in any virtual or physical marketplace medium and may be considered the point of sale. In an additional embodiment, the client user may use the navigation application(s) to find the auction-format offer. 
     The marketplace applications  410  may include one or more personalization applications  424 . The personalization application(s)  424  may allow third parties to personalize various aspects of their interactions with the system  112 . For example the third party may, utilizing an appropriate personalization application  424 , create a personalized reference page at which information regarding transactions to which the third party is (or has been) a party may be viewed. Further, the personalization application(s)  424  may enable a third party to personalize products and other aspects of their interactions with the system  112  and other parties, or to provide other information, such as relevant business information about themselves. 
     The marketplace applications  410  may include one or more internationalization applications  426 . In one embodiment, the network-based system  112  may support a number of marketplaces that are customized, for example, for specific geographic regions. A version of the system  112  may be customized for the United Kingdom, whereas another version of the system  112  may be customized for the United States. Each of these versions may operate as an independent marketplace, or may be customized (or internationalized) presentations of a common underlying marketplace. 
     The marketplace applications  410  may include one or more reputation applications  428 . The reputation applications  428  allow parties that transact utilizing the network-based system  112  to establish, build, and maintain reputations, which may be made available and published to potential trading partners. Consider that where, for example, the network-based system  112  supports person-to-person trading, users may have no history or other reference information whereby the trustworthiness and credibility of potential trading partners may be assessed. The reputation applications  428  allow a user, for example through feedback provided by other transaction partners, to establish a reputation within the network-based system  112  over time. Other potential trading partners may then reference such a reputation for the purposes of assessing credibility and trustworthiness. The feedback for each seller is placed in respective feedback tables  236 . 
     In order to allow listings and/or products, available via the network-based system  112 , to be published in a visually informing and attractive manner, the marketplace applications  410  may include one or more imaging applications  430 . Sellers may upload images for inclusion within offer listings using J2ME, MMS, and WAP or other microbrowsers. An imaging application  430  also operates to incorporate images within viewed offered listings. The imaging application  430  may also operate to publish the identifier  166  associated with the listing  164  on the display  162 . The imaging applications  430  may also support one or more promotional features, such as image galleries that are presented to potential buyers. For example, sellers may pay an additional fee to have an image included within a gallery of images for promoted offers. 
     The marketplace applications  410  may include one or more offer creation applications  432 . The offer creation applications  432  allow sellers conveniently to author products pertaining to goods or services that they wish to transact via the system  112 . Offer management applications  434  allow sellers to manage offers, such as goods, services, or donation opportunities. Specifically, where a particular seller has authored and/or published a large number of products, the management of such products may present a challenge. The offer management applications  434  provide a number of features (e.g., auto-reproduct, inventory level monitors, etc.) to assist the seller in managing such products. One or more post-offer management applications  436  also assist sellers with a number of activities that typically occur post-offer. For example, upon completion of an auction facilitated by one or more auction applications  422 , a seller may wish to leave feedback regarding a particular buyer. To this end, a post-offer management application  436  may provide an interface to one or more reputation applications  428 , so as to allow the seller conveniently to provide feedback regarding multiple buyers to the reputation applications  428 . 
     The marketplace application(s)  410  may also further include one or more escrow application(s)  446  and the escrow account  450 . In certain environments, the escrow application(s)  446  of the marketplace applications  410  may replace the funds release application(s)  146  of the payment applications  132  in the system of  FIG. 1  and in the interaction chart of  FIG. 4 . In addition, the escrow account  450  of the marketplace applications  410  may replace the holding account  150  of the payment applications  132  in some environments. The escrow account  450  may be a transaction-specific escrow account, and/or the escrow account  450  may be a seller-specific escrow account for each pending seller transaction. In either instance, the seller may associate collateral with the holding account directly or through another seller account associated with the payment application(s)  452 . 
     A risk model  447  of the escrow application(s)  446  may operate in a manner similar to the risk model  147  of the funds release application(s)  146 , as previously described, to assess risks associated with each transaction. The risk model  447  may likewise, based on the information received from various sources (e.g., database tables  200  of  FIG. 3 ), determine the risk level of the payment transaction using a scoring algorithm. The risk model  447  may likewise consider factors such as the seller-specific criteria, the buyer-specific criteria, and/or the transaction-specific criteria, previously discussed herein. The risk model  447  may indicate, for example, that service should be denied to a participant (buyer or seller) due to high likelihood of fraud, may recommend, for example, a service fee for processing the payment transaction, payment instruments to be used by either the buyer or the seller, approval by buyer before release of funds from the escrow account  450 , and/or restrictions (e.g., time or amount held) on disbursing funds to the seller. 
     The payment application (s)  452  may replace the payment application(s)  132  of the network-based system  112  of  FIG. 1  in certain environments. The payment application(s)  452  may include the payment transfer module  142 , the fraud prevention application(s)  144 , and the dispute resolution application(s)  148 , as previously described. 
     In other embodiments, a seller and/or a buyer is able to dynamically choose between a variable payment option as described in the system of  FIGS. 1 and 2 , and an escrow option as described in the system of  FIG. 5 . The ability to choose may be based upon seller attributes, buyer attributes, or other criteria. The seller may choose to offer one or both options, e.g., in competitive environments, and the buyer may then choose or agree to the payment option used. 
     Even though the context of this description is with regard to marketplace applications, it is to be understood by those of skill in the art that the described subject matter may also be applicable to other types of applications for various types of transactions. The transactions may include those between a single seller and a single buyer or may include those between a single seller and multiple buyers, and may include selling a catalog-type product, or even a more unique product. 
     4. 4 Computer System 
       FIG. 6  shows a diagrammatic representation of a machine in the example form of a computer system  500  within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., network) to other machines. In a network deployment, the machine may operate in the capacity of a server or a client user machine in server-client user network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a server computer, a client user computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a mobile device, a palmtop computer, a laptop computer, a desktop computer, a personal digital assistant, a communications device, a wireless telephone, a land-line telephone, a control system, a camera, a scanner, a facsimile machine, a printer, a television, television cable a pager, a personal trusted device, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. 
     Further, while a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. 
     The example computer system  500  includes a processor  502  (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory  504  and a static memory  506 , which communicate with each other via a bus  508 . The computer system  500  may further include a video display unit  510  (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system  500  also includes an input device  512  (e.g., a keyboard), a cursor control device  514  (e.g., a mouse), a disk drive unit  516 , a signal generation device  518  (e.g., a speaker) and a network interface device  520 . 
     The disk drive unit  516  includes a machine-readable medium  522  on which is stored one or more sets of instructions (e.g., software  524 ) embodying any one or more of the methodologies or functions described herein. The instructions  524  may also reside, completely or at least partially, within the main memory  504 , the static memory  506 , and/or within the processor  502  during execution thereof by the computer system  500 . The main memory  504  and the processor  502  also may constitute machine-readable media. 
     The instructions  524  may further be transmitted or received over a network  526  via the network interface device  520 . 
     Applications that may include the apparatus and systems of various embodiments broadly include a variety of electronic and computer systems. Some embodiments implement functions in two or more specific interconnected hardware modules or devices with related control and data signals communicated between and through the modules, or as portions of an application-specific integrated circuit. Thus, the example system is applicable to software, firmware, and hardware implementations. 
     While the machine-readable medium  522  is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals. 
     The illustrations of embodiments described herein are intended to provide a general understanding of the structure of various embodiments, and they are not intended to serve as a complete description of all the elements and features of apparatus and systems that might make use of the structures described herein. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure.  FIGS. 1 to 6  are merely representational and may not be drawn to scale. Certain proportions thereof may be exaggerated, while others may be minimized. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. 
     The following description includes terms, such as “up”, “down”, “upper”, “lower”, “first”, “second”, etc. that are used for descriptive purposes only and are not to be construed as limiting. The elements, materials, geometries, dimensions, and sequence of operations may all be varied to suit particular applications. Parts of some embodiments may be included in, or substituted for, those of other embodiments. While the foregoing examples of dimensions and ranges are considered typical, the various embodiments are not limited to such dimensions or ranges. 
     The Abstract is provided to comply with 37 C.F.R. § 1.74(b) to allow the reader to quickly ascertain the nature and gist of the technical disclosure. The Abstract is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. 
     In the foregoing Detailed Description, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments have more features than are expressly recited in each claim. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment. 
     Thus, embodiments describe a method and a system to automatically transfer payment to a third party, for example, as part of a request from a network-based device. Although embodiments of the present invention have been described with reference to specific example 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 embodiments as expressed in the subjoined claims.