Chargebackhit API Reference

Download OpenAPI specification:Download

Enhance your understanding with our detailed business guide.

Support: support@chargebackhit.com

Get started

Chargebackhit provides API that empowers you to process and manage alerts. Chargebackhit APIs accept and return JSON in the HTTP body. You can interact with the APIs directly using your preferred HTTP/REST library or one of the client libraries provided by Chargebackhit.

Environment Base URL
Webhook https://api.chargebackhit.com/client-webhook-endpoint
Integration https://api.chargebackhit.com/api/v2/integration
Alerts https://api.chargebackhit.com/api/v2/alerts
MIDs https://api.chargebackhit.com/api/v2/caids
Enrollment https://api.chargebackhit.com/api/v2/import
Event handling in Webhooks

For non-ordered events, adopt practices like temporarily storing webhooks before processing, using Chargebackhit's API for additional data in case of event collisions, and processing events asynchronously to avoid timeout issues.

Authentication

When you sign up for an account, you are given a secret and public API key pair. You authenticate with our API by providing the appropriate key in the request Authorization header. Never share your secret keys. Keep them guarded and secure.

To start accepting alerts, even in the sandbox environment, you need credentials. You can easily find your credentials in the admin panel. The signature value is base64-encoded from the SHA-512 hash function. Apply the merchant's secret key for the encryption key, and use the following string for signature data:
base64encode(sha512(public_key + requestJsonData + public_key))

PHP
Python
JavaScript
GO
Kotlin

To access the detailed information mentioned above, navigate to guide.

Integration

The Chargebackhit provides the following main requests for testing integration:

  • Generate sandbox alert for creating simulated alerts to test and validate integrations in a secure environment
  • Response outcome for effectively communicating chargeback and outcomes while maintaining secure and accurate data sharing.

Both requests offer appropriate response codes to help users identify successful integrations, bad requests, or unauthorized access.

Generate sandbox alert

The primary purpose of this request is to support the testing and validation of Chargebackhit integrations in a controlled environment. The request aims to create simulated alerts for testing purposes. This request ensures secure communication through the use of request signatures and public keys. It contains comprehensive information about the alert.

The request also gathers essential card-related details, such as the card acceptor ID, etc. Additionally, it encompasses merchant details, including their identification, name, and payment descriptor.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Request Body schema: application/json
required
object

All information about it.

This includes information such as the date the alert was published, the alert amount with currency, alert type, etc.

required
object

Data associated with the alert transaction, used for matching the alert to the transaction.

This includes information such as the date the transaction was created, the transaction amount with currency, transaction type, etc.

required
object

All information about the Merchant Identification (MID).

This includes information such as the unique identifier for the merchant, internal ID, payment descriptor, etc.

Responses

Request samples

Content type
application/json
{
  • "alert": {
    },
  • "transaction": {
    },
  • "merchant": {
    }
}

Response samples

Content type
application/json
{
  • "error": {
    }
}

Validate outcome

The primary purpose of the request is to facilitate effective communication of chargeback and outcomes while ensuring secure and accurate data sharing. The request is designed to process and communicate the outcome of a chargeback.

The request encompasses detailed information about the order, refund, customer, device, transactions, products, and merchant, including various identifiers, dates, amounts, currencies, and contact details. It also covers relevant URLs related to the merchant's policies and terms.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Request Body schema: application/json
outcome
required
string
Enum: "reversed" "previously-reversed" "decline" "reverse-error" "shipped" … 3 more

Standard required response codes.

Upon receiving a webhook alert, promptly provide a valid response. Only the initial response is accepted unless set to pending. No modifications are allowed after submission.

object

All information about the order.

This includes information such as the order ID, the date the order was created, the order amount with currency, etc.

object

All information about the customer.

This includes information such as the customer ID, personal data, device information, etc.

Array of objects

All information about the transactions.

This includes information such as the order ID, the date the order was created, the order amount with currency, etc.

Array of objects

All information about the purchased products.

This includes information such as the product name, SKU, description, etc.

object

All information about the merchant.

This includes information such as the merchant's payment terms, refund policy, warranty terms, etc.

Responses

Request samples

Content type
application/json
{
  • "outcome": "reversed",
  • "order": {
    },
  • "customer": {
    },
  • "transactions": [
    ],
  • "products": [
    ],
  • "merchant": {}
}

Response samples

Content type
application/json
{
  • "error": {
    }
}

Manage alerts

This section ensures seamless and efficient management of alerts and outcomes within the Chargebackhit.

Update response outcome allows for efficient and secure updates of alert outcomes, ensuring up-to-date information. Get alert by ID facilitates secure access to detailed information about a specific alert, while alert list enables users to securely and effectively retrieve tailored lists of alerts based on various filtering parameters.

Update response outcome

This request facilitates efficient and secure updating of alert outcomes within the Chargebackhit.

The primary purpose of a request in the Chargebackhit is to update the outcome of a previously submitted alert. This request allows users to provide an updated response outcome for a specific alert identified by its unique identifier (UUID).

path Parameters
id
required
string <uuid>

Unique identifier for the entity.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Request Body schema: application/json
outcome
required
string
Enum: "reversed" "previously-reversed" "decline" "reverse-error" "not-found" … 3 more

Standard required response codes.

Upon receiving a webhook alert, the primary task is to promptly provide a valid response using one of the outcomes.

object

It contains identifier for the order.

Responses

Request samples

Content type
application/json
{
  • "outcome": "reversed",
  • "order": {
    }
}

Response samples

Content type
application/json
{
  • "error": {
    }
}

Get alert by ID

This request allows users to securely and efficiently access detailed information about a specific alert within the Chargebackhit.

The main purpose of a request in the Chargebackhit is to retrieve detailed information about a specific alert using its unique identifier (UUID). This request allows users to access and review the alert's data, including the alert's details, associated transaction data, and merchant information.

path Parameters
id
required
string <uuid>

Unique identifier for the entity.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Responses

Response Schema: application/json
Array of objects

Detailed information about a specific alert.

This includes information such as the alert details, transaction data, and merchant identification (MID).

Response samples

Content type
application/json
{
  • "data": [
    ]
}

Retrieve alerts list

This request allows users to securely and effectively retrieve a tailored list of alerts from the Chargebackhit based on a wide range of filtering parameters, ensuring the retrieval of relevant information.

The main purpose of the request in the Chargebackhit is to retrieve a list of alerts based on various filtering parameters, including alert types, outcomes, providers, products, transaction details, and merchant-related information. This request allows users to narrow down and access specific sets of alerts based on their requirements.

Additionally, the request provides pagination options to limit the number of results, helping manage network traffic and improve efficiency.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Request Body schema: application/json
object

Set of parameters used for detailed filtering.

This includes parameters such as system account IDs, merchant IDs, transaction IDs, alert dates, etc.

object

The fields must be indexed to be sorted by them.

Thereafter, you can select which parameters to sort by.

object

Pagination to limit the number of results to help keep network traffic in check.

Responses

Response Schema: application/json
Array of objects

Detailed information about a specific alert.

This includes information such as the alert details, transaction data, and merchant identification (MID).

object

Pagination to limit the number of results to help keep network traffic in check.

Request samples

Content type
application/json
{
  • "filter": {
    },
  • "sort": {
    },
  • "pagination": {
    }
}

Response samples

Content type
application/json
{
  • "data": [
    ],
  • "pagination": {
    }
}

Webhook

Webhooks are a simple yet powerful way to receive automated notifications from Chargebackhit.

With Webhooks, you can set up your application to receive notifications whenever certain alert events occur and make instant action and applicable responses.

Webhook

In the Chargebackhit webhooks implementation, there are several types of webhooks based on the alert type parameter.

  • Prevent webhooks are triggered when a transaction inquiry occurs that requires an immediate response - sharing transaction details, including order, customer, and product. Prevent represents the inquiry and prevented webhook alert types. Prevent includes Order Insight (OI), Compelling Evidence (CE3.0), and Consumer Clarity (CC). All transaction data can affect and increase a cardholder and issuer experience. The more valid and relevant data provided, the more effective the response can be. In addition to the basic value of Prevent, the Compelling Evidence 3.0 rule aims to deflect fraud disputes when specific conditions are met and valid mandatory fields are transferred. The mandatory fields are highlighted with the CE3.0 badges.

  • Resolve webhooks are triggered when a merchant-directed refund is needed to resolve a potential dispute case or automated pre-dispute resolution has occurred. Merchant-directed refunds are notified by the alert type init-refund (CDRN, ETHOCA), while automated pre-dispute resolutions are notified by the alert type resolved (RDR).

  • Inform webhooks are triggered when a Visa Fraud or Dispute case is filed with alert types fraud-notification or dispute-notification, respectively.

Prevent, Resolve, and Inform webhooks have a unified structure and need to be distinguished by the alert type, with specific products and providers specified in the corresponding fields.

The responses should be in accordance with the specified alert type.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Request Body schema: application/json
required
object

All information about it.

This includes information such as the date the alert was published, the alert amount with currency, alert type, etc.

required
object

Data associated with the alert transaction, used for matching the alert to the transaction.

This includes information such as the date the transaction was created, the transaction amount with currency, transaction type, etc.

required
object

All information about the Merchant Identification (MID).

This includes information such as the unique identifier for the merchant, internal ID, payment descriptor, etc.

Responses

Response Schema: application/json
One of
outcome
required
string
Default: "acknowledged"

Standard required response codes.

object

All information about the order.

This includes information such as the order ID, the date the order was created, the order amount with currency, etc.

required
object

All information about the customer.

This includes information such as the customer ID, personal data, device information, etc.

Array of objects

All information about the related transactions.

This includes information such as the transaction ID, transaction creation date, amount, currency, etc.

required
Array of objects

All information about the purchased products.

This includes information such as the product name, SKU, description, etc.

object

Cardholder/Issuer Experience

Information about the merchant, including their contacts, policies, and more, can be provided as a default during MID enrollment.

If such parameters are not transmitted by the merchant, Chargebackhit will send them by default using the information provided during the onboarding process.

Request samples

Content type
application/json
{
  • "alert": {
    },
  • "transaction": {
    },
  • "merchant": {
    }
}

Response samples

Content type
application/json
Example
{
  • "outcome": "acknowledged",
  • "order": {
    },
  • "customer": {
    },
  • "transactions": [
    ],
  • "products": [
    ],
  • "merchant": {}
}

MIDs

The API offers comprehensive tools for managing and analyzing merchant and CAID data, enabling businesses to assess risk levels, and create holistic risk profiles.

Get merchant

This request allows retrieving specific merchant details using a unique identifier id. The response includes the merchant's id, name, and payment descriptor.

path Parameters
id
required
string <uuid>

Unique identifier for the entity.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Responses

Response Schema: application/json
object

All information about the Merchant Identification (MID).

This includes information such as the unique identifier for the merchant, internal ID, payment descriptor, etc.

Response samples

Content type
application/json
{
  • "data": {
    }
}

Update merchant

The method to update individual MID (Merchant) details using a unique identifier id.

path Parameters
id
required
string <uuid>

Unique identifier for the entity.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Request Body schema: application/json
internal_id
string <= 500 characters

Internal ID or something else that you uses to identify your mid (field merchant_internal_id from enrollment).

Responses

Response Schema: application/json
object

All information about the Merchant Identification (MID).

This includes information such as the unique identifier for the merchant, internal ID, payment descriptor, etc.

Request samples

Content type
application/json
{
  • "internal_id": "mid_QWE12345"
}

Response samples

Content type
application/json
{
  • "data": {
    }
}

Get merchant list

This request provides list of retrieves merchant lists using flexible filtering, sorting, and pagination options. Users can paginate results, sort by specified fields, and filter by parameters like ids, descriptors, and names. The response contains merchant details and pagination information.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Request Body schema: application/json
object

Set of parameters used for detailed filtering.

This includes parameters such as system account IDs, internal IDs, payment descriptors, etc.

object

The fields must be indexed to be sorted by them.

Thereafter, you can select which parameters to sort by.

object

Pagination to limit the number of results to help keep network traffic in check.

Responses

Response Schema: application/json
Array of objects

All information about the Merchant Identification (MID).

This includes information such as the unique identifier for the merchant, internal ID, payment descriptor, etc.

object

Pagination to limit the number of results to help keep network traffic in check.

Request samples

Content type
application/json
{
  • "filter": {
    },
  • "sort": {
    },
  • "pagination": {
    }
}

Response samples

Content type
application/json
{
  • "data": [
    ],
  • "pagination": {
    }
}

Get CAID

Method to retrieve individual CAID (Card Acceptor ID) details using a unique identifier id.

path Parameters
id
required
string <uuid>

Unique identifier for the entity.

query Parameters
include
Array of arrays
Items Value: "caid.activities"

Include the product activations.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Responses

Response Schema: application/json
object

All information about retrieving individual CAID details.

This includes parameters such as system CAID ID, creation date, active status, merchant details, etc.

Response samples

Content type
application/json
{
  • "data": {
    }
}

Update CAID

The method to update individual CAID (Card Acceptor ID) details using a unique identifier id.

path Parameters
id
required
string <uuid>

Unique identifier for the entity.

query Parameters
include
Array of arrays
Items Value: "caid.activities"

Include the product activations.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Request Body schema: application/json
internal_id
string <= 500 characters

Internal ID or something else that you uses to identify your mid (field description from enrollment).

Responses

Response Schema: application/json
object

All information about retrieving individual CAID details.

This includes parameters such as system CAID ID, creation date, active status, merchant details, etc.

Request samples

Content type
application/json
{
  • "internal_id": "caid_QWE12345"
}

Response samples

Content type
application/json
{
  • "data": {
    }
}

Disenroll product by CAID

Method to disenroll products for individual CAID (Card Acceptor ID) using a unique identifier id.

path Parameters
id
required
string <uuid>

Unique identifier for the entity.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Request Body schema: application/json
products
Array of strings
Items Enum: "ethoca" "rdr" "oi" "cdrn" "consumer-clarity" … 2 more

Products that are disenrolled for this CAID.

This includes the product names such as Ethoca, RDR, OI, CDRN, Consumer Clarity, Visa Dispute, and Visa Fraud.

In case of invalid status of product you will receive an error with code: validation_status_invalid and message: status must be a valid value for a product passed in request.

Responses

Response Schema: application/json
object

All information about retrieving individual CAID details.

This includes parameters such as system CAID ID, creation date, active status, merchant details, etc.

Request samples

Content type
application/json
{
  • "products": [
    ]
}

Response samples

Content type
application/json
{
  • "data": {
    }
}

Get CAID list

Leveraging the API's ability to access a list of CAIDs with comprehensive filtering, sorting, and pagination options, the response can gather crucial information such as PSP identifiers, BINs, and merchant details.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Request Body schema: application/json
object

Set of parameters used for detailed filtering.

This includes parameters such as system account IDs, merchant IDs, creation dates, update dates, statuses, etc.

object

The fields must be indexed to be sorted by them.

Thereafter, you can select which parameters to sort by.

object

Pagination to limit the number of results to help keep network traffic in check.

Responses

Response Schema: application/json
Array of objects

Information about retrieving individual CAID details.

This includes parameters such as system CAID ID, creation date, active status, merchant details, etc.

object

Pagination to limit the number of results to help keep network traffic in check.

Request samples

Content type
application/json
{
  • "filter": {
    },
  • "sort": {
    },
  • "pagination": {
    }
}

Response samples

Content type
application/json
{
  • "data": {
    }
}

Enrollment

The API facilitates rapid merchant onboarding by enabling batch creation of import MIDs.

Enroll MID batch

This method allows enrolling a batch of MIDs, streamlining the process of registering multiple merchants or card acceptor IDs.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Request Body schema: application/json
Array
required_products
Array of strings

This parameter specifies the products that enrolled for this CAID.

merchant_internal_id
string

Internal ID or something else that is used to identify the MID (merchant).

card_acceptor_id
string

Identification value used by card brands and banks to identify the location of the card acceptor terminal.

acquirer_bin
string

Six-digit Bank Identification Number (BIN) issued by the merchant's bank or processor.

psp_name
required
string

PSP identifier for recognition.

mcc
string

Setting merchant category codes.

descriptor
required
string

Payment descriptor.

description
string

Internal ID or something else that is used to identify the MID (caid).

arns
Array of strings [ 3 .. 10 ] items [ items = 23 characters .{1}4.{21} ]

Acquirer Reference Number (ARN) is a unique number assigned to a credit card transaction as it moves through the payment flow, facilitating tracking, especially in disputes, refunds, or chargebacks.

Responses

Request samples

Content type
application/json
Example
[
  • {
    }
]

Response samples

Content type
application/json
{
  • "error": {
    }
}

Get enrollment list

The request facilitates the retrieval of enrollment lists through flexible filtering, sorting, and pagination options. Users have the ability to paginate results and apply filters based on parameters such as statuses and descriptions.

The response contains card_acceptor_id that associated with entity from /api/v2/caids/list.

header Parameters
signature
string <= 500 characters

Signature of the request allows verifying whether the request is genuine.

public_key
string <= 500 characters

Unique identification that is shared at the moment of registration along with the Private Key.

Request Body schema: application/json
object

Set of parameters used for detailed filtering.

This includes parameters such as merchant internal IDs, statuses, descriptions, etc.

object

Pagination to limit the number of results to help keep network traffic in check.

Responses

Response Schema: application/json
Array of objects

All information about the enrollment lists.

This includes parameters such as system ID, merchant internal ID, CAID, status, required products, ARNs, etc.

object

Pagination to limit the number of results to help keep network traffic in check.

Request samples

Content type
application/json
{
  • "filter": {
    },
  • "pagination": {
    }
}

Response samples

Content type
application/json
{
  • "data": [
    ],
  • "pagination": {
    }
}

Changelog

The changelog documents all modifications, enhancements, and removals to the API. It helps developers and users track changes, understand new features, and adjust their implementations.

It is equally important to stay informed about updates in the broader business guide changelog, which provides comprehensive details on product-level changes specific to chargeback prevention.

Great care is taken to ensure that changes to the Solidgate APIs do not impact existing integrations.

Non-breaking changes

These modifications do not affect existing integrations and ensure backward compatibility:

  • New fields: Introduction of new, optional request fields or parameters in existing APIs.
  • Response modifications: Addition of new fields to API responses.
  • HTTP headers: Inclusion of new, optional HTTP request or response headers.
  • String length: Expansion of existing string field values.
  • Identifier format: Changes such as altering or removing prefixes from existing identifiers.
  • Webhook events: Addition of new webhook event types, which requires explicit opt-in.
  • Webhook schema: Inclusion of new fields in existing webhook event schemas.
  • Versioning: Older API versions remain supported for a set period, with advance notice for deprecation.
  • Rate limiting: Any modifications to rate limits will be communicated at least one month in advance.

Breaking changes

Breaking changes can impact existing integrations and require adjustments. These are marked with a breaking changes badge and include:

  • Operation removal: Removing an entire API operation.
  • Parameter modifications: Removing, renaming, or making an optional parameter required.
  • Response modifications: Removing or renaming a response field.
  • Type changes: Modifying the data type of a parameter or response field.
  • Enum updates: Removing existing enum values.
  • Validation rules: Adding new validation rules to an existing parameter.
  • Authentication and authorization: Changing authentication or authorization requirements.


28 January 2025

Removed general CAID status deprecated field; use info.products.{}.status in the responses for get CAID, get CAID list, update CAID, and disenroll products by CAID.

23 December 2024

Added the failure_reason field to the CAID info.products.{} object, representing the specific reason for an unsuccessful enrollment in the responses for get CAID, get CAID list, update CAID, and disenroll products by CAID responses.

Deprecated the general CAID status; use info.products.{}.status to retrieve the enrollment status of products.

02 October 2024

Added products object to the CAID info object that represents actual state of enrolled products in the get CAID, get CAID list, update, and disenroll products by CAID responses.

Deprecated ..._status fields in the CAID info object, use products fields instead.

28 August 2024

Added token pagination method to the retrieve alerts list


09 August 2024

Added additional field to the alert:rdr object in the webhook:

  • pricing_tier - RDR pricing tiers based on the Merchant Category Code (MCC)

25 July 2024

Added additional fields to alert object in the webhook:

  • mcc - merchant category code
  • descriptor - original payment descriptor
  • reason_code - alert reason code

20 June 2024

Added disenroll product by caid endpoint.


07 June 2024

Added:

28 February 2024

Removed a deprecated billing_address field from the webhook inquiry response.


14 February 2024

Added an outcome field to indicate the outcome of an alert in the responses for the get alert and get alert list endpoints.


08 February 2024

Added an info object to indicate the enrollment status of a MID in the responses for the get caid and get caid list endpoints.