What notation marks that an activity must be completed within two-day time in an activity diagram?

Question

Customers can pay for an order instantly or later. When the order is pay-later, I want to draw a notation that signifies that the customer must pay within two-day time in an activity diagram. If the customer does not pay within two-day time, the system will mark the order as canceled.

In this attached image, the first swimlane is for the actor Customer, and the second swimlane is for the actor System. I created a time event notation that signifies that the customer must pay within 48 hours. Then, I placed the merge/branch node on the customer swimlane to signify that the customer is the actor that must make the payment.

The issue that I thought of about my current diagram is that someone might misunderstand the time event notation. Someone might understand the notation as a sign that the system will always wait 48 hours before marking the order as canceled or awaiting shipment. In reality, the system will mark the order as awaiting shipment as soon as the customer pays. However, if the customer doesn't pay after 48 hours, the system will mark the order as canceled.

How can I draw a better diagram to signify the above description?

Answer 1

An accept time event action (e.g. an AcceptEventAction with a single TimeEvent trigger) cannot have an input flow, so your diagram is invalid, and then does not show what you want.

The guards of the flow after a Decision must be written between brackets ([]).

---

I placed the merge/branch node on the customer swimlane to signify that the customer is the actor that must make the payment.

but this is check by the system independently of the customer, so this is wrong / unclear

The fact the two actions creating order are not in the customer swimlane is also wrong / unclear for me

---

After the action create an order with the awaiting payment status you can create a new timer dedicated to the current order of the customer. In case a customer pays before 2 days the corresponding timer is deleted.

But that can produce a lot of timers, you can also memorize the current order more timeout in a fifo and you have a unique timer. In case a customer pays before 2 days the corresponding order is removed from the fifo.

• That unique timer can periodically check the memorized orders, but that pooling wake-up the system even when nothing must be done.

• That unique timer can be started when a first order is memorized, then when the system wake-up it manages the too older orders, then if the fifo become empty the timer is stopped else it is updated depending on the delay of the first (older) order in the fifo

Answer 2

Per @qwerty_so's comment, I have decided to use an interruptible region. This interruption trigger of this region is the system accepting payment. Here's the new diagram.

EDIT

As per @bruno's comments and @Axel Scheithauer's comments, I have cropped the more complete image of my activity diagram. An Accept Time Event Action seems to be able to have incoming edges/flows, contrary to @bruno's comments. Furthermore, I believe that the incomplete screenshot was what caused confusion in my diagram.

I also revised my diagram so that the interruptible region's signal comes from the Accept Time Event Action instead of Accept Event Action.

Diagram 1:

Diagram 2: