Webhooks
Event types
ChargebackStop currently supports eleven types of webhook events:
alert.createdalert.updatedenrolment.createdenrolment.updatedrepresentment.createdrepresentment.updatedfraud_notification.created(deprecated, to be removed on March 31, 2026)scheme_notice.createdscheme_notice.updatedlookup.createdlookup.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-Signatureheader, 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-Keyheader 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.
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 (currentlyv1) followed by the hexadecimal HMAC-SHA512 digest.
How to verify a received signature
Verify the timestamp (
t=): Extract the timestamp from theX-Signatureheader 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.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 receivedX-Signatureheader.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 receivedX-Signatureheader. 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 ofalert.created,alert.updated,enrolment.created,enrolment.updated,representment.created,representment.updated,fraud_notification.created,scheme_notice.created,scheme_notice.updated,lookup.created, orlookup.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_alerts); 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_alerts).
Sample alert.updated body. Please note the previous_attributes object.
Enrolment webhooks (enrolment.created, enrolment.updated)
enrolment.created, enrolment.updated)enrolment.createdis sent when a new enrolment is created.enrolment.updatedis currently emitted when an enrolmentstatuschanges.This status-only behavior is the current implementation and is not a strict long-term contract. Additional enrolment field changes may also emit
enrolment.updatedin 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 emitenrolment.updated.Enrolment webhook payloads are versioned as
api_version: "v2".For update events,
data.previous_attributesincludes 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 TC40fraud_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, scheme_notice.updated)scheme_notice.createdis sent when a new scheme notice is created.scheme_notice.updatedis emitted when a tracked field on a scheme notice changes. Currently tracked fields are:is_revoked,notice_revoked_at,fraud_reported_at, andtransaction_purchase_date.A
scheme_notice.updatedevent is only emitted after ascheme_notice.createdevent exists for that notice.For update events,
data.previous_attributesincludes 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 SAFEnotice_type: FRAUD_NOTICE or DISPUTE_NOTICEscheme: VISA, MASTERCARD, or OTHERfraud_reported_at: Date when the fraud was reportedfraud_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, lookup.updated)lookup.createdis sent when a new digital receipt lookup is created (from Ethoca Consumer Clarity or Verifi Order Insight).lookup.updatedis emitted when a tracked field on a lookup changes. Currently tracked fields are:lookup_statusanddeflection_status.A
lookup.updatedevent is only emitted after alookup.createdevent exists for that lookup.For update events,
data.previous_attributesincludes 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_3lookup_status: PENDING, SUCCEEDED, FAILED, or TIMEOUTdeflection_status: NOT_ATTEMPTED, PENDING, SUCCEEDED, or FAILEDparent_lookup_id: ID of the parent lookup (e.g., for HISTORICAL lookups linked to a DISPUTED lookup)transaction_amount: Transaction amount in centsintegration_id: Platform Integration ID for the matched transaction's payment processor integrationintegration_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-webhooks
Last updated
Was this helpful?