AUTOMATIC RESTITUTION OF TRANSACTION FEES, PUNISHMENT OF NON-PAYING BIDDERS, AND MANAGEMENT OF APPEALS
A method and system for resolving disputes between parties involved in a network-based transaction is described. One aspect of the present invention seeks to automatically facilitate the restitution of value to parties of the transaction, for example, facilitated by a network-based commerce platform or involving a network-based payment service, where a dispute has arisen with respect to the transaction.
Latest eBay Patents:
This application is a continuation of U.S. application Ser. No. 12/638,938, filed Dec. 15, 2009, which is a continuation of U.S. application Ser. No. 10/837,224, filed Apr. 30, 2004 and claims the benefit of U.S. Provisional Application No. 60/476,784, filed Jun. 6, 2003, which are incorporated herein by reference in their entirety.
TECHNICAL FIELDThe present invention relates generally to the field of commerce automation. More particularly, the present invention relates to a method and system for dealing, at least partially in an automated manner, with disputes between parties involved in electronic commerce.
BACKGROUNDA common type of a network-based transaction is purchasing goods or services via a network-based commerce facility or trading platform (e.g., a website on the Internet). One type of network-based transaction is an online-auction transaction. In an online-auction transaction, a seller offers an item for sale via an auction website in which a number of bidders access the website and bid for the item. A transaction is completed after the winning bidder pays for the item and the seller delivers the item to the winning bidder.
A common type of a network-based transaction is purchasing goods or services via a network-based commerce facility or trading platform (e.g., a website on the Internet). One type of network-based transaction is an online-auction transaction. In an online-auction transaction, a seller offers an item for sale via an auction website in which a number of bidders access the website and bid for the item. A transaction is completed after the winning bidder pays for the item and the seller delivers the item to the winning bidder.
A number of technical challenges exist with such a transaction such as a party to the transaction failing to follow through with the transaction. For example, the winning bidder may falsely claim that the seller did not deliver the auctioned item, fail to pay for the auctioned item, or provide a fraudulent check to purchase the item. In such a case, the bidder is referred to as a “non-paying bidder.” As a result of a failed transaction, the seller may request a refund for a fee that may have been charged by the network-based transaction facility to facilitate the transaction.
Another problem that may occur is a seller falsely claiming the auctioned item was shipped or that a transaction did not go through, to obtain a refund when in fact a valid sale occurred.
The conventional dangers of fraud and identity theft associated with network-based transactions are well known and present unique technical challenges to overcome in a quick and efficient manner. Thus, there is a need for dealing with disputes between parties involved in a network-based transaction. The automation of procedures to handle issues and disputes presents a number of unique technical problems and challenges.
SUMMARY OF AN EMBODIMENT OF THE INVENTIONA method and system for resolving disputes between parties involved in a network-based transaction is described. One aspect of the present invention seeks to automatically facilitate the restitution of value to parties of the transaction, for example, facilitated by a network-based commerce platform or involving a network-based payment service, where a dispute has arisen with respect to the transaction.
The present invention is illustrated by way of example and not intended to be limited by the figures of the accompanying drawings in which like references indicate similar elements and in which:
A method and system for resolving disputes between parties involved in electronic commerce is described. One aspect of the present invention seeks to facilitate the restitution of value to parties of a transaction, for example, facilitated by a network-based commerce platform or involving a network-based payment service, where a dispute has arisen with respect to the transaction. It will be appreciated that when an agreement is reached between parties to transact, that agreement imposes reciprocal obligations on each of the relevant parties. Where a dispute arises, one party may have performed an action to at least partially satisfy his or her obligations. For example, a buyer party to a transaction may have made payment to a seller party, where after the seller party has failed to perform by not delivering a transacted product or service to the buyer. Alternatively, a seller party may have shipped a product, or at least partially performed a service, to the benefit of the buyer party when a dispute arises and the buyer party fails to make a payment to the seller party.
According to one aspect, the present invention attempts to reduce abuse by parties failing to follow through with a transaction, for example, by automatically providing a party accused of failing to follow through in a transaction an opportunity to resolve or complete the transaction without (or at least with reduced) human interaction by operators of the network-based transaction facility. For one embodiment, a submission of a complaint is submitted to a network-based transaction facility. The complaint is related to a party in a failed transaction. A resolution of the complaint is facilitated and restitution is provided to one of the parties upon resolving the complaint.
In the following embodiments, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.
TerminologyIn the following embodiments, the term “transaction” or “transactions” refers to any communications between two or more entities and is to be construed to include, but not limited to, commercial transactions including sale and purchase transactions, online-auction transactions and other like transactions.
Transaction FacilityThe network-based transaction facility 110 includes one or more of a number of types of front-end servers, namely a pages servers 112 that delivers web pages (e.g., markup language documents), a pictures servers 114 that dynamically delivers images to be displayed within Web pages, a listing servers 116, a CGI servers 118 that provides an intelligent interface to the back-end of network-based transaction facility 110, and a search servers 120 that handles search requests to the network-based transaction facility 110. An email servers 121 provides, inter alia, automated email communications to users of the network-based transaction facility 110. The network-based transaction facility 110 also includes an administrative application(s) functions 128 for providing functions for applications running the network-based transaction facility 110.
The back-end servers include a database engine server 122, a search index server 124 and a credit card data server 126, each of which maintains and facilitates access to respective databases 123, 125, 127, respectively.
The Internet-based network-based transaction facility 110 may be accessed by a client program 130, such as a browser (e.g., the Internet Explorer® distributed by Microsoft Corp. of Redmond, Wash.) that executes on a client machine 132 and accesses the network-based transaction facility 110 via a network such as, for example, an Internet 134. Other examples of networks that a client may utilize to access the network-based transaction facility 110 include a wide area network (WAN), a local area network (LAN), a wireless network (e.g., a cellular network), or the Plain Old Telephone Service (POTS) network.
Database StructureCentral to the database 200 is a user table 240, which contains a record for each user of the network-based transaction facility 110. A user may operate as a seller, buyer, or both, within the network-based transaction facility 110. The database 200 also includes an items tables 242 that may be linked to the user table 240. Specifically, the items tables 242 include a seller item table 244 and a data items table 246. A user record in user table 240 may be linked to multiple items that are being, or have been, auctioned via network-based transaction facility 110. A link indicates whether the user is a seller or a bidder (or buyer) with respect to items for which records exist within the item tables 242. Database 200 also includes a note table 248 populated with note records that may be linked to one or more item records within the item tables 242 and/or to one or more user records within the user table 240. Each note record within the note table 248 may include, inter alia, a comment, description, history or other information pertaining to an item being auctioned via network-based transaction facility 110, or to a user of network-based transaction facility 110.
A number of other tables are also shown to be linked (directly or indirectly) to the user table 240, namely a user past aliases table 250, a feedback table 252, a feedback details table 253, a transaction record table 260, an account balances table 258, an accounts table 256, a bids table 254, a seller final value fee request table 270, a seller final value fee request details table 272, a non-paying bidder complaints table 262, a non-paying bidder complaint details table 264, and a dispute and request table 282.
Non-Paying Bidder Complaint/Final Value Fee Request Record TablesThe item no. column 302 stores item identifiers of items involved in failed transactions. The seller user ID column 304 stores user IDs of sellers who auctioned the item in item no. column 302. The NPB user ID column 306 stores user IDs of buyers who did not follow through on a transaction related to the items identified in the item no. column 302. The reason for failed transaction column 308 stores reasons why the transaction failed that may be given by a seller. For example, reasons may include a buyer failing to purchase an item or providing a fraudulent check to pay for the item.
The notice date column 310 stores the date a notice was sent to the respective buyer identified in the NPB user ID column 306 that he/she has not completed the transaction for the item identified in the respective item no. column 302. The notice reason column 312 stores the reasons why the notice was sent. For example, the notice can be sent because a seller filed a final value fee refund request or the seller filed a NPB alert against the buyer.
The NPB user ID column 402 stores the user IDs of buyers in which a complaint has been filed. The buyers listed in the NPB user ID column 402 are buyers involved in failed transactions. The item no. column 404 stores identifiers of items involved in transactions in which the buyer listed in the NPB user ID column 402 was the winning bidder and has failed to complete the transaction for the item.
The valid warning count column 406 stores a count value on the number of times the NPB received a warning for being a “non-paying bidder” or for failing to complete a transaction. The NPB tick column 408 stores the number of times the NPB has been involved in a failed transaction in which the NPB was at fault. The reason for NPB tick column 410 stores the reasons for the NPB ticks. The suspended status column 412 stores the status of the NPB to participate on the network-facility. For example, after a certain number of NPB ticks, the NPB can be suspended from participating in an on-line auction on the network-based facility.
The seller user ID column 502 stores the user IDs of sellers filing NPB complaints. The NPB user ID column 504 stores user IDs of buyers against which a NPB complaint has been filed. The date of complaint column 506 stores the date in which the NPB complaint was filed. The reason for complaint column 508 stores the reasons why the seller filed the NPB complaint. The status of complaint column 510 stores the status of the complaint. For example, the status can indicate that the complaint has been resolved or if it is pending.
The sellers user ID column 602 stores the user IDs of sellers filing a FVF refund request. The NPB user ID column 604 stores the user IDs of the NPB related to the FVF refund request by the seller. The item no. column 606 stores an identifier of the item related to the FVF refund request. The action desired column 608 stores the requests of the seller. The seller may request a refund or a credit for future transactions.
The reason for FVF credit column 610 stores the reason for the credit. For one embodiment, the following reasons are not valid reasons for filing a FVF credit: (1) the bidder paid, returned it and seller issued a refund; (2) Seller and Buyer mutually agreed not to complete the transaction; or (3) sale price to high bidder was lower than final high bid. The credit date column 612 stores the date in which a refund or a credit for future transactions was given. The credit amount column 614 stores the amount of the credit or refund given.
The item no. column 702 stores item identifiers related to failed transactions. The failed transaction has caused an NPB to have a “tick” or count against him in which the NPB is considered at fault. The seller user ID column 704 stores user IDs of sellers who auctioned the item in the item no. column 702 and filed a NPB complaint or alert against the NPB. The NPB user ID column 706 stores user IDs of buyers who did not follow through on a transaction related to the items identified in the item no. column 702.
The ‘reasons for failed transaction’ column 708 stores reasons why the transaction failed. For example, reasons may include a buyer failing to pay for an item, providing a fraudulent check to pay for the item, or falsely claiming the auctioned item was not received. The reason for appeal column 710 stores reasons why the NPB is appealing a NPB tick. A valid reason for appeal can be that the NPB did pay for the item and the seller is providing a false complaint to obtain a FVF refund or credit. The appeal code column 712 stores codes related to the appeal. For example, the codes can indicate if the appeal is granted and the NPB tick is taken away or if the appeal is denied.
The above record tables are exemplary and additional column entries or tables can be used by network-based transaction facility 110 to provide services such that users of network-based transaction facility 110 may file complaints for a bidder or buyer (“non-paying bidder”) who has failed to follow through on a transaction (e.g., an online auction sale). Furthermore, the network facility 100 can also provide a final value fee (FVF) refund request or credit service for sellers involved in a failed transaction. The network-based transaction facility 110 can also keep track of NPB and suspend the NPB if involved in more than a certain number of failed transactions.
In the following operations, a party is able to file a complaint against a bidder (“non-paying bidder”) who has failed to follow through on a transaction (e.g., an auction sale) after a certain period of time from the end of the sale. A notification is provided to the non-paying bidder (“NPB”) so that the seller and a bidder can communicate with each other to resolve the complaint or complete the transaction. If the parties cannot resolve the complaint after a certain period of time, the seller is allowed to file a FVF refund request for the FVF that the seller may have paid to facilitate the sale on the network-based facility. A NPB count or “tick” will be maintained for every failed transaction in which the NPB is involved.
Filing a Non-Paying Bidder Alert or ComplaintReferring to
At operation 806, if the seller does not wish to file a complaint or alert, operation 800 ends. If the seller does wish to file a complaint, operation 800 can continue to operation 826, 862, or 808. At operation 808, a determination is made if the seller has waited at least 7 days and no more than 30 days. The waiting period is to give the bidder an opportunity to complete the transaction before the seller can file a complaint or request a final value fee refund or request.
If the seller has not waited at least 7 days and no more than 30 days, operation 800 returns to operation 804. If after the 7 day waiting period, but before 30 days after end of auction, at operation 810, the seller may file a NPB complaint. For example, interfaces such as interfaces 1002 and 1010, as shown in
At operation 812, the information entered by the seller is captured or stored in a database such as that shown in
Referring to
-
- 1) Bidder paid, returned item and seller issued a refund;
- 2) The parties mutually agreed not to complete the transaction; or
- 3) Sale price too high and bidder bid price was lower than final high bid.
If the reasons for the complaint are at least one of the above reasons, operation 800 continues at operation 842 in
At operation 824, an email is sent to both bidder/buyer and seller informing the parties of the reason for complaint, item number, and that the bidder will get a NPB tick if the complaint is not resolved. The buyer is informed that the seller has filed a complaint. If the buyer believes the seller has made false statements, the buyer can inform the network-based transaction facility 110. For example, the buyer can send an email to a “safeharbor” within the network-based transaction facility 110.
At operation 826, the buyer and seller are asked to resolve differences among themselves. This notification can be a separate email or contained in the email of operation 824. For one implementation, the email to the NPB can encourage the buyer to leave negative feedback for the seller if the buyer responded during the mediation period and the seller did not respond and is now filing a FVF credit request.
At operation 828, a determination is made if the buyer and seller have resolved their differences (e.g., completed the transaction and/or satisfied obligations imposed by a transaction agreement). If the parties have not resolved their differences, operation 800 continues to operation 862 in
Referring to
At this point, the seller can request a FVF refund or credit because a transaction was not completed for valid reasons. At operation 844, a determination is made whether the seller wants to file a FVF refund or credit request. At operation 846, if the seller does not wish to file a FVF credit request, the seller can leave interfaces 1102, 1108, or 1120 and the process ends. If, however, the seller does wish to file a FVF credit request, operation 800 continues to operation 848.
At operation 848, the seller's user ID, item number, and reasons for complaint can be auto-populated on the online form. Alternatively, the seller can enter the aforementioned information as shown in windows 1104 and 1106 in
At operation 850, the FVF credit is automatically posted to seller's account. The buyer is not given a NPB tick because there was a valid reason on why the transaction was not completed. At operation 852, an email is sent to the buyer (cc: Seller) to inform the buyer that the seller has requested a FVF credit for the reasons given. The buyer is asked to email the “safeharbor” if this is not valid. For example, if the buyer did complete the transaction, then the seller is fraudulently requesting a FVF refund.
At operation 854, a determination is made if the buyer has sent an email to the “safeharbor.” If an email was not sent, at operation 856, the process ends and the seller is given a FVF credit. If the buyer does send an email to the “safeharbor”, at operation 858, the seller is not given a FVF credit and the process ends. Here, a further determination can be made by the network facility to inquire about the validity of the buyer's and seller's statements.
Filing a Non-Paying Bidder AppealReferring to
If a NPB complaint has been filed and 10 days or more have elapsed, operation 800 continues to operation 864. At operation 864, a determination is made if less than a predetermined time period (e.g., 60 days) has elapsed since the end of the auction. If more than 60 days have elapsed, at operation 866, operation 800 ends and no FVF credit request is filed. Here, approximately two months have passed since the auction, which exceeds a maximum time limit to file a FVF credit request.
If less than 60 days have elapsed since the end of the auction, at operation 868, a determination is made if the seller wants to file a FVF credit request. If the seller does not want to file a FVF credit request, operation 800 ends at operation 866. If the seller does want to file a FVF credit request, at operation 870, the seller is taken to the FVF online credit form such as that shown in interfaces 1102, 1108, or 1120 of
At operation 872, after the seller completes the FVF online form, the FVF credit is automatically posted to the seller's account and a NPB tick is given to the NPB. For example, the seller's account can be credited within 24 hours of a FVF credit request being filed. The NPB is notified via email that a tick has been given and is given the opportunity to appeal the tick.
At operation 874, a determination is made if the NPB wants to appeal the tick. If the NPB does not want to appeal the tick, operation 800 continues to operation 830. If the NPB does want to appeal the tick, the NPB is taken to an online NPB appeal form such as interface 1202 shown in
At interface 1202, the NPB is given a window 1204 to enter a user ID and password and a window 1206 to enter the item number. Interface 1202 also provides a window 1208 for the NPB to enter a message on why the tick should not be given to him. After the NPB completes the NPB appeal form, the network-based facility can give the NPB a confirmation such as interface 1302 shown in
For one embodiment, the NPB is given a maximum number of ticks (e.g., 3 ticks) before the NPB is suspended from participating in online auctions. If the NPB tick goes from 3 to 2, the NPB can be reinstated. If the FVF credit for the seller is reversed, the NPB tick can later be reversed and the tick can be removed. For another embodiment, the NPB must receive at least three NPB ticks from three different sellers before that bidder is automatically suspended. If, for example, a bidder receives three NPB ticks from Seller A and one NPB tick from Seller B, the bidder should not be automatically suspended (NPB tick score=2). However, the bidder should be flagged so that the operator of the network-based transaction facility may manually review the bidder and have the ability to suspend the bidder.
Submission of Complaints Between PartiesReferring to
The type column 1505 stores the type of dispute. The counterparty column 1510 stores a name of a counter party to the dispute. The transaction identifier column 1515 stores an identifier of the transaction record that is in dispute. The date column 1520 stores the date of the transaction in dispute. The amount column 1525 stores an amount of the transaction in dispute. The reason column 1530 stores a reason for the dispute. Examples of entries to be stored in the reason column 1530 include unauthorized, non-receipt, merchandise, duplicate, or other.
The filed on column 1535 stores the date the dispute was filed. The status column 1540 stores an indicator of the status of the dispute. For example, the entry stored in the status column 1540 may include “case closed,” “waiting for your response,” (which indicates when the dispute is waiting for a response from the accused party), and “reviewing your response,” (which indicates when the dispute is in a review workflow state). The action column 1545 stores an indication of an action to be performed by one of the parties to the transaction, such as “resolved” or “cancel.”
Referring to
At block 1601, the network-based transaction facility 110 receives a complaint from a party (e.g., a complaining party) to a transaction. For example, the network-based transaction facility 110 may receive a complaint from a buyer related to a transaction in dispute between the buyer and seller. For instance, the buyer may submit a complaint regarding a purchased item that has not been received from a seller related to the transaction.
In one embodiment, the complaint includes complaint information. The complaint information may include an identifier of the counter party (e.g., an accused party) to the dispute, the transaction identifier of the transaction in dispute, the date of the transaction, the amount of the transaction, the reason for the complaint, and the date the complaint was filed. The complaint information may be stored in the open dispute and request table 1500 as described above.
Upon submitting the complaint, the complaining party may view the complaint via the network-based transaction facility 110. For example,
The disputes table 1715 includes a type column 1720, a counterparty column 1725, a transaction ID column 1730, a date column 1735, an amount column 1740, a reason column 1745, a filed on column 1750, a status column 1755, and an action column 1760.
The type column 1720 displays the type of dispute. The counterparty column 1725 displays an identifier of the counterparty to the dispute. The transaction ID column 1730 displays an identifier of the transaction in dispute. In one embodiment, upon selecting a specific transaction ID, the user is shown additional details relating to the transaction in dispute.
The date column 1735 displays the date of the transaction in dispute. The amount column 1740 displays the amount in dispute. The reason column 1745 displays a brief reason for the complaint. The filed on column 1750 displays the date the complaint was received by the network-based transaction facility 110. The status column 1755 displays the current status of the complaint. In one embodiment, upon selecting a specific status indicator, the user is shown a chargeback details view relating to the complaint. For example,
At block 1603, the network-based transaction facility 110 determines whether the complaint is a ‘Not As Described’ (NAD) type complaint. In one embodiment, a NAD complaint indicates the buyer has received a purchased item that was not as described, for example, in an online listing for the item. If the complaint is a NAD type complaint, control passes to block 2503. If the complaint is not a NAD type complaint, control passes to block 1605.
At block 1605, the network-based transaction facility 110 determines whether the complaint includes tracking information for the shipped item. If the complaint includes tracking information, control passes to block 1650. If the complaint does not include tracking information, control passes to block 1607.
At block 1607, the network-based transaction facility 110 sends a request for resolution information, in the exemplary form of a resolution form, over the network to a second party to the transaction. The automatic submission of the resolution form allows an accused party to answer or appeal the submitted complaint. For example,
At block 1610, the network-based transaction facility 110 receives the requested resolution information (or response) over the network from the accused party.
At block 1612, the network-based transaction facility 110 determines whether the accused party selects to resolve the dispute by providing proof of a refund. If the proof of refund was indicated, control passes to block 1615. If the proof of refund was not indicated, control passes to block 1640.
At block 1615, the network-based transaction facility 110 sends a request for proof of the refund to the accused party. For example,
Referring again to
At block 1617, the network-based transaction facility 110 receives the proof of refund information.
At block 1623, the network-based transaction facility 110 confirms the proof of refund. For example, the network-based transaction facility 110 may confirm a refund issued via the network-based transaction facility 110 is valid by comparing the received proof of refund information with the records stored on the network-based transaction facility 110. Also, if the refund was issued with a facility other than the network-based transaction facility 110, the network-based transaction facility 110 may automatically or manually validate the refund information with a third party, such as a third party financial institution. If the refund is validated, control passes to block 1635. If the refund is not validated, control passes to block 1626.
At block 1626, the network-based transaction facility 110 approves the complaint. For example, the network-based transaction facility 110 may determine the complaint is valid and rejects the accused contention that a refund was made.
At block 1629, the network-based transaction facility 110 provides restitution to the complaining party. For example, the network-based transaction facility 110 may facilitate a refund payment, facilitate a partial refund payment, facilitate a stop payment, or facilitate the completion of the transaction (e.g., facilitate performance, such as facilitate payment or facilitate the delivery of the auctioned item), etc. For instance, the network-based transaction facility 110 may facilitate the transfer of funds from an account associated with the accused party to provide restitution to the complaining party.
At block 1632, the network-based transaction facility 110 notifies the parties of the decision. For example, the network-based transaction facility 110 may email both parties of the decision in favor of the complaining party and the decision that the accused party is to provide restitution to the complaining party. The notification may also include information related to the resolution of the complaint.
Referring back to block 1635, the network-based transaction facility 110 rejects the complaint. For example, the network-based transaction facility 110 may determine the complaint to be invalid based on the proof of refund information received from the accused party.
At block, 1637, the network-based transaction facility 110 notifies the parties of the decision. For example, the network-based transaction facility 110 may email both parties of the decision in favor of the accused party and may also include information related to the resolution of the complaint.
Referring back to block 1640, the network-based transaction facility 110 determines whether the accused party selected to resolve the dispute by providing tracking information (e.g., a tracking number, shipping carrier being used, date shipped, destination address, current location, etc.). If tracking information has been received, control passes to block 1642. If tracking information has not been received, control passes to block 1680.
At block 1642, the network-based transaction facility 110 sends a request for tracking information to the accused party. For example,
At block 1645, the network-based transaction facility 110 receives the shipping tracking information from the accused party.
At block 1650, the network-based transaction facility 110 determines whether the shipping tracking information is valid. For example, the network-based transaction facility 110 may electronically determine whether the shipping tracking information is valid based an automatic comparison of the received shipping tracking information and the tracking information stored on a computer of the related shipping carrier over a network. If the tracking information is valid, control passes to block 1655. If the tracking information is not valid, control passes to block 1665. In one embodiment, an agent associated with the shipping information will manually confirm the shipping tracking information with the related shipping carrier via telephone, fax, electronic mail, among other communications mechanisms well known to those or ordinary skill in the art.
At block 1655, the network-based transaction facility 110 rejects the complaint. For example, the network-based transaction facility 110 may reject the complaint because a purchased item is in transit based on the received shipping tracking information.
At block 1660, the network-based transaction facility 110 notifies the parties of the decision. For example, the network-based transaction facility 110 may email both parties of the decision in favor of the accused party and the decision based on the evidence that the item has been shipped to the complaining party. The notification may also include information related to the resolution of the complaint, such as the tracking information and other resolution information.
At block 1665, the network-based transaction facility 110 approves the complaint. For example, the network-based transaction facility 110 may approve the complaint because there is no proof the purchased item was sent to the complaining party based on the received tracking information.
At block 1670, the network-based transaction facility 110 provides restitution to the complaining party. For example, the network-based transaction facility 110 may facilitate a refund payment, facilitate a partial refund payment, facilitate a stop payment, or facilitate the completion of the transaction (e.g., facilitate performance, such as facilitate payment or facilitate the delivery of the auctioned item), etc.
At block 1675, the network-based transaction facility 110 notifies the parties of the decision. For example, the network-based transaction facility 110 may email both parties of the decision in favor of the complaining party and the decision that the accused party is to provide restitution to the complaining party. The notification may also include information related to the resolution of the complaint.
Referring back to block 1680, the network-based transaction facility 110 sends a request to accept liability to the accused party of the dispute. In one embodiment the network-based transaction facility 110 sends the accused party an online form prompting the accused party for any additional details explaining the non-performance. For example,
At block 1682, the network-based transaction facility 110 receives the accept liability information related to the complaint.
At block 1684, the network-based transaction facility 110 approves the complaint based on the accused party's expressed acceptance of liability.
At block 1685, the network-based transaction facility 110 provides restitution to the complaining party. For example, the network-based transaction facility 110 may facilitate a refund payment, facilitate partial refund payment, facilitate a stop payment, or facilitate the completion of the transaction (e.g., facilitate performance, such as facilitate payment or facilitate the delivery of the auctioned item), etc.
At block 1690, the network-based transaction facility 110 notifies the parties of the decision. For example, the network-based transaction facility 110 may email both parties of the decision in favor of the complaining party and the decision that the accused party is to provide restitution to the complaining party. The notification may also include information related to the resolution of the complaint, such as the reasons for non-performance.
At block 2503, the network-based transaction facility 110 sends a NAD form to the buyer. In one embodiment, an item is not as described if the seller misrepresents the item in a way that affects its value or usability. The NAD form enables the buyer to provide NAD information. For example, the NAD information may include information related to the condition of the purchase made by the buyer.
At block 2506, the network-based transaction facility 110 receives the NAD information from the buyer. NAD information may include, for example, information collected using the NAD dispute form 2600.
At block 2509, the network-based transaction facility 110 sends a Dispute Complaint Response Form to the seller. For example,
At block 2512, the network-based transaction facility 110 receives the NAD resolution information from the Seller. At decision block 2515, the network-based transaction facility 110 determines whether the seller provided an indication to refund the buyer for the NAD item. If the seller provides an indication to refund the buyer, control passes to block 2518. If the seller did not provide an indication to refund the buyer, control passes to block 2521.
At block 2518, the network-based transaction facility 110 facilitates payment of the refund to the buyer. In one embodiment, the network-based transaction facility 110 may automatically transfer the appropriate refund amount from a financial account of the seller to a financial account of the buyer.
At block 2521, the network-based transaction facility 110 determines whether the seller provided an indication to refund the buyer after the NAD item is returned. If the seller provided an indication to refund the buyer after the NAD item is returned, control passes to block 2524. If the seller did not provide an indication to refund the buyer after the NAD item is returned, control passes to block 2536.
At block 2524, the network-based transaction facility 110 notifies the buyer to return the NAD item and provide the tracking information (e.g., tracking number, shipping carrier being used, date shipped, destination address, current location, etc.).
At block 2527, the network-based transaction facility 110 receives the tracking information from the buyer.
At block 2530, the network-based transaction facility 110 sends the tracking number to the seller.
At block 2533, the network-based transaction facility 110 receives confirmation from the seller of receipt of the NAD item and facilitates a refund to the buyer. In one embodiment, the network-based transaction facility 110 may automatically transfer the appropriate refund amount from a financial account of the seller to a financial account of the buyer.
At decision block 2536, the network-based transaction facility 110 determines whether the seller provided an indication to provide a partial refund to the buyer. If the seller provides an indication to negotiate a partial refund with the buyer for the NAD item, control passes to block 2537. If the seller does not provide an indication to negotiate a partial refund with the buyer for the NAD item, control passes to block 2551.
At block 2537, the network-based transaction facility 110 sends the seller a partial refunds form to the seller to obtain the partial refund amount offered by the seller to the buyer for the NAD item. In this fashion, both parties may negotiate a fair price for the item without human intervention. For example,
At block 2538, the network-based transaction facility 110 receives the partial refund amount offer from the seller.
At block 2539, the network-based transaction facility 110 notifies the buyer of the partial refund amount offer. In this fashion, the buyer may decide whether to accept the partial refund amount. In one embodiment, the buyer may offer a counter-proposal, by which the seller and buyer may continue to negotiate a final partial refund amount.
At block 2542, the network-based transaction facility 110 receives the response to the partial refund offer amount from the buyer.
At decision block 2542, the network-based transaction facility 110 determines whether the buyer agrees to the partial refund offer. If the buyer agrees to the partial refund offer, control passes to block 2545. If the buyer does not agree to the partial refund offer, control passes to block 2548.
At block 2545, the network-based transaction facility 110 facilitates the payment of the partial refund to the buyer. In one embodiment, the network-based transaction facility 110 may automatically transfer the appropriate refund amount from a financial account of the seller to a financial account of the buyer; automatically prepare a check to be mailed to the buyer, etc.
Referring back to decision block 2551, the network-based transaction facility 110 determines whether the seller provided an indication to provide a proof of refund. If the seller provided an indication to provide a proof of refund, control passes to block 1612 and the process flow continues as described above. If the seller did not provide an indication to provide a proof of refund, control passes to block 2554.
At decision block 2554, the network-based transaction facility 110 determines whether the buyer indicated the reason for the NAD complaint is because of an empty box or a different category, for example as described above. If the complaint is for an empty box/different category, control passes to block 2557. If the complaint is not for an empty box/different category, control passes to block 2563.
At block 2557, the network-based transaction facility 110 requests the buyer to provide a copy of a police report regarding the empty box item or of a different category. In this fashion, for example, the submission of frivolous complaints may be reduced. In one embodiment, the network-based transaction facility 110 might also only require a police report if the cost of the item is greater than a predetermined amount (e.g., $200).
At block 2560, the network-based transaction facility 110 receives a copy of the police report. In one embodiment, the network-based transaction facility 110 receives a scan copy of the police report or a faxed copy of the police report.
At block 2563, the network-based transaction facility 110 sends a disagree with complaint form to the seller. For example,
At block 2566, the network-based transaction facility 110 receives an explanation from the seller.
At block 2548, the network-based transaction facility 110 performs an investigation of the complaint. The network-based transaction facility 110 may perform the investigation automatically without human intervention, with human intervention, or a combination of both. Both parties will be notified of the results of the investigation. The investigation may determine to accept the complaint from the buyer and therefore, require the seller to refund the buyer. Alternatively, the investigation may determine to reject the complaint and end the investigation. In one embodiment, if the complaint is accepted, the buyer is required to return the item and provide tracking information (form not shown). After the network-based transaction facility 110 confirms the seller has received the returned item, the network-based transaction facility 110 will facilitate the refund of funds to the buyer. In one embodiment, the network-based transaction facility 110 may automatically transfer the appropriate refund amount from a financial account of the seller to a financial account of the buyer; prepare a check to be mailed to the buyer, etc.
In one embodiment, the network-based transaction facility 110 might also request additional information, as evidence, from which to base the decision, such as a certificate of authentication from a third party, a digital photo of the disputed item, affidavits from a third party regarding the disputed item, additional police reports, etc. This additional information may be provided to the network-based transaction facility 110 electronically or by other means.
In one embodiment, a third party agent may view the information related with each dispute within a view (not shown), including the complaint, response to the complaint, and negotiation of partial refund, etc. Furthermore, each complaint may be prioritized for view based on the transaction amount, language, a service level agreement, etc.
It should be understood that the process flows 1600 and 2500 are not limited to the blocks as described above. For example, the network-based transaction facility 110 may wait a predetermined amount of time for responses from the parties and/or remind parties to reply to requests for information within a predetermined amount of time. Furthermore, the network-based transaction facility 110 may automatically accept the complaint, reject the complaint, and/or facilitate the performance of restitution if a party to the transaction does not respond within a predetermined amount of time. For example, if the seller does not respond to a complaint within 10 days, the network-based transaction facility 110 will approve the complaint. However, longer wait periods may be necessary to accommodate international shipping times (e.g., 15 calendar days).
It should also be understood that the information exchanged in the process flows 1600 and 2500, as shown in
Furthermore, it is understood that the notification of the buyer and seller as described above is not limited to using online forms, as described above. Rather, one of ordinary skill in the art will recognize additional mechanisms may be used to notify the parties including electronic mail, and text messaging, among other examples.
Exemplary Computing SystemThe computer system 3000 includes a processor 3002, a main memory 3004 and a static memory 3006, which communicate with each other via a bus 3008. The computer system 3000 may further include a video display unit 3010 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 3000 also includes an alpha-numeric input device 3012 (e.g., a keyboard), a cursor control device 3014 (e.g., a mouse), a disk drive unit 3016, a signal generation device 3020 (e.g., a speaker) and a network interface device 3022.
The disk drive unit 3016 includes a machine-readable medium 3024 on which is stored a set of instructions (i.e., software) 3026 embodying any one, or all, of the methodologies described above. The instructions 3026 is also shown to reside, completely or at least partially, within the main memory 3004 and/or within the processor 3002. The instructions 3026 may further be transmitted or received via the network interface device 3022. For purposes of this specification, the term “machine-readable medium” shall be taken to include any medium that is capable of storing or encoding a sequence of instructions for execution by the machine and that cause the machine to perform any one of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to include, but not limited to, solid-state memories, optical and magnetic disks, and carrier wave signals.
It will be appreciated that more or fewer processes may be incorporated into the method(s) illustrated in
The exemplary embodiments of the present invention have been discussed above within the context of a network-based transaction facility 110, which operates as a platform by which parties can establish an agreement to transact. It will, of course, be appreciated that the present invention is not limited to use within the context of such a trading platform, and may be deployed by any platform or service that is involved in a transaction. For example, the present invention could be deployed by a payment service that facilitates the transfer of funds between parties, a shipping service that is involved in the physical transport of products between parties or a services platform that allows one party to deliver a service to another party in exchange for value. The term “network-based transaction facility” should be construed to include a network-based trading platform, a payment service, a shipping service, or a services-delivery platform, for example.
Thus, a method and system for dealing with non-performing parties related to network-based transactions has been described. In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than in a restrictive sense.
Claims
1. A method comprising:
- receiving a complaint from a first party to a transaction, the complaint being associated with the transaction on a network-based commerce facility, the first party being obligated to pay a transaction fee relating to the transaction;
- determining, one or more processors, that the complaint includes a valid reason to provide restitution of the transaction fee;
- sending a request to a second party to the transaction, the request including the reason, the request requesting from the second party a notification specifying that the complaint is fraudulent; and
- based on the notification specifying that the complaint is fraudulent not being received from the second party within a predetermined amount of time, providing restitution of the transaction fee to the first party.
2. The method of claim 1, wherein the first party is a seller of an item listed on the network-based commerce facility and the second party is a bidder on the item.
3. The method of claim 2, wherein the valid reason does not include any of the following reasons: (1) the bidder paid for the item, but then returned the item and received a refund from the seller, (2) the seller and the buyer mutually agreed not to complete the transaction, or (3) the bidder bid an amount that was lower than the final high bid for the item.
4. The method of claim 2, wherein the valid reason includes one of the following reasons (1) the bidder did not provide payment for the item, (2) the bidder provided a fraudulent form of payment for the item, or (3) the bidder falsely claimed that the item was not received by the buyer.
5. The method of claim 1, further comprising, based on the notification specifying that the complaint is fraudulent not being received from the second party in the predetermined amount of time, increasing a count associated with the second party, the count representing a number of failed transactions in which the second party was at fault, and suspending the second party from participating on the network-based commerce facility based on the count reaching a threshold count.
6. The method of claim 5, further comprising receiving a valid reason for an appeal from the second party, making a determination to grant the appeal, and based on the making of the determination to grant the appeal, decreasing the count associated with the second party and reinstating the second party to participate on the network-based commerce facility based on the count falling below the threshold count.
7. The method of claim 6, wherein the valid reason for the appeal includes an assertion by the second party that the complaint received from the first party is false.
8. A system comprising:
- one or more modules implemented by one or more processors, the one or more modules configured to:
- receive a complaint from a first party to a transaction, the complaint being associated with the transaction, the first party being obligated to pay a transaction fee relating to the transaction;
- determine that the complaint includes a valid reason to provide restitution of the transaction fee;
- send a request to a second party to the transaction, the request including the reason, the request requesting from the second party a notification specifying that the complaint is fraudulent; and
- based on the notification specifying that the complaint is fraudulent not being received from the second party within a predetermined amount of time, provide restitution of the transaction fee to the first party.
9. The system of claim 8, wherein the first party is a seller of an item listed on the network-based commerce facility and the second party is a bidder on the item.
10. The system of claim 9, wherein the valid reason does not include any of the following reasons: (1) the bidder paid for the item, but then returned the item and received a refund from the seller, (2) the seller and the buyer mutually agreed not to complete the transaction, or (3) the bidder bid an amount that was lower than the final high bid for the item.
11. The system of claim 9, wherein the valid reason includes one of the following reasons (1) the bidder did not provide payment for the item, (2) the bidder provided a fraudulent form of payment for the item, or (3) the bidder falsely claimed that the item was not received by the buyer.
12. The system of claim 8, wherein the one or more modules are further configured to, based on the notification specifying that the complaint is fraudulent not being received from the second party in the predetermined amount of time, increase a count associated with the second party, the count representing a number of failed transactions in which the second party was at fault, and suspend the second party from participating on the network-based commerce facility based on the count reaching a threshold count.
13. The system of claim 12, wherein the one or more modules are further configured to receive a valid reason for an appeal from the second party, make a determination to grant the appeal, and based on the making of the determination to grant the appeal, decrease the count associated with the second party and reinstate the second party to participate on the network-based commerce facility based on the count falling below the threshold count.
14. The system of claim 13, wherein the valid reason for the appeal includes an assertion by the second party that the complaint received from the first party is false.
15. A non-transitory computer-readable medium comprising a set of instructions that, when executed by at least one processor of a computer system, cause the computer system to perform operations, the operations comprising:
- receiving a complaint from a first party to a transaction, the complaint being associated with the transaction, the first party being obligated to pay a transaction fee relating to the transaction;
- determining that the complaint includes a valid reason to provide restitution of the transaction fee;
- sending a request to a second party to the transaction, the request including the reason, the request requesting from the second party a notification specifying that the complaint is fraudulent; and
- based on the notification specifying that the complaint is fraudulent not being received from the second party within a predetermined amount of time, providing restitution of the transaction fee to the first party.
16. The non-transitory computer-readable medium of claim 15, wherein the first party is a seller of an item listed on the network-based commerce facility and the second party is a bidder on the item.
17. The non-transitory computer-readable medium of claim 16, wherein the valid reason does not include any of the following reasons: (1) the bidder paid for the item, but then returned the item and received a refund from the seller, (2) the seller and the buyer mutually agreed not to complete the transaction, or (3) the bidder bid an amount that was lower than the final high bid for the item.
18. The non-transitory computer-readable medium of claim 16, wherein the valid reason includes one of the following reasons (1) the bidder did not provide payment for the item, (2) the bidder provided a fraudulent form of payment for the item, or (3) the bidder falsely claimed that the item was not received by the buyer.
19. The non-transitory computer-readable medium of claim 15, the operations further comprising, based on the notification specifying that the complaint is fraudulent not being received from the second party in the predetermined amount of time, increasing a count associated with the second party, the count representing a number of failed transactions in which the second party was at fault, and suspending the second party from participating on the network-based commerce facility based on the count reaching a threshold count.
20. The non-transitory computer-readable medium of claim 19, the operations further comprising receiving a valid reason for an appeal from the second party, making a determination to grant the appeal, and based on the making of the determination to grant the appeal, decreasing the count associated with the second party and reinstating the second party to participate on the network-based commerce facility based on the count falling below the threshold count.
Type: Application
Filed: Jan 6, 2014
Publication Date: Oct 2, 2014
Applicant: eBay Inc. (San Jose, CA)
Inventors: Huey Lin (Mountain View, CA), Max R. Levchin (Palo Alto, CA), Gina Han (Sunnyvale, CA), Ted Levan (San Francisco, CA), Daniele Levy (San Francisco, CA), Chris McGraw (Sunnyvale, CA), Erik Klein (Sunnyvale, CA), Greg Cervelli (San Jose, CA), Steven Wo (San Jose, CA), Carl Freeland (Palo Alto, CA), May Chen (San Jose, CA), Kristen Wilson (Mountain View, CA), Jason Nielson (Omaha, NE), Kyle Haffey (Omaha, NE), Julie Gonzales (Omaha, NE), Denise Aptekar (Omaha, NE)
Application Number: 14/148,526
International Classification: G06Q 50/18 (20060101); G06Q 20/10 (20060101);