Callback Verification

Overview

Context and purpose

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. Important failure modes include canonicalization errors, leaked secrets, unsigned fields, replay, wrong environment, and accepting browser return parameters. 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.

How it works

Verification checks that an inbound callback has the claimed origin and has not been altered in transit. Depending on the provider, it may require HMAC verification, asymmetric signatures, authenticated channels, a timestamp or replay controls.

Practical checks and failure points

Rotate secrets safely, compare MACs in constant time where possible, reject stale replayed messages and authorize the referenced merchant.

Related concepts

Duplicate Callback · Delayed Webhook

Further reading

• api-security.owasp.org official reference