DocsWatchTowerSigned Callbacks

Signed Callbacks

How adapter-based integrations receive final review and challenge outcomes after the initial transaction response.

When callbacks are used

The transaction ingestion response is the immediate risk outcome. A signed callback is used when the final outcome happens later, such as after an analyst review or a completed step-up verification.

Remllo adapter integrations can map the final WatchTower outcome into the release, decline, or status operation agreed with the source platform. The adapter contract is confirmed during implementation.

Provider-neutral contract

Callback delivery is not tied to one core-banking or payment provider. Remllo uses adapter contracts so the same WatchTower outcome can be mapped safely into each supported source system.

Supported outcome events

  • `transaction.review_outcome` after an analyst records the final result of a reviewed transaction
  • `transaction.challenge.resolved` after a challenge verification is completed or expires
  • a later final outcome when the organization requires analyst approval after successful verification

Verify every callback

WatchTower signs the exact request body with HMAC-SHA256. Verify the signature before parsing or acting on the callback, reject stale timestamps, and process each callback reference idempotently.

Callback headers
X-WatchTower-Signature: lowercase hexadecimal HMAC-SHA256 signature
X-WatchTower-Timestamp: Unix timestamp in milliseconds used in the signed value
X-WatchTower-Organization-Id: organization that owns the event
X-WatchTower-Environment: sandbox or production delivery context
Signature input
signedValue = X-WatchTower-Timestamp + "." + rawRequestBody
signature = HMAC_SHA256(callbackSecret, signedValue)

Compare signatures using a constant-time comparison.

Delivery and retry behaviour

  • return any 2xx response only after the event has been accepted safely
  • timeouts and non-2xx responses are retried with backoff
  • use the callback reference as the idempotency key so retries do not repeat a release or decline action
  • do not depend on callback ordering; compare the transaction and challenge state before applying an action
  • keep the raw body available until signature verification is complete
Fail safely

An invalid signature, stale timestamp, unknown organization, or duplicate terminal outcome must not trigger a payment action. Record the event for investigation and return a non-success response where appropriate.