Webhooks

Event types

ChargebackStop currently supports eleven types of webhook events:

  • alert.created

  • alert.updated

  • enrolment.created

  • enrolment.updated

  • representment.created

  • representment.updated

  • fraud_notification.created (deprecated, to be removed on March 31, 2026)

  • scheme_notice.created

  • scheme_notice.updated

  • lookup.created

  • lookup.updated

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, enrolment.created, enrolment.updated, representment.created, representment.updated, fraud_notification.created, scheme_notice.created, scheme_notice.updated, lookup.created, or lookup.updated.

  • 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.

Enrolment webhooks (enrolment.created, enrolment.updated)

  • enrolment.created is sent when a new enrolment is created.

  • enrolment.updated is currently emitted when an enrolment status changes.

  • This status-only behavior is the current implementation and is not a strict long-term contract. Additional enrolment field changes may also emit enrolment.updated in the future.

  • Status updates performed through simulation tooling (for example, PATCH /v1/simulate/enrolments/{enrolment_id} for TEST organisations) follow the same behavior and can emit enrolment.updated.

  • Enrolment webhook payloads are versioned as api_version: "v2".

  • For update events, data.previous_attributes includes tracked fields and their previous values at event creation time.

Sample enrolment.created payload.

Sample enrolment.updated payload. Please note the previous_attributes object.

Sample representment.created event

Sample representment.updated event

Sample fraud_notification.created event.

Fraud notification 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

Scheme notice webhooks (scheme_notice.created, scheme_notice.updated)

  • scheme_notice.created is sent when a new scheme notice is created.

  • scheme_notice.updated is emitted when a tracked field on a scheme notice changes. Currently tracked fields are: is_revoked, notice_revoked_at, fraud_reported_at, and transaction_purchase_date.

  • A scheme_notice.updated event is only emitted after a scheme_notice.created event exists for that notice.

  • For update events, data.previous_attributes includes only the tracked fields that changed and their previous values.

  • Scheme notice webhook payloads are versioned as api_version: "v1".

Sample scheme_notice.created payload.

Sample scheme_notice.updated payload. In this example, the notice was revoked. Please note the previous_attributes object.

Scheme notice field definitions:

  • scheme_notice_type: TC15, TC40, or SAFE

  • notice_type: FRAUD_NOTICE or DISPUTE_NOTICE

  • scheme: VISA, MASTERCARD, or OTHER

  • fraud_reported_at: Date when the fraud was reported

  • fraud_type: Free-form string from the upstream network (e.g., CARD_NOT_PRESENT, STOLEN, COUNTERFEIT, ACCOUNT_TAKEOVER, etc.)

  • fraud_dispute_eligible: Whether the fraud is eligible for a dispute

Lookup webhooks (lookup.created, lookup.updated)

  • lookup.created is sent when a new digital receipt lookup is created (from Ethoca Consumer Clarity or Verifi Order Insight).

  • lookup.updated is emitted when a tracked field on a lookup changes. Currently tracked fields are: lookup_status and deflection_status.

  • A lookup.updated event is only emitted after a lookup.created event exists for that lookup.

  • For update events, data.previous_attributes includes only the tracked fields that changed and their previous values.

  • Lookup webhook payloads are versioned as api_version: "v1".

Sample lookup.created payload.

Sample lookup.updated payload. In this example, the deflection status changed from PENDING to SUCCEEDED. Please note the previous_attributes object.

Lookup field definitions:

  • type: ETHOCA_CONSUMER_CLARITY, ETHOCA_FIRST_PARTY_TRUST, VERIFI_ORDER_INSIGHT, or VERIFI_COMPELLING_EVIDENCE_3

  • lookup_status: PENDING, SUCCEEDED, FAILED, or TIMEOUT

  • deflection_status: NOT_ATTEMPTED, PENDING, SUCCEEDED, or FAILED

  • parent_lookup_id: ID of the parent lookup (e.g., for HISTORICAL lookups linked to a DISPUTED lookup)

  • transaction_amount: Transaction amount in cents

  • integration_id: Platform Integration ID for the matched transaction's payment processor integration

  • integration_transaction_id: Payment processor's transaction ID (e.g., Stripe charge ID, Adyen PSP reference)

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?