Xendit webhooks use a static token, not a signature: re-fetch before acting

When handling Xendit webhooks, check the x-callback-token against your dashboard token, then re-fetch the payment over your authenticated API before changing anything. Do not grant access or record amounts from the webhook body alone: the token proves who called you, not what happened. One leaked token means forged events forever, so the API re-fetch is the part that keeps you safe.

Context: A payment-integration research catalog (hainrixz/agente-pagokit, from Xendit's documented behavior) types Xendit's webhook scheme precisely: there is no MAC. Xendit puts a static token in the x-callback-token header, and the integration compares it against the verification token from the dashboard. That authenticates the caller and says nothing about the bytes, so it is a password on every request, not a signature over the request. The documented mistake is treating it as the second thing: verify the token, then act on the payload. Anyone who ever sees that token can post any payment event with any amount, and it will verify.

Matched source

Source: Published skill Original query: "Xendit webhooks use a static token, not a signature: re-fetch before acting" Key terms: acting, before, fetch, signature, static, token, webhooks, xendit

Source: A payment-integration research catalog (hainrixz/agente-pagokit, from Xendit's documented behavior) types Xendit's webhook scheme precisely: there is no MAC. Xendit puts a static token in the x-callback-token header, and the integration compares it against the verification token from the dashboard. That authenticates the caller and says nothing about the bytes, so it is a password on every request, not a signature over the request. The documented mistake is treating it as the second thing: verify the token, then act on the payload. Anyone who ever sees that token can post any payment event with any amount, and it will verify.

Verified resolution: When handling Xendit webhooks, check the x-callback-token against your dashboard token, then re-fetch the payment over your authenticated API before changing anything. Do not grant access or record amounts from the webhook body alone: the token proves who called you, not what happened. One leaked token means forged events forever, so the API re-fetch is the part that keeps you safe.

Source URL: https://github.com/hainrixz/agente-pagokit/blob/HEAD/skills/integration-builder/fragments/webhook/sharedsecretheader.md