Paying Contractors

In my opinion it is pay per iteration. The customer (PO) can negotiate what will be done in each iteration with the contractor.
If the team size is stable, there is only a small difference to pay by the hour: In case of pay by the hour the contractor is motivated to do overtime which can make him less productive and decrease the value cost ratio for the customer.

Ok thanks, and if the contractor does not deliver what was agreed within the iteration?

In an ideal world, the contractor will value customer collaboration over contract negotiation.
This means, the most important thing when the sprint goal was not reached is to collaborate on how to improve for the next iteration.
You could think of a situation where the contractor is only payed if he reaches the sprint goal. In this case he would be motivated to set sprint goals which are not too challenging, and it might even be that the reason for not reaching the goal is missing feedback from the customer.
You could even think of a basis payment for each sprint (effort) and a bonus for delivered value (if sprint goal was met).

It's generally best to fund the current Sprint up front and at the client's risk. This puts the onus on the client to de-risk delivery by collaborating via the PO throughout the Sprint, and to see early demonstrations. This is usually better than allowing a client to turn their noses up at an increment they have not been sufficiently involved in.

What about dividing the risk, by having the client paying half the price at the beginning of the sprint, and half the price at the sprint review ?

It's possible, but I'd have reservations about such an arrangement. A sprint should be short enough to be irreducable in terms of mitigating business risk. Or to put it another way, a sprint should be the smallest "chunk" of business risk that can be taken on and paid for.

If a client can only pay for a fraction of a sprint, I'd question whether the sprints are actually short enough to meet their risk appetite.

I think what Olivier meant was that the client pays some price in advance for the sprint being executed, and another price at the end if the value is delivered. This is what I meant with basis payment and bonus.
In my opinion this can be a compromise between paying each iteration (regardless if value was delivered or not) and paying only for successful iterations where the committed value was delivered.
I have made good experience with time and material. If you are payed depending on the reached sprint goal, this might lead to heavy and time wasting discussions at sprint planning about what can be done in the sprint, and even discussions at the review about if the sprint goal was met.

Well, the project is long enough for us to change the way we work. So we can start a certain way and if we find that its not working, we can then try a different route.

Setup is this.
DT are the contractors
UAT/PO/SM are the company
Client is,well, the client.

First option will be to pay per sprint as I feel that this will incentivize all parties, contractors, company and client, to perform their tasks/responsibilities at the highest level. DT will ensure quality and efficiency. SM/PO will ensure that that supply the right information and are always available. Same goes with the client, but they will also ensure that they are clear about what they want.

Might even try one or 2 sprints towards the end using NoEstimates.

I'm not sure if having the PO and the SM on the same side is better than having the SM with the Dev Team.
Of course, having the Scrum Team tears in separate company is not the best case, so each option has some drawbacks.

Agreed, but unfortunately in this case there is no other option. Luckily the relationship between contractors and company is very good.

Scenario A Paying per hour:
The worst case is that the contractor makes overhour to optimize his cashflow.

Scenario B Paying per sprint:
The worst case is that the client asks for getting amount of work done and is less prepared for making compromises on reaching the sprint goal.

Both scenarios are resulting in overhours, but normaly the client has more pull. So I tend to recommend pay per hour and limit the work time.
The contractor is then not payed for overtime and has no reason to make it. The client has no (financial) advantage on insisting on the initial sprint Goal instead making compromises.

In my opinion making compromises and focus on the absolute necessary is the key benefit of working with scrum.

Kind regards