Callback Verification

Overview

Callback Verification is the process of confirming that a callback is authentic, intact, timely, and connected to a valid expected object or transaction. It is used to prevent forged or replayed notifications from changing payment or account state. It differs from TLS alone, which protects transport but does not prove that the application message came from the expected provider.

A typical implementation works as follows: The receiver verifies a signature or shared secret over the raw payload, checks timestamp and replay limits, validates identifiers and amounts, and confirms allowed state transitions. Business actions triggered by Callback Verification should be idempotent and should verify the current object state before fulfillment or accounting updates.

Common risks include canonicalization errors and leaked secrets. Important failure modes include canonicalization errors, leaked secrets, unsigned fields, replay, wrong environment, and accepting browser return parameters. These failures can enable false payment updates.

Core controls require teams to use provider-approved signing, constant-time comparison, secret rotation, timestamp windows, nonce or event deduplication, and authoritative API reconciliation. A Callback Verification handler should acknowledge only after durable receipt when the provider’s retry contract depends on the response.

Operational evidence should include event ID, signature version, secret ID, timestamp, payload hash, verification result, object checks, and reviewer action. Callback Verification should be documented alongside Callback Handler, Webhook Endpoint, and Certificate Pinning.

Monitoring for Callback Verification should track delivery age, signature failures, duplicate rate, retry exhaustion, and unresolved business events. Replay of Callback Verification should preserve original identifiers and timestamps so historical processing cannot masquerade as a new event.