Skip to content

    Dispute Case Management


    The Dispute Case Management API provides the following methods:

    • Create dispute API (/dispute) will create dispute/claim in NETS Chargeback system based upon the card number and transaction details provided in the request.

    • Get dispute API (/disputes) to fetch cases from NETS Chargeback system (CBK) based upon case group number or case number or cardnumber

    • Update Dispute API(/dispute) Update an existing dispute case to perform submit/close/reject/acknowlegde closure of the dispute/case with additional documents / notes / additional information

    • Document API (document) This API will fetch single dispute document at a time based upon the document Id

    • Search Case API (/disputeQueue) will return the Cases from NETS Chargeback system from particular Claim Queue based upon the queue ID parameter Examples: 1000 - 1st Line Issuer 2000 - 1st Line NETS 3000 - Case Handling Not Possible 4000 - Closed Supercase 5000 - Awaiting Issuer Feedback 6000 - Awaiting Dispute Submission 7000 - Issuer Disputes

    Environments and base addresses

    All communication between your site and Nets Dispute Case Management is managed over HTTPS. The Dispute Case Management APIs are collected under the following base addresses:

    EnvironmentBase address


    All API requests are required to include a valid Authorization header. This header should contain your secret API key for the environment (Test or Live) you are currently using.

    The secret API key should only be passed between your server and a Nets endpoint. The secret API key should never be used from the client side of your site / app for security reasons.

    Requests and responses

    The Dispute Case Management APIs follow the RESTful architectural style. A set of resources can be accessed using some of the endpoints provided by the APIs. To retrieve, add, or update resources, you use the associated HTTP methods for these actions:

    GETRetrieves a resource (idempotent, will never mutate a resource)
    POSTCreates a new resource. A JSON object, provided by you, describes the resource.
    PUTUpdates an existing resource. A JSON object, provided by you, describes the changes.


    You can pass parameters to the Dispute Case Management APIs using:

    • Header parameters. Authorization.
    • Path parameters. For example, the documentId in the path /v1/disputes/document/{documentId}.
    • JSON objects. Some requests, typically POST and PUT, expect you to pass JSON objects to the Dispute Management API (for example the getDispute request body.

    Retries and idempotent keys

    Most HTTP methods are idempotent, meaning that sending the same HTTP request multiple times to the server will not change the state of the server. In case of a network failure, it is always safe to retry an idempotent request. However, POST requests usually create new resources on the server side and cannot be retried safely by default. Using an idempotency key makes it safe for clients to retry POST requests that failed due to network failures.

    Was this helpful?

    What was your feeling about it?