In any plan there is liable to be some difference between what you would like to be high priority and what actually is high priority. Since you're paying, you pretty much get to decide what is high priority, and you pretty much get to tell the people you're paying to work on high priority stuff first.
So, if they're avoiding code review then either:
- You are not making code review higher priority than writing more new code. You might think you are, when actually you're saying "can we get this done by the end of tomorrow?" and letting them respond "sure, if we drop everything else". "Everything else" means they skip code review on this and anything they've done recently that needs review.
- They aren't doing what you asked them and paid them to do. Since you're prepared to pay extra for code review and they'd still prefer to write new code without review for less money, you have to find out from them why code review is so unpleasant.
Either way, to get the developers involved you could look into the Scrum concept of a "Definition of Done". You could have this even if you're not doing Scrum, and include code review in your team's definition. That is, they can't say that X is finished until X has been reviewed, which means they have to find someone to review their code (and the code of the juniors they're responsible for). Hopefully this will lead to them trading off reviews with each other.
Another way to present it is that by reviewing code they are familiarising themselves with parts of the system they may need to work on in future. If you encourage shared responsibility for the whole code base, as opposed to ownership of components, then you force more eyes onto each piece of code. Granted that's not the same as a formal review phase, but it's a move in the right direction since it achieves the same goal of avoiding using code that only one person thinks is correct.
Of course if they really hate reviewing then they could choose to do a completely cursory review, passing everything more-or-less without reading it. In that case you'll have to drill deeper into the problem and convince them to do a good job. To demonstrate that review is beneficial you can point to problems that occur due to someone having goofed off a review they were supposed to do. Professionals hopefully respond fairly strongly once their mistakes are seen to cause real problems, but often less strongly if they're failing to tick off what they perceive as a pointless task. If you cannot find problems that can be at least partially ascribed to lack of review, then consider again how you decided that review really is beneficial for this project.
Another possibility, that I can't rule out from what you say in the question, is that the coders you have simply aren't very good, or at least aren't very good at producing a working project without additional technical support. You don't say anything about testing, bug-fixing, or QA in general. If all they want to do is write code, and don't want to make it actually work reliably, then naturally not doing code review would be one part of this. The flip side, I suppose, is that maybe your coders are so universally awesome that their code always works first time and doesn't need testing, bug-fixing, or review. That seems unlikely!