Event versus state
An event describes something reported to have happened. State is your system’s current interpretation of the operation. They are related, but not identical: a late notification about an earlier step should not necessarily overwrite a later confirmed result simply because it arrived most recently.
Name allowed transitions
Define the supported lifecycle and the evidence required to move between states. Keep business transitions separate from delivery or processing errors. A notification handler failing internally does not, by itself, prove that the underlying bank payment failed or that a customer should submit another instruction.
An out-of-order example
A fictional integration receives a completed notification before an older pending notification. A naive last-write-wins update returns the payment to pending. A lifecycle-aware handler preserves completion and records the delayed event, using the provider’s documented ordering and reconciliation mechanisms rather than guessing from arrival time.
Leave a readable trail
Record event identity, source, relevant timestamps and the resulting state decision without exposing unnecessary sensitive information. Make rejected transitions visible for investigation. When the external record and local interpretation disagree, reconcile them explicitly instead of adding another special case that hides the history from future reviewers.