How would one achieve something similar to database transactions.
Well, you could use distributed transactions, but you don't want to. And, more probably than not, you don't need to.
What if these services don't expose APIs to rollback a transaction, what would be the solution?
Well, it's great actually, so you won't mess up with distributed transactions. The modern way to handle things like that is to employ the concept of eventual consistency. It means that your business process is split into several steps, each of which is processed ACID-ly. So the overall result is not consistent right away, but eventually consistent instead, when all steps are processed.
Usually it's done with sagas. Saga is an approach of getting distributed agreement of a business-process, and at the same time it's a way to handle failures (there is a very good example in an post I linked to). It's not about a certain way they can be implemented in. They could have a synchronous centralized control, asynchronous centralized control, or a distributed.
In the case where rollback is not available, what would be the correct order to consume each service?
It totally depends on your domain. When it doesn't matter from the business point of view, common sense is to start with an action that is easiest to rollback, so that the most risky action, requiring the most complex rollback, would be the last one.
Here is an example in e-commerce, using aforementioned saga approach.
