Handle Delayed and Out-of-Order Payment Events

Treat a notification as input to an order decision

Identify the provider event, transaction reference, and store environment before changing the order. Event delivery and order updates happen separately. A later-arriving notification may describe something older than the state your store has already recorded.

Define which transitions can still be applied

Allow known forward transitions such as pending to captured or captured to refunded. Preserve the final state when an earlier informational event arrives late. If the event appears incompatible with the order state, verify the provider’s current transaction record and save an exception for staff.

Keep replay and fulfillment effects separate

Record whether an event has already been handled. Make the order update and any fulfillment trigger safe to repeat even if a duplicate uses a different event identifier. Test both delivery duplication and application failure after a status update.

Replay a controlled sequence in staging

• Deliver capture confirmation before an earlier authorization notice.
• Deliver the same confirmation twice.
• Deliver a refund after the order was fulfilled and verify fulfillment does not restart.