Having a "wait" state, or wait activity, is not implausible, and depending on the domain, not uncommon either. Mark it as such and defined how long the state will be active for (i.e. how long it it goes back to the decision point).
If the decision point doesn't have to be explicitly exposed, you can roll the decision and wait state into a single activity that moves on the availability of an operator.
On a side note; if the OP is a "demo" of the actual flow being assessed in your project, there are other options for models and modeling this behavior that may be worthwhile investigating, such as;
- FSM, a state with an event that moves the machine on to the "place order" state
- If there are multiple flows that require synchronisation, a join may be a better idea
Sometimes other solutions may just be another model, or a redesign of some sort that removes the wait state. That said, often then solution is just the wait state because that's the behavior of the process flow being modeled (whether that is by design or by analysis).
On the added second option, the "wait until" inherently requires a test to determine if the required condition is satisfied, I'm not sure the second option models that appropriately.