We've been dealing this year with a couple overseas development partners that provide particular business services. By my count we are 5 months late on the first and 2 months late with the second partner. We've had a lot of churn from unclear requirements (lawyers were involved), but a lot more from the technical side.
We just discovered this week that Partner A changed their web service out from under us without informing us. Once we got the WSDL files from them we updated our proxies easily enough, but we started seeing some problems. On one web service message we expect a null return to mean that the data simply isn't ready yet and try again later. They switched it to throwing an exception so they could "provide more information," breaking our code in the process by changing the semantics of their service. We'd try to suggest going to a DTO response coming back that could contain either the successful or not ready information coming back, but we don't have any confidence, or influence, over their solution.
Partner B has simply never done any .Net or Web Service integration work, and they seem to have very weak quality practices. I.e. obviously no unit testing or even integration testing and poor configuration management. Really bad bugs that should have been caught by simple visual inspection have gotten through to the testing environment.
Lessons Learned? Well, for one thing I would emphasize as much communication as possible early on and don't rely on documentation alone for communication. Don't assume anything about their, or your, understanding of the integration issues. Secondly, if I'm ever in this situation again (and since this is the way the world is going to work from now on it's likely), I would insist on a shared code repository or a Continuous Integration infrastructure that spans the code of both partners to find problems faster.
The two partners are on two different continents, so I'm certainly not bashing any particular country or region.