We use DFD for high-level modeling. It shows inter-process communications via messages, signals and (most often) data/business objects.

I don’t believe in high-level and low-level modeling of the same business process. The can only represent two sequential stages of process discovery but as soon as you dived into the low-level model there is no way back to high level.

I’d like to be able to combine the high-level and the more detailed view in one model, but I’m not sure this is possible. You could create a “receive payment” subprocess, and put the event gateway in the subprocess diagram, but it probably wouldn’t help, as you need to show the “exception handling” (process delay, process refusal) at the top level.

В BPMN 2.0 можно воспользоваться non-interrupting attached timer event, чтобы разбирательство с задержкой не прекращало ожидания сообщения.

Варианты могут быть разными для разных ситуаций, единственно правильного решения тут нет. Я ставил перед собой другую задачу - показать широко распространенную и при этом явно неправильную схему.

Thank you for sharing thoughts. I had this hope in mind. Some BPMS developers will read this post for sure.

Of course the attached events is the option but implementing it probably isn’t easier. Anyway, the systems I have in mind lack both.

As for individual preferences - I considered the solution you propose but I didn’t like the idea of combining different messages into one. Such a diagram would require annotations while the diagram with the event gateway speaks for itself.

The proposed diagram is a bit eclectic - one may ask why sending the message isn’t implemented by intermediary event - but who cares.

Imagine, for example, a single activity with all three events attached to it: the timer, the refusal event, and the payment event (keeping in mind, refusal and payment could be attributes of the same “response” event if we wanted). The activity must be designed to “not exit” so that it stops and waits for one of these three events to transpire.

I think diagrammatically it is cleaner than the event gateway in some respects, but there’s no “never-ending activity” as a first-class notion in BPMN (um, that I’m aware of, the spec is big and getting bigger!). And I think there are even more complicated scenarios than the one that you describe that really call for an event gateway to exist.