This method is used if the seller wishes to contest a payment dispute initiated by the buyer. The unique identifier of the payment dispute is passed in as a path parameter, and unique identifiers for payment disputes can be retrieved with the getPaymentDisputeSummaries method.
Note: Before contesting a payment dispute, the seller must upload all supporting files using the addEvidence and updateEvidence methods. Once the seller has officially contested the dispute (using contestPaymentDispute), the addEvidence and updateEvidence methods can no longer be used. In the evidenceRequests array of the getPaymentDispute response, eBay prompts the seller with the type of supporting file(s) that will be needed to contest the payment dispute.
If a seller decides to contest a payment dispute, that seller should be prepared to provide supporting documents such as proof of delivery, proof of authentication, or other documents. The type of supporting documents that the seller will provide will depend on why the buyer filed the payment dispute.
The revision field in the request payload is required, and the returnAddress field should be supplied if the seller is expecting the buyer to return the item. See the Request Payload section for more information on these fields.
This method is supported in Sandbox environment. To access the endpoint, just replace the
apiz.ebay.com root URI with
|payment_dispute_id||string||This is the unique identifier of the payment dispute. This path parameter must be passed into the call URI to identify the payment dispute for which the user plans to contest. This identifier is automatically created by eBay once the payment dispute comes into the eBay system. The unique identifier for payment disputes is returned in the paymentDisputeId field in the getPaymentDisputeSummaries response.|
This path parameter is required, and the actual identifier value is passed in right after the payment_dispute resource. See the Resource URI above.
All requests made to eBay REST operations require you to provide the
Authorization HTTP header for authentication authorization.
In addition, this method requires you to include the Content-Type header and its value should be set to "application/json". See HTTP request headers- opens rest request components page for details.
This request requires an access token created with the client credentials grant flow, using one or more scopes from the following list (please check your Application Keys page for a list of OAuth scopes available to your application):
See OAuth access tokens for more information.
This field shows information that the seller provides about the dispute, such as the basis for the dispute, any relevant evidence, tracking numbers, and so forth.
This container is needed if the seller is requesting that the buyer return the item. If this container is used, all relevant fields must be included, including fullName and primaryPhone.
The first line of the street address.
The second line of the street address. This line is not always necessarily, but is often used for apartment number or suite number, or other relevant information that can not fit on the first line.
The city of the return address.
The country's two-digt, ISO 3166-1 country code. See the enumeration type for a country's value.
The county of the return address. Counties are not applicable to all countries.
The full name of return address owner.
The postal code of the return address.
This container shows the seller's primary phone number associated with the return address.
The seller's country calling code. This field is needed if the buyer is located in a different country than the seller. It is also OK to provide if the buyer and seller are both located in the same country. For a full list of calling codes for all countries, see the countrycode.org site.
The seller's primary phone number associated with the return address. When this number is provided in a contestPaymentDispute or contestPaymentDispute method, it is provided as one continuous numeric string, including the area code. So, if the phone number's area code was '408', a number in this field may look something like this:
The state or province of the return address.
This integer value indicates the revision number of the payment dispute. This field is required. The current revision number for a payment dispute can be retrieved with the getPaymentDispute method. Each time an action is taken against a payment dispute, this integer value increases by 1.
This call has no response headers.
This call has no payload.
This call has no field definitions.
This call can return one of the following HTTP status codes. For an overview of the status codes, see HTTP status codes in Using eBay RESTful APIs.
|500||Internal Server Error|
For more on errors, plus the codes of other common errors, see Handling errors.
|33000||API_FULFILLMENT||APPLICATION||There was a problem with an eBay internal system or process. Contact eBay developer support for assistance.|
|33011||API_FULFILLMENT||REQUEST||There was a change in payment dispute attributes. Please use get payment dispute api to get latest details.|
|33100||API_FULFILLMENT||REQUEST||Invalid input request|
|33101||API_FULFILLMENT||REQUEST||Invalid payment dispute state|
|33102||API_FULFILLMENT||REQUEST||No evidence available for contest|
This call has no warnings.
New to making API calls? Please see Making a Call.
Note: Identifiers, such as order IDs or user IDs, and personal data in these samples might be anonymized or may no longer be active on eBay. If necessary, substitute current, relevant eBay data in your requests.
The seller contests a payment dispute. The unique identifier of the payment dispute is passed in as a path parameter.
After passing in the unique identifier of the payment dispute as a path parameter, the seller sets the revision value and provides the return address where the buyer will return the item.
With a successful call, an http status code of
204 Success is returned. This method has no response payload.