If you use status updates captured in the order service, the service should not really now about the content. So it would basically capture all status updates it gets for some correlation id — and just stores them without the need of understanding it. Otherwise you are right, you are coupling too tightly again.
But I doubt that I would go down that route. If you think about back office you might have another possibility: The UI might show something like “order is in payment” with a link to a separate component which can show the details of payment. A good question is how to do this link without coupling these components too much — but that depends on the overall UI approach.
And another approach is to have a separate component only listening for events for a certain (overall) flow by using some correlation identifier. This is known as distributed tracing and typically used for technical monitoring. But so far I see no reason to not also use this to show a subset of the events to the back office agent to give him an idea about the status. Spontaneously — without knowing too much about your use case and environment — that would be the approach I would try to follow if there is no reason against.
