Payment Callback

Overview

A payment callback is a server-to-server notification sent to a configured endpoint when a payment’s status or related information changes. The public callback URL can also receive forged or replayed requests. Callbacks communicate asynchronous events such as payment detected, confirming, completed, failed, expired, refunded, or reversed according to the provider’s lifecycle. For Payment Callback, the event identifier, signature result, delivery attempt, and resulting business state should remain connected throughout processing.

Receivers should use HTTPS, verify the documented authentication or signature, validate the schema, deduplicate atomically, and persist before acknowledging. Delivery can be duplicated, delayed, reordered, or abandoned after retry limits. When amounts, currency, or status are uncertain, query the provider and reconcile authoritative records. They allow backend systems to react after the customer has left the checkout page.

For Payment Callback, metrics should separate transport success from business success. Payment Callback is a provider notification or invocation concerning payment state; the exact event contract and security requirements must be stated rather than inferred from the word callback. Returning an HTTP success before durable storage risks losing an event if later processing fails. Business actions triggered by Payment Callback should be idempotent and should verify the current object state before fulfillment or accounting updates.

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

Monitoring for Payment Callback should track delivery age, signature failures, duplicate rate, retry exhaustion, and unresolved business events.

Replay of Payment Callback should preserve original identifiers and timestamps so historical processing cannot masquerade as a new event.