Webhook handlers are tempting places to finish work immediately. The callback arrives, so the system must be ready, right?
In practice, some providers fire callbacks before their own read endpoints expose the final state. A synchronous handler that assumes the status endpoint is already settled can turn a successful vendor flow into a false failure inside your application.
The better pattern is to accept the callback quickly, record enough context to continue, and hand confirmation to a background worker with bounded retries and backoff. The main request path stays responsive, the external system gets time to settle, and failure becomes observable instead of mysterious.
This is not glamorous architecture. It is the kind of small reliability choice that keeps integrations from depending on perfect timing between systems you do not control.