While I think @Christophe's answer is the simplest solution (and simplicity often prevails over everything else), I think there is, at least, one more alternative.
OrderController is basically the same for all three contexts but for some specific behaviour, I would evaluate the possibility to make these specific behaviours parametrizable. In other words, make
OrderController configurable so that I have only one Controller and N different configurations. In runtime, this's translated into 3 different instances of
OrderController each of which with its own configuration.
If at some point, any of the contexts diverge so that the convention over configuration is not possible, we are still in time to extend the controller and implement a dedicated one. Or not extend it at all.
It's worth saying that polymorphism (or inheritance) is usually more coupling and constraining than composition.
They have two parts, the first part in authorising and validating the
input, and the second part is doing the logic like storing the order.
the second part is the duplicate code.
Controllers, ideally, have very little logic to override. Extending a super controller should result in 3 classes with almost no differences, so why not encapsulate the differences in components and make the controller configurable?
On one hand, validations and security are cross-cutting features that can be decoupled from controllers. On the other hand, business logic must be encapsulated in different components.