The payment exists, but the order is still waiting
A customer can have a successful payment while the shop still shows an unpaid order. The payment provider and the shop hold different records, and the message joining them may be delayed, repeated or processed incorrectly. Treating the last webhook received as the complete truth makes that disagreement harder to repair.
A webhook is a signal to evaluate a business record. It is not a substitute for deciding which system owns payment status, fulfilment status or customer communication. A payment provider can settle the payment question; it cannot establish whether the warehouse has dispatched the parcel. Those authorities need to remain separate.
Accept the message before doing the work
The receiving endpoint should verify the sender, record a durable receipt and hand the work to a processor. A successful acknowledgement should mean the message is safely accepted, not that every downstream action has finished. If durable acceptance fails, pretending success hides work that still needs to happen.
Stripe documents signature verification, duplicate delivery and a lack of guaranteed event ordering. These are explicit integration conditions, not exceptional mistakes to dismiss during testing. Stripe's webhook guidance is the relevant contract for Stripe integrations.
Our recommended receipt record includes the provider event reference, the affected business reference, receipt time and processing state. Keep the payload needed for diagnosis under an appropriate access and retention policy. A log line that disappears with the application process is not an adequate receipt ledger.
Repeating a message must not repeat the business effect
Consider an illustrative order flow that sends a confirmation after marking payment as received. Deduplicating the inbound event helps, but the processor can still stop after sending the message and before recording completion. Replaying the job could then send another confirmation.
Track the business effect separately from the delivery attempt. A confirmation, stock reservation and refund each need their own stable operation reference. Where a receiving service supports an idempotency mechanism, use the same reference for retries of the same intended action. Where it does not, define how an uncertain result will be investigated before repeating it.
Ordering needs similar care. An older payment notification should not overwrite a later refund state merely because it arrived last. Evaluate permitted state transitions and consult the authoritative record when the event cannot safely establish the current position. Arrival order is a transport detail, not a business rule.
Recovery needs a path that does not depend on another webhook
A reconciliation job compares relevant records across systems and produces explainable differences. For example, it can identify payments with no matching order update or orders waiting for a payment decision that is already known elsewhere. The comparison needs a defined scope, pagination and a checkpoint so it can resume.
Do not automatically repair every difference. A mismatch may be legitimate while fulfilment is in progress, or it may require an operator to resolve an ambiguous reference. Separate safe repairs from cases requiring evidence. Record the reason for each action so the next incident does not begin from an empty history.
The uncomfortable cost is an operational screen or report that somebody actually reads. Delivery dashboards can look healthy while business records remain wrong. A reconciliation result without an owner is another unprocessed message.
Run a recovery exercise this week
Choose a harmless test order and trace it from provider record to local state and outbound communication. Replay its event, change the order of related messages, and interrupt processing after a side effect. Confirm that the outcome remains explainable.
Then omit the notification altogether in a test environment. The reconciliation path should find the discrepancy without waiting for a new event. Document who can approve repair, what evidence they see and how completion is recorded. That exercise tests the integration, not merely its webhook endpoint.