Merchant Webhook
Pronunciation: MUR-chunt WEB-hook
Definition
Merchant Webhook is an asynchronous integration concept that delivers payment or account events from a provider to a merchant-controlled URL through asynchronous HTTP requests. Merchant Webhook must specify the producer, consumer, event type and version, delivery URL, stable event identifier, signature method, timestamp, retry policy, and expected response. A reliable Merchant Webhook implementation validates authenticity, acknowledges quickly, stores the event durably, processes idempotently, tolerates duplicates and reordering, and records the final business outcome.
Overview
Merchant Webhook is an asynchronous integration concept that delivers payment or account events from a provider to a merchant-controlled URL through asynchronous HTTP requests. Events may repeat, arrive late, appear out of sequence, or stop after retry limits. An attacker may also send forged requests to a public endpoint. Returning success before durable storage can lose the event during later failure. Monitoring for Merchant Webhook should track delivery age, signature failures, duplicate rate, retry exhaustion, and unresolved business events. Replay of Merchant Webhook should preserve original identifiers and timestamps so historical processing cannot masquerade as a new event.
Receivers should use HTTPS, verify signatures or the provider’s documented authentication, deduplicate by stable event identity, and persist before acknowledging. Merchant webhooks inform business systems about status changes without continuous polling. Events can update orders, support dashboards, inventory, fulfillment, notifications, or accounting when payments are detected, confirmed, failed, expired, or refunded. Monitoring, replay, and periodic API reconciliation cover messages that never arrive or cannot be processed. The Merchant Webhook path should preserve ordering and duplicate evidence so delayed delivery cannot silently overwrite a newer state.
For Merchant Webhook, the event identifier, signature result, delivery attempt, and resulting business state should remain connected throughout processing.
A receiver should treat transport acknowledgement and successful downstream processing as separate states for Merchant Webhook.
Recovery for Merchant Webhook should combine replay controls with an authoritative status check rather than trusting delivery history alone.
A Merchant Webhook handler should acknowledge only after durable receipt when the provider’s retry contract depends on the response.
Key Takeaway
Merchant webhooks are reliable only with authentication, durable receipt, deduplication, ordering controls, replay, and authoritative reconciliation.
Sources
- IETF RFC 9110 — IETF (2026-07-30)
- OpenAPI Initiative Documentation: V3.2.0 — OpenAPI Initiative (2026-07-30)
- OxaPay Documentation: Webhook — OxaPay (2026-07-30)