US20090112767A1

US20090112767A1 - Escrow system and method

Info

Publication number: US20090112767A1
Application number: US12/257,212
Authority: US
Inventors: Ayman Hammad; Patrick Faith
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2007-10-25
Filing date: 2008-10-23
Publication date: 2009-04-30
Also published as: EP2218046A4; US20090119170A1; AU2008316620B2; US20120310832A1; WO2009055726A2; US8219490B2; CA2703751A1; US9721250B2; US20090187492A1; WO2009055719A2; US10163100B2; AU2008316613B2; US8433651B2; AU2008316620A1; BRPI0818769A2; US20170286953A1; BRPI0818774A2; US8589300B2; US20090112721A1; WO2009055726A3

Abstract

A system and method for conducting purchasing transactions using escrow. A central processing entity secures the terms to a purchasing transaction on behalf of the various parties to the transaction. Once the terms of the purchasing transaction are agreed upon, the central processing entity holds any funds used in the transaction in escrow until confirmation is received that a supplier's contractual obligations have been fulfilled.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS

This patent application claims priority to U.S. Provisional Application No. 60/982,682 filed Oct. 25, 2007, entitled “Mobile Phone Payment System and Method,” which is hereby incorporated by reference in its entirety for all purposes.

BACKGROUND

A consumer, using prior methods, could negotiate the purchase an item from a merchant or manufacturer. The consumer could negotiate with the seller over the item to be purchased, the price of the item, as well as other terms of the transaction. Once an agreement was reached, a consumer could conduct a payment transaction using a credit account.
This standard purchasing scenario presented some drawbacks for consumers. Typically, a consumer could only communicate with one merchant or manufacturer at a time. Consequently, merchants and manufactures were often not in direct competition with each other. Also, the consumer did not have financers competing over credit terms. As a result, consumers were often not receiving the best possible financing deals for their purchases.
The typical purchasing scenario also presented some problems for merchants. For example, when purchasing transactions are conducted over the Internet, the merchant is typically the entity that bears the financial risk if the consumer is unable to pay for the purchased item. As a result, merchants and manufacturers were often hesitant to give their best deal online because they had to incorporate into any offered price the credit risk of the consumer.
Issuers that offered financing terms often encountered a risk similar to the risk faced by merchants. For example, when a consumer purchases an item in person, perhaps using a point-of-sale terminal at a retailer, the issuer bears the risk if the consumer fails to pay off the debt. As a result, issuers have to price into their financing terms this assumed risk for these transactions.
Embodiments of this disclosure address these and other problems.

SUMMARY

Embodiments of the invention are directed to methods and systems suitable for processing transactions.
One embodiment is a method for a payment transaction using a central processing entity. The method comprises receiving a purchase request message from a consumer, sending to one or more merchants a supply request message, receiving from the one or more merchants one or more supply response messages, sending to one or more issuers a financing request message, receiving from the one or more issuers one or more financing response messages, selecting a supplier from the one or more supply response messages and selecting one or more issuers from the one or more financing response messages to form a purchasing contract, sending an acceptance message to the selected supplier and to the one or more selected issuers, receiving a set of payments from the one or more selected issuers, holding the set of payments in escrow until a confirmation is received, and releasing the set of payments to the selected supplier after receiving confirmation from the consumer.
In another embodiment is method for purchasing goods using a central processing entity. The method comprises sending a purchase request message to the central processing entity. The central processing entity uses the purchase request message to collect a set of merchandise offers from one or more merchants and to collect a set of financing offers from one or more financers. An offer is accepted from the set of offers, and an offer is accepted from one or more selected financing offers from the set of financing offers to create a purchasing contract. The creation of the purchasing contract causes the central processing entity to place a set of payments derived from the one or more selected financing offers into escrow with the central processing entity. A confirmation that a merchant has fulfilled its obligations under the purchasing contract is sent to the central processing entity. The confirmation causes the central processing entity to release the set of payments in escrow to the merchant.
These and other embodiments are described in further detail below, with reference to the Figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary system for conducting a payment transaction using escrow, in accordance with an embodiment of the disclosure.

FIG. 2 is a flowchart illustrating a method for conducting a payment transaction using escrow, in accordance with an embodiment of the disclosure.

FIG. 3 is an illustration depicting an exemplary user-interface, in accordance with an embodiment of the disclosure.

FIG. 4 is an illustration depicting an exemplary user-interface, in accordance with an embodiment of the disclosure.

FIG. 5 is an illustration depicting an exemplary user-interface, in accordance with an embodiment of the disclosure.

DETAILED DESCRIPTION

Embodiments of the invention are directed to a method and a system for conducting purchase transactions through a central processing entity through escrow.
One aspect of the disclosed systems and methods is that a central processing entity sits in the middle to parties conducting a purchasing transaction, such as a consumer, a merchant, and an issuer. In one embodiment, the central processing entity is a payment processing organization that operates a payment processing network, the payment processing network itself, or any subcomponent thereof. All parties can deal with the central processing entity and not directly with the other parties. As a result, a number of benefits can be obtained for all parties.
As used herein, “payment processing organization” may refer to an organization that runs the payment processing network, or it may refer to any other suitable entity that deals with or processes payments. A “payment processing network” may include any suitable collection of computational apparatuses that can process payment information. In some embodiments, a payment processing network may be adapted to process credit and debit card transactions. More specifically, it may be able to send and receive authorization request messages for debit and credit card transactions, and may be able to clear and settle such transactions.

I. Exemplary System for Conducting a Payment Transaction Using Escrow

FIG. 1 is a block diagram of an exemplary system 100 for conducting a payment transaction using escrow, in accordance with an embodiment of the invention. System 100 includes a consumer 110 using a communication device 120 that is in operative communication with a payment processing network 130. The system 100 also includes suppliers 140 (e.g., supplier A 140(a) and supplier B 140(b)) and issuers 150 (e.g., issuer A 150(a) and issuer B 150(b)). The suppliers 140 and the issuers 150 are also in operative communication with the payment processing network 130. Any suitable number of suppliers 140 and issuers 150 may be present in systems according to embodiments of the invention.
Consumer 110 may be an individual, or an organization such as a business that is capable of using a communication device 120 to conduct a payment transaction. A payment transaction can be any exchange of services or goods. Consumer 110 will typically have credit accounts and debit accounts with one or more of the issuers 140. The credit and debit accounts of a consumer 110 can be associated with one or more communication devices 120.
A communication device 120 can refer to any suitable device that allows consumer 110 to communicate a payment processing organization 120 to conduct a payment transaction with suppliers 130 and issuers 140. Some examples of communication devices include computer apparatuses (e.g., laptop computers, desktop computers, etc.), cellular or wireless phones, personal digital assistants (PDAs), pagers, smart media, and the like. Communication devices can be hand-held and compact so that they can fit into a consumer's wallet and/or pocket (e.g., pocket-sized).
Communication device 120 is a capable of communicating information in any suitable form. For example, some communication devices 120 may communicate with a payment processing organization 120 by sending messages over the Internet. Other communication devices 120 may use a short message service (SMS) message such as a text message, a multimedia media message (MMS), a phone call, a voice message, a voicemail message, an instant messaging (IM) message, an email message, etc.
In some cases, an entity receiving a message from a communication device 120 (e.g., payment processing network 130) may require a PIN for security purposes before authorizing the transmission. Consumer 110 can enter the PIN into communication device 120 communicating with the entity. The communication device 120 can then send the PIN to the entity. Once the entity verifies the PIN, the requesting entity will authorize the transmission of the message. For example, to send a SMS message to payment processing network 130, payment processing network 130 may request a PIN that must be verified as a valid PIN before allowing the transmission of the SMS message.
In some embodiments, the communication device 120 may interact with other entities indirectly. For example, in one embodiment, the communication device 120 may interact with a payment processing network 130 by first communicating with an access device, such as a point-of-sale terminal, that in turn communicates with the payment processing network 130.
If an access device is a point of sale terminal, any suitable point of sale terminal may be used including card or phone readers. The card or phone readers may include any suitable contact or contactless mode of operation. For example, exemplary readers can include RF (radio frequency) antennas, magnetic stripe readers, etc. to interact with the portable consumer devices.
In some embodiments, communication devices 120 may include specialized software that allows the communication device 120 to communicate directly other entities. For example, a communication device 120 in the form of a mobile phone may include translation software that translates transaction information received from an access device into a form that can be understood, processed, and transmitted by payment processing network 130.
In some embodiments, communication devices 120 may use generalized software to allow the device to communicate with other entities. For example, a communication device 120 in the form of a computer may use a standard web browser to communicate with a payment processing network 130 over the Internet. The payment processing network 130 may run a web site that receives, processes, and responds to messages received over the Internet.
Suppliers 140 can include any entity that can supply the goods or service that a consumer may wish to purchase. Some examples of suppliers include manufacturers of goods, providers of services, or retailers. Suppliers 140 can communicate with a payment processing organization using any suitable method to conduct a payment transaction. For example, supplier 140 may use an e-commerce business application to conduct a transaction over the Internet by communicating with a payment processing organization.
Issuers 150 can include entities that may open and maintain an account for a consumer 110. Such issuer 150 may or may not have a pre-existing relationship with the consumer 110. For example, issuer A 150(a) may have issued a credit card to the consumer 110, but issuer B 150(b) may not have done so. Some examples of issuers include banks, business entities such as retail stores, or governmental entities. In many cases, issuer 150 may also issue a payment card to a consumer 110.
A payment processing network 130 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network 130 may include VisaNet™. Payment processing networks such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services.
In one embodiment, the payment processing network 130 includes a value-added services engine (VASE) 131. A VASE 131 is an engine, often written in software running on a server computer, capable of facilitating communications and transactions between consumers 110, suppliers 140, and issuers 150. In addition, a VASE can provide a number of services for each of the parties involved in a payment transaction. For example, VASE 131 is capable of interacting with a fraud risk module 132 and a credit risk module 133 to create a risk analysis of the consumer 110. This risk analysis can be given to suppliers 140 and issuers 150 to help suppliers 140 and issuers 150 decide what terms they will offer to the consumer 110 in a payment transaction. VASE 131 is also capable of using an escrow module 134 to hold consumer 110 funds received from an issuer 150 until the consumer 110 confirms that a supplier 140 has fulfilled their obligations to the consumer 110 in a payment transaction.
A VASE 131 may be run on a computer or a server computer. A server computer refers to a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, server computer may be a database server coupled to a web server. VASE 131 may use any suitable wired or wireless network, including the Internet. A server computer can include a computer readable medium (CRM). CRM comprises code for performing the functions of server computer. Server computer may also include a processor (not shown).
VASE 131 may also include a database. A database may store any suitable data. For example, a database may include data that links information associated with a communication device 120 (e.g., phone number) to account numbers and other information of consumer 110. Database also includes data that links consumer data (e.g., account numbers) to issuers 150.
Escrow module 134 is a module that may be present in a payment processing network 130. One purpose of the escrow module is to hold a consumer's 110 funds received from an issuer 150 in escrow until a supplier 140 completes their obligations of payment transaction. In one embodiment, a consumer 110 can notify a payment processing network 130 that the consumer 110 has received delivery of the items purchased from the supplier 140. After a payment processing network 130 receives this notification, the payment processing organization can use the escrow module 134 to release the stored funds to the supplier 140. In one embodiment, the payment processing organization releases the funds to the supplier 140 by crediting the funds to an account of the supplier 140. The escrow module 134 may be run on a computer or a server computer. The escrow module 134 may have access to a database to store information. The escrow module 134 may be able to communicate with a VASE 131.
Fraud risk module 132 is a module that may be present in the payment processing network 130. The fraud risk module 132 is able to collect and analyze data concerning a consumer 110 to determine the risk that a request received by the payment processing network 130 from a consumer 110 is fraudulent. For example, one embodiment of a fraud risk module 132 may analyze the location from where the request of the consumer 110 originated. The fraud risk module 132 can compare the location to other data, such as the home or business address of the consumer 110. The fraud risk module 132 may then assign or adjust a fraud risk score based on the comparison of this location information. Other factors could also be used by a fraud risk module to determine a fraud risk score. For example, a fraud risk module might analyze the value of the transaction, the order history of the consumer, the communication medium or protocol used to transmit the purchase transaction request, the shipping parameters in the request, the time of day the request was made, the location from which the request was made, whether the request was authenticated using a PIN, etc. The fraud risk analysis can then be shared with issuers 150 and suppliers 140 so that those entities may use the fraud risk analysis when forming responses to a consumer's request to purchase or finance goods or services.
Credit risk module 133 is a module that may be present in the payment processing organization. The credit risk module 133 can be configured to analyze a consumer's credit history in the context of a given payment transaction to determine the potential risk that a consumer 110 will not be able to fulfill any payment obligations for the given transaction. For example, if a consumer has frequently made late payments on a credit account that is being used in a given payment transaction, then the credit risk module 133 can assign a higher credit risk score to for that transaction. Other credit risk factors may include the percent of the credit limit current used by a consumer, the number of credit accounts opened by the consumer, the length of the consumer's credit history, etc. The credit risk analysis can then be shared with issuers 150 and suppliers 140 so that those entities may use the credit risk analysis when forming responses to a consumer's request to purchase or finance goods or services.
The following patents and applications can describe suitable fraud risk modules or aspects thereof, and they are herein incorporated by reference in their entirety for all purposes: U.S. patent application No. 10/863,813, filed on Jun. 7, 2004, U.S. Pat. No. 6,119,103, issued Sep. 12, 2000, entitled “Financial Risk Prediction Systems and Methods Therefor,” U.S. Pat. No. 6,658,393, issued Dec. 2, 2003, entitled “Financial Risk Prediction Systems and Methods Therefor,” and U.S. Patent Application Publication No. 2002/0194503, published Dec. 19, 2002, entitled “Distributed Quantum Encrypted Pattern Generation and Scoring.

II. Exemplary Method for Conducting a Transaction Using Escrow

FIG. 2 is a flow chart illustrating the steps taken according to one embodiment. Many of the entities in FIG. 1 will be referenced in the description of the steps outlined in FIG. 2.
At step 201 a consumer 110 initiates a payment transaction by sending a purchasing request message to a payment processing network 130. The purchasing request message may include parameters for the items or services that the consumer wishes to purchase. In one embodiment, a consumer 110 may use a communication device 120 to enter the initial parameters for the payment transaction. In various embodiments, the initial parameters may include the particular items the consumer wishes to purchase, features related to any of the requested items, the desired price range, delivery terms, financing terms, etc. Parameters related to the goods or services to be purchased can be considered purchase parameters. Parameters related to the financing terms desired by the consumer can be referred to as financing parameters.
A consumer 110 may also select a consumer profile at step 201 for use in a given payment transaction. In one embodiment, a consumer profile is configured by a consumer 110 to reflect various preferences that the consumer 110 may wish to use for a class of payment transactions. For example, a consumer may create a profile named “electronics” that contains preferences for transactions involving electronics. This profile may reflect the consumer's preference for weekend home delivery of electronic items. The consumer may also prefer to use certain credit accounts when purchasing electronics, because those credit accounts give extra insurance or warranty benefits for items purchased using those credit accounts. A consumer 110 may create many different profiles. For example, a consumer may also have a profile named “automotive” in addition to an “electronics” profile. In the “automotive” profile, the consumer may wish to minimize the interest rate used for purchases related to automobiles. One skilled in the art will recognize that there are many different permutations of preferences that a consumer could express through the use of consumer profiles.
Once a consumer 110 has selected the desired parameters for a transaction, the parameters are communicated to the payment processing network 130 in a purchase request message. As discussed earlier, a communication between a consumer 110 and a payment processing network 130 may be transmitted in a variety of ways. For example, a communication device 120 used by the consumer can transmit the purchasing request message to the payment processing network 130 over the Internet.
At step 202, the payment processing network 130, or a subcomponent thereof, may conduct risk assessment of the consumer's requested purchase transaction. Conducting a risk assessment is optional. In various embodiments, a fraud risk module may be used to create a fraud risk score reflecting the probability that the received transaction request is fraudulent. In various embodiments, a credit risk module may be used to create a credit risk score reflecting the probability that a consumer will not be able to pay for the items or services requested in the payment request message. As discussed earlier in reference to the fraud risk module and the credit risk module, a variety of factors may be considered by each module to determine their respective risk scores. Also, some embodiments may combine a credit risk score and a fraud risk score into a single risk score.
At step 203, after it receives the purchase request message, the payment processing network 130 sends (e.g., transmits) supply request messages to suppliers 140. The supply request message can contain many pieces of data. For example, the supply request message can identify the goods or services that the consumer 110 wishes to purchase. The supply request message may also contain other purchase parameters sent to the payment processing network 130 from the client 110. Other data, such as the outcome of any credit risk or fraud risk analysis can also be transmitted to the suppliers 140 in a supply request message.
In some embodiments, a payment processing network 130 may aggregate many similar purchase requests received from different consumers 110. The payment processing network 130 (or a server computer present therein) may aggregate these purchase requests into a single supply request message to each of the suppliers 140. One potential advantage for consumers in this scenario is that consumers may be able to get better terms from supplier when the goods or services are purchased in bulk in combination with other consumers.
Illustratively, ten different consumers may send purchase requests to buy the same type of television. The payment processing network 130 can aggregate those purchase requests and can send an aggregate supply message to one or more of the suppliers 140. Because the supply message may request the purchase of ten television sets instead of one television set, one or more of the suppliers 140 may be willing to provide a greater discount on the bulk sale of television sets.
In some embodiments, consumers 110 may elect to participate in an aggregated purchase request while selecting the parameters for a transaction. In other embodiments, consumers may indicate in their profile that they are willing to participate in aggregated purchases if available. In yet other embodiments, the payment processing network 130, may suggest to a consumer that they join an aggregated purchase request if the consumer submits a purchase request similar to an aggregated purchase request already in progress.
A payment processing network 130 may also run different aggregated purchases in different manners. For example, a payment processing network may allow consumers 110 to join an aggregated purchase request until a certain number of purchase requests have been received. The target number of requests may be 10, 100, 1000, etc. Alternatively, a payment processing network may collect purchase orders until the anticipated aggregate value of the purchase orders crosses a threshold value. Other embodiments may collect purchase orders until a certain date has passed or a certain amount of time has elapsed. It is also possible to combine these variations. For example, an aggregated purchase request may remain open until 100 orders have been collected or one week has passed. In some embodiments, consumers may be able to opt-out of an aggregated purchase request if the period to join the aggregated purchase request is still open. In any of these embodiments, the payment processing network may send out a notification to any consumers who have joined the aggregated purchase request in order to give the consumers updates on the status of the purchase request or to inform the consumers that the opportunity to opt in or out of a purchase request will soon pass.
In some embodiments, an aggregated purchase request may be managed by a VASE 131 and information related to the aggregated purchase request may be stored in associated databases. In other embodiments, a separate module may manage the aggregated purchase request on behalf of the VASE 131.
In some embodiments, the payment processing organization that operates or is affiliated with the payment processing network 130 is the entity actually buying the goods or services from the supplier 140, not the consumer 110. As a result, if the consumer 100 backs out of a purchase transaction after an agreement has been reached, then the payment processing organization that operates or that is affiliated with the payment processing network 130 owns the goods or services and is responsible for payment.
At step 204, suppliers 140 send supply response messages to the payment processing network 130. Suppliers 140 can include in their supply response messages any offers that they feel is appropriate. A supplier 140 may include multiple offers in response to a single supply request message, or a supplier 140 may decline to make any offer.
At step 205, offers for financing from one or more issuers 150 are solicited from the payment processing network 130 in a financing request message. A financing request message may contain the parameters of the consumer's negotiation request, any risk analysis conducted by the payment processing organization, or other relevant data. For example, in some embodiments the offers received from the suppliers 140 may also be presented to the issuers 150 for their evaluation. Issuers 150 may wish to make any financing offers for specific suppliers 140 or even specific offers made by suppliers 140.
In some embodiments, it may be beneficial for a consumer 110 to receive financing for a payment transaction from more than one issuer 140. For example, one issuer 140 may be able to offer an very low interest rate on a loan, but this low interest rate is only available up to a maximum amount that is below the value for a given transaction. If a consumer 110 wishes to minimize the overall interest rate on any funds borrowed used to conduct a transaction, it may be beneficial for a consumer to combine the capped low interest rate offer from one issuer with another financing offer from a different issuer in order to obtain the best overall financing. Thus, a single transaction may be financed by multiple issuers in some embodiments of the invention.
In some embodiments, the financing may not be strictly on cash terms. For example, the consumer 110 may have a credit account with an issuer 150 with a rewards program, and the issuer, in its offer, may allow the consumer to finance the purchase, in whole or in part, with reward points previously earned by the consumer 110.
In some embodiments, the payment processing organization that operates the payment processing network 130 is the entity securing financing for the payment transaction from an issuer 140, not the consumer 110. As a result, it is the payment processing organization that must pay back the issuer if the consumer fails to pay for the purchase transaction. Issuers may offer the payment processing network better financing terms than a consumer because the fraud and/or credit risk to the issuer is often lower when offering financing to a payment processing network than a consumer.
In some embodiments, the financing may obtained in an aggregated manner. For example, a number of consumers 110 may have credit accounts with similar issuers 150, and the payment processing network 130 may present these financing requests to the issuers in an aggregated fashion similar to the aggregated purchase requests discussed earlier.
At step 206, offers from one or more issuers are received by the payment processing network 130 in a financing response message. Issuers 150 are free to make any numbers of offers in response to a give financing request message.
At step 207, one or more offers from the suppliers 140 and the issuers 150 are selected by the consumer 110 to form a purchasing contract. In one embodiment, the offers submitted by the suppliers 140 and issuers 150 are presented to the consumer 110, and the consumer 110 accepts one or any combination of the offers that the consumer finds most appealing. In some embodiments, the payment processing network 130 groups a supplier's offer with an issuer's offer before presenting the combined offers to the consumer 110. The combined offers may be presented to the consumer 110 via a Web interface. In another embodiment, the payment processing organization has the authority to select offers on behalf of the consumer within specified parameters. In various embodiments, the suppliers and issuers are notified by using acceptance messages. The one or more accepted supply offers and the one or more accepted financing offers can be considered a set of accepted offers.
At step 208, the payment processing network 130 collects the funds from the issuers 150 of any selected financing offers and places those funds from into escrow. In one embodiment, an escrow module 134 is used to store and track the funds. The one or more selected financing offers can be considered a set of payments.
At step 209, the suppliers 140 of any selected offers are notified that their offers have been accepted by a consumer 110. Once a supplier 140 is notified that its offer has been accepted, the supplier is aware that it has entered into a contract with the consumer and the supplier can begin to fulfill the terms of the contract.
At step 210, the consumer 110 confirms to the payment processing network 130 that a supplier 140 has completed its obligation to the consumer under the purchasing contract. The precise obligations of the supplier 140 will depend on the contract. In one embodiment, the consumer 110 will confirm (e.g., in a confirmation message) that he has received satisfactory delivery of the items the consumer 110 has purchased from the supplier 140. The consumer 110 may sent his confirmation to the payment processing network 130 using the same communication device 120 the consumer used to create the purchasing request message. The consumer 110 may alternatively use a different device to send its confirmation. In some embodiments, the consumer may send an email, SMS, or other message to the payment processing organization to confirm that the supplier has fulfilled their obligations. In some embodiments, the payment processing organization may send a communication to the consumer 110 asking the consumer 110 to confirm that that supplier 140 has fulfilled its obligations. This message may be sent via email, SMS, or any other appropriate means. In another embodiment, confirmation may not be sent by the consumer; instead, confirmation is sent to the payment processing organization by a third-party, such as a shipping entity, freighter, or installation service.
In the event that the consumer 110 fails to send a timely confirmation, the payment processing network 130 may wish to seek independent confirmation that a supplier 150 has fulfilled their obligations.
At step 211, the funds held in escrow are released to the supplier 140 after the consumer's 110 confirmation is received by the payment processing network 130. The funds can be transferred to the supplier in a variety of ways. For example, a check can be mailed, funds can be wired to an account owned by the supplier, etc. In another embodiment, an acquirer, such as a bank that operates a bank account for the supplier, receives the released funds on behalf of the supplier. An acquirer refers to any suitable entity that has an account with supplier. Once step 211 is complete, the transaction is complete.
FIGS. 3-5 show examples of user-interfaces that a consumer 110 might use according to one embodiment. The illustrations shown in FIG. 3-5 resemble screen shots of a generic web browser that can be used to communicate with a payment processing network 130. It will be clear to one of skill in the art that the interfaces shown in FIG. 3-5 can easily be adapted to for a variety of communication devices 120. For example, the screen, or slight variants thereof, could be displayed on a computer, on a mobile phone, at a POS device, etc.
FIG. 3 shows an example of a screen a consumer 110 might use to enter parameters for a negotiation transaction that the consumer wishes to conduct. FIG. 3 corresponds to step 201 in FIG. 2. In FIG. 3, a consumer is presented with a form that presents a number of different options that a consumer can use to specified the consumer's desired criteria for a purchase transaction. The parameters in the embodiment shown in FIG. 3 include the type of item to purchase 310, a specific feature of the item 320, a desired price range 330, a delivery preference 340, financing preferences 350, and a selected user profile 350. In the example shown in FIG. 3, the consumer 310 wishes to purchase an LCD television for between $2000.00 and $2500.00. The consumer has also specified that delivery should be by Aug. 30, 2008 and that no specific financing terms are preferred. Also, the user has selected an “Electronics” user-profile that the consumer has configured. As described above, this profile may specify additional criteria relevant to this negotiation request. When the consumer clicks on the submit button, a purchase request message is sent to a payment processing network 130.
FIG. 4 shows an example of how one embodiment presents to a consumer 110 a number of offers received from suppliers 140 and issuers 150. FIG. 4 corresponds to step 207 in FIG. 2. In FIG. 4, a payment processing organization operating a payment processing network 130 has taken the information given to the payment processing organization by the consumer in FIG. 3 and obtained a number of offers for goods and financing. These offers have been grouped by the payment processing organization and are presented to the consumer in FIG. 4. Other embodiments may present the offers for merchandise separately from the offers for financing.
In FIG. 4, a number of offers from various suppliers 140 and issuers 150 can be seen. For example, “Offer #1” 410 presents a 42″ LCD with 1080 p from Brand X for $2000.00. “Offer #2” 420 presents a 46″ LCD with 1080 p from Brand Y for $2150.00. FIG. 4 also shows a number of different financing options associated with these offers. For example, “Offer #1” uses credit card A of the consumer and offers 0% financing for 60 days and 15.5% thereafter. “Offer #2” includes a financing offer using credit card B for 8.9% interest. “Offer #3” 430 offers for the user to use 100,000 reward points that the consumer has earned with that account.
In the example shown in FIG. 4, the consumer 110 has selected Offer #2 420 as his preferred offer. When the consumer clicks the submit button, the payment processing network 130 will secure the appropriate funds from the issuer 150 holding “Credit Card B” and send a message to the supplier 140 of the television to send the goods to the consumer.
FIG. 5 shows an example of a user-interface that a consumer 110 might use to confirm that a supplier 140 has fulfilled their obligations. FIG. 5 corresponds to step 210 in FIG. 2. In this screen, a consumer is confirming that the consumer has received the item purchased. The payment processing network 130 may then release consumer funds held in escrow to the supplier.
Embodiments of the invention provide for a number of advantages. One advantage to a consumer is increased competition among merchants and issuers. As a result, consumers should be able to secure better deals for purchases and financing. Another benefit may be that the central processing entity will be able to aggregate purchase requests from a number of consumers and present those aggregated purchase requests to sellers and issuers so as to secure better terms for consumers.
One advantage to merchants in some embodiments is that, since they are actually selling to the central processing entity, rather than the consumer, the credit risk for any transaction is minimal. Also, the central processing entity can hold funds that are to be used to pay for any purchases in escrow. As a result, a merchant can feel more secure about any transactions conducted with a central processing entity because the merchants know that the funds are available as soon as the merchants complete their obligations under a purchase contract. Additionally, embodiments allow merchants to incorporate real-time information, such as inventory, into any offers for sale that they make.
Issuers are also able to benefit from aspects of the disclosed systems and methods. For example, issuers can be presented with a variety of information that they can use to determine the financing terms that they will offer on a transaction by transaction basis. Also, issuers can feel more secure about being paid for any credit they offer, because it is the central processing agency buying goods from merchants.
Certain embodiments of the invention may include none, some, or all of the above technical advantages. One or more other technical advantages may be readily apparent to one skilled in the art from the figures, descriptions, and claims included herein.

III. Alternative Embodiments

The process outlined in FIG. 2 describes a general embodiment. There are many variations of the general flow outlined in FIG. 2 that might be appropriate for other embodiments.
One alternative embodiment is a fast escrow embodiment. In this embodiment, the entire process is designed to occur over a very short period of time similar to a typical purchase made using any typical Internet storefront.
In another alternative embodiment, customer purchase requests are not processed immediately. Instead, purchase requests from many different consumers may be aggregated by the payment processing organization and presented to suppliers and issuers as an aggregated request.
Another alternative embodiment is an automated or standing-request embodiment. In this embodiment, a consumer may make a purchase request that is stored with the payment processing organization. The payment processing organization will periodically solicit offers for goods, services, and financing from suppliers and issuers. Whenever a supplier or issuer makes an offer that qualifies under the standing-request, the consumer will accept the offer. This process can occur a pre-determined number of time or indefinitely.
In yet another embodiment, in addition to searching for items/service and financing, the payment processing organization may also search for and present other relevant items for the transaction. For example, in one embodiment, the payment processing organization may search for coupons that are relevant for the items or financing used by the consumer.

VII. Computer Apparatuses

FIG. 6 shows a block diagram of subsystems that may be present in computer apparatuses that can be used according to various embodiments.
The various participants and elements in the previously described Figures may operate using one or more computer apparatuses (e.g., the previously described communication device 110, or a server computer in the payment processing network 130) to facilitate the functions described herein. Any of the elements in the Figures may use any suitable number of subsystems to facilitate the functions described herein. Examples of such subsystems or components are shown in a FIG. 6. The subsystems shown in FIG. 6 are interconnected via a system bus 775. Additional subsystems such as a printer 774, keyboard 778, fixed disk 779 (or other memory comprising computer readable media), monitor 776, which is coupled to display adapter 782, and others are shown. Peripherals and input/output (I/O) devices, which couple to I/O controller 771, can be connected to the computer system by any number of means known in the art, such as serial port 777. For example, serial port 777 or external interface 781 can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus allows the central processor 773 to communicate with each subsystem and to control the execution of instructions from system memory 772 or the fixed disk 779, as well as the exchange of information between subsystems. The system memory 772 and/or the fixed disk 779 may embody a computer readable medium. Any of these elements may be present in the previously described features. For example, the previously described directory server and access control server may have one or more of these components shown in FIG. 6.
A computer readable medium according to an embodiment may comprise code for performing any of the functions described above. For example, the previously described servers run by a payment processing organization may comprise a computer readable medium comprising: a) code for receiving a purchase request message over a network; and b) code for sending messages to suppliers and issuers. The server may also have a processor coupled to the computer readable medium, where the processor executes instructions embodied by computer code on the computer readable medium.
It should be understood that the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement the present invention using hardware and a combination of hardware and software.
Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.
The above description is illustrative and is not restrictive. Many variations of the disclosure will become apparent to those skilled in the art upon review of the disclosure. The scope of the disclosure should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the disclosure.
All patents, patent applications, publications, and descriptions mentioned above are herein incorporated by reference in their entirety for all purposes. None is admitted to be prior art.

Claims

1. A method for a payment transaction using a central processing entity, the method comprising:

receiving a purchase request message from a consumer;

sending to one or more suppliers a supply request message;

receiving from the one or more suppliers one or more supply response messages;

sending to one or more issuers a financing request message;

receiving from the one or more issuers one or more financing response messages;

selecting a supplier from the one or more supply response messages and selecting one or more issuers from the one or more financing response messages to form a purchasing contract;

sending an acceptance message to the selected supplier and to the one or more selected issuers;

receiving a set of payments from the one or more selected issuers;

holding the set of payments in escrow until a confirmation is received; and

releasing the set of payments to the selected supplier after receiving confirmation from the consumer.

2. The method of claim 1 wherein the purchase request message includes one or more purchase parameters, wherein the purchase parameters can be specific values or a range of values.

3. The method of claim 1 wherein the purchase request message includes one or more financing parameters, wherein the financing parameters can be specific values or a range of values.

4. The method of claim 1 wherein the supply request message or the financing request message includes information from a consumer profile created by the consumer, wherein the consumer profile contains information on the consumer's purchasing or financing preferences.

5. The method of claim 1 wherein the supply request message includes information from more than one purchase request message.

6. The method of claim 1 wherein the financing request message includes information about the one or more supply response messages.

7. The method of claim 1 further comprising:

generating a risk assessment associated with the purchase request.

8. The method of claim 7 wherein the risk assessment includes a fraud risk assessment and a credit risk assessment.

9. The method of claim 7 wherein the financing request message includes the risk assessment.

10. The method of claim 1 wherein the one or more issuers are issuers that hold credit or debit accounts of the consumer.

11. The method of claim 1 wherein the one or more financing response messages include options to use reward points earned by the consumer.

12. The method of claim 1 wherein the step of selecting a supplier and selecting one or more financers is done by the consumer.

13. The method of claim 1 wherein the step of selecting a supplier and selecting one or more financers is done by the central processing entity.

14. The method of claim 1 wherein the confirmation is generated by the consumer.

15. The method of claim 1 wherein the confirmation is generated by a shipping entity.

16. A computer-readable medium comprising code for performing the method of claim 1

17. A server computer with a processor and the computer-readable medium of claim 16.

18. A method for purchasing goods using a central processing entity, the method comprising:

sending a purchase request message to the central processing entity, wherein the central processing entity uses the purchase request message to collect a set of supply offers from one or more supplier and to collect a set of financing offers from one or more financers;

accepting one or more selected supply offers from the set of supply offers and one or more selected financing offers from the set of financing offers to form a purchase contract, wherein creation of the purchasing contract causes the central processing entity to place a set of payments derived from the one or more selected financing offers into escrow with the central processing entity; and

sending a confirmation that a supplier has fulfilled its obligations under the purchasing contract to the central processing entity, wherein the confirmation causes the central processing entity to release the set of payments in escrow to the supplier.

19. A computer readable medium comprising:

code for sending a purchase request message to the central processing entity, wherein the central processing entity uses the purchase request message to collect a set of supply offers from one or more supplier and to collect a set of financing offers from one or more financers;

code for accepting one or more selected supply offers from the set of supply offers and one or more selected financing offers from the set of financing offers to form a purchase contract, wherein creation of the purchasing contract causes the central processing entity to place a set of payments derived from the one or more selected financing offers into escrow with the central processing entity; and

code for sending a confirmation that a supplier has fulfilled its obligations under the purchasing contract to the central processing entity, wherein the confirmation causes the central processing entity to release the set of payments in escrow to the supplier.

20. A computer apparatus comprising a processor, and the computer readable medium of claim 19 coupled to the processor.