Webhooks

Event types

ChargebackStop currently supports five types of webhook events:

  • alert.created

  • alert.updated

  • representment.created

  • representment.updated

  • fraud_notification.created

Adding webhook endpoints

In the partner dashboard

To add a webhook endpoint, go to the Partner settings page and click “Add Endpoint” in the section at the bottom of the page.

In the modal window, enter the URL ChargebackStop should send events to, and select the event types you want to receive.

Once the endpoint is saved, it appears in the table at the bottom of the page. You can use the eye icon to reveal the webhook secret that the ChargebackStop platform uses to sign webhooks.

In the organisation dashboard

Open your ChargebackStop dashboard, then select “Settings” from the left-hand menu. From the tabs at the top, pick “Webhooks”.

To add a webhook, click the “Add webhook” button and fill in the form with your endpoint URL and the events you want to receive.

Once the endpoint is saved, it appears in the table at the bottom of the page. You can use the eye icon to reveal the webhook secret that the ChargebackStop platform uses to sign webhooks.

Delivery mechanism

Request Details

  • The payload will be a JSON object (see below for details).

  • We include an X-Signature header, which is an HMAC-SHA512 hash of the timestamp and payload, allowing you to verify request authenticity. The signing secret is unique to your webhook subscription.

  • We include an X-Idempotency-Key header with the unique delivery ID.

  • We expect a successful HTTP response (2xx status code) within 20 seconds.

Reliability and retries

  • If the initial delivery attempt fails (e.g., due to a network error or a 4xx/5xx response from your server), we automatically retry delivery.

  • Our retry strategy includes 5 attempts over approximately 2 days, with increasing delays between attempts: 1 minute, 5 minutes, 30 minutes, 2 hours, and finally 12 hours.

    • Retries for the same delivery keep the same X-Idempotency-Key value (the delivery ID). The header helps prevent processing duplicate deliveries. To ensure you process each event only once, rely on the event ID from the payload (id), which stays the same across retries of that event.

  • If all retries are exhausted and the delivery remains unsuccessful, the delivery will be marked as FAILED.

  • If multiple delivery attempts to a given endpoint start failing, the system will automatically disable the webhook endpoint due to poor health.

Signature

To ensure webhook security and authenticity, we include a unique signature with each request. This signature allows you to verify that the webhook originated from us and that its payload was not tampered with in transit.

1

How the X-Signature header is generated

  • Timestamp: We take the current Unix timestamp (the number of seconds since January 1, 1970 UTC). This timestamp is included directly in the signature header.

  • Payload: This is the raw JSON body of the webhook request.

  • Concatenation: We create a string by concatenating the timestamp, a period (.), and the UTF-8 decoded payload. For example: "{timestamp}.{payload_string}".

  • HMAC-SHA512: We then use your unique webhook secret (provided to you when you set up the webhook subscription) to create an HMAC of the concatenated string using the SHA512 hashing algorithm.

  • Hex Digest: The resulting HMAC is encoded into a hexadecimal string.

  • Formatted signature: Finally, the signature is formatted as t={timestamp},v1={hex_digest}.

Notes on the formatted signature:

  • t={timestamp}: Unix timestamp when the signature was generated. You can compare this with your current time and discard webhooks that are too old to help prevent replay attacks. We recommend tolerating reasonable clock skew (e.g., a few minutes) between your servers and ours.

  • v1={hex_digest}: Signature scheme version (currently v1) followed by the hexadecimal HMAC-SHA512 digest.

2

How to verify a received signature

  1. Verify the timestamp (t=): Extract the timestamp from the X-Signature header and compare it with your current server time. If the difference is too large (outside your acceptable tolerance for clock skew and message delivery times), you may choose to discard the request.

  2. Verify the signature (v1=): If the timestamp is acceptable, construct the signature string on your end:

    • Use the timestamp from the t= part of the received X-Signature header.

    • Use the raw request body as the payload.

    • Concatenate them: "{timestamp_from_header}.{raw_request_body}".

    • Calculate the HMAC-SHA512 hash of this concatenated string using your webhook secret.

    • Convert the hash to its hexadecimal representation.

    • Compare this generated signature with the v1= value from the received X-Signature header. They must match exactly.

If the timestamp is recent enough and your generated signature matches the one provided in the header, you can be confident the webhook is genuine, untampered, and not a replayed request.

JavaScript signature verification function

PHP signature verification function

Python signature verification function

Payloads

Webhook payload contains the following fields:

  • id - unique event ID.

  • type - event type, currently one of alert.created, alert.updated, representment.created, representment.updated, or fraud_notification.created.

  • created_at - date and time of when event was created.

  • data - object containing the main body of the event.

    • object - a snapshot of the entity the webhook was generated for. For alert events it matches the alert object from the API (https://api.chargebackstop.com/v1/docs#/Alerts/src_api_alerts_get_alertsarrow-up-right); representment and fraud notification events follow their corresponding public event payload schemas.

    • previous_attributes - present only in ‘updated’ events, contains a list of fields that changed and their previous values.

Examples

Sample alert.created payload. data→object body matches the alert object from the API (https://api.chargebackstop.com/v1/docs#/Alerts/src_api_alerts_get_alertsarrow-up-right).

Sample alert.updated body. Please note the previous_attributes object.

Sample representment.created event

Sample representment.updated event

Sample fraud_notification.created event.

Field definitions:

  • fraud_notification_type: SAFE or TC40

  • fraud_type:

    • LOST

    • STOLEN

    • NOT_RECEIVED_AS_ISSUED

    • FRAUDULENT_APPLICATION

    • COUNTERFEIT

    • MISC

    • FRAUDULENT_USE_OF_ACCOUNT_NUMBER

    • ACQUIRER_REPORTED_COUNTERFEIT

    • INCORRECT_PROCESSING

    • ACCOUNT_TAKEOVER

    • MERCHANT_MISREPRESENTATION

    • MANIPULATION_OF_ACCOUNT_HOLDER

    • UNKNOWN

    • CARD_NOT_PRESENT

    • BUST_OUT_COLLUSIVE_MERCHANT

    • MODIFICATION_OF_PAYMENT_ORDER

    • FIRST_PARTY_MISUSE

Postman collection

We created a Postman collection that allows you to send sample webhooks.

It contains a pre-request script that generates a correct signature every time you send the request.

Postman collection: https://www.postman.com/chargebackstop/chargebackstop/collection/2yu40q8/chargebackstop-webhooksarrow-up-right

Last updated

Was this helpful?