Example

Complete procedure: a guest-facing procedure that builds an order and takes payment before confirmation or sync.

Goal: One coherent purchase path — shared payment core for occupancy and menu flows.

Typical step order

1. Guest / time / elements context — as in booking-classic-occupancy, or skip occupancy for booking-menu-checkout.
2. Build the order
   • AddPositionToOrder — configured orderables; quantities usually FromOtherParameter.
   • OrderFromMenu — guest-picked SKUs.
3. PayNow — checkout when gross total > 0; skipped when nothing is owed.
4. Persist / notify — SyncReservationEntry / SyncOrderEntry / SyncInvoiceEntry, then InformGuestViaEmail → InformOperator.

Choosing order-building steps

Scenario	Prefer
Fixed or parameter-driven price list	AddPositionToOrder
Guest browses menu	OrderFromMenu
Multi-night stay	AddNightsToOrder before PayNow
Pay first, order more later	PayNow then ReOrderMenu / SubmitAsReorder

Related patterns: booking-classic-occupancy, booking-menu-checkout, booking-kiosk-tickets.

Testing split: Component guides for knobs; this pattern for chaining; Playwright for one E2E path; procedure-manager tests for PayNow edge cases.