Repetition can be normal
A delivery system may send the same business notification more than once, particularly when acknowledgements are delayed or lost. That does not necessarily mean two payments occurred. The receiver needs its own plan for recognising processed events and preventing repeated effects such as extra fulfilment.
Two identities matter
Distinguish the event’s delivery identity from the underlying payment or order identity. A payment can legitimately produce several different events. Ignoring everything with the same payment identifier would suppress real lifecycle changes, while processing every repeated delivery as new could duplicate stock movements or customer credits.
A shipping example
A fictional paid event triggers a shipping job, but the acknowledgement is lost. The sender retries the event. The receiver should recognise the already-recorded event and avoid creating another shipment, while still returning the expected acknowledgement through its documented delivery-handling process.
Make the effect durable
Coordinate event recording with the downstream work so a crash cannot leave an ambiguous “processed” flag and an unknown effect. Test failure before and after each boundary. Retain enough operational history to replay safely, and distinguish a legitimate new refund event from another copy of the original payment notification.