Payment Webhook

Overview

Payment Webhook is an asynchronous integration concept that sends an asynchronous HTTP event to a merchant endpoint when a payment’s state or related information changes. They connect provider state to orders, fulfillment, support, and accounting. Returning success before durable storage may lose an event when later processing fails. The Payment Webhook path should preserve ordering and duplicate evidence so delayed delivery cannot silently overwrite a newer state.

Receivers should use HTTPS, verify the documented signature or authentication, validate the schema, deduplicate atomically, and persist before acknowledging. Webhooks let systems react to payment detection, confirmation progress, completion, failure, expiration, refund, or another provider-defined event without constant polling. Processing should run through durable queues and legal state transitions. A receiver should treat transport acknowledgement and successful downstream processing as separate states for Payment Webhook.

An audit trail for Payment Webhook should link the contract and client version, principal, request identifier, sanitized payload evidence, response, callbacks, retries, overrides, provider references, and final state. Delivery is usually at least once and can be delayed, duplicated, reordered, or exhausted after retries. Replay tools, monitoring, status queries, and reconciliation cover delivery gaps. For Payment Webhook, the event identifier, signature result, delivery attempt, and resulting business state should remain connected throughout processing.

Public endpoints can receive forged or replayed messages.

Recovery for Payment Webhook should combine replay controls with an authoritative status check rather than trusting delivery history alone.

A Payment Webhook handler should acknowledge only after durable receipt when the provider’s retry contract depends on the response.