The problem
Partner integration is where most commerce platforms accumulate their hardest operational problems. Each partner has its own data model, its own notion of what an error means, its own release cadence, and its own availability — and none of those are within your control. Integration code written as if the other side behaves becomes the most expensive code in the system to maintain, because every partner change lands on it.
How we approached it
Translate at the boundary, so each partner's model is converted once into an internal one and partner-shaped assumptions never reach the core.
Treat partner unavailability as an expected state with a defined behaviour, rather than as an exception to be logged.
Keep transactional correctness explicit across services that can each fail independently, instead of inferring it from the happy path.
Reconcile continuously, because catalog and pricing data updated by several sources will diverge and the only question is whether you find out before the customer does.
Where it landed
Partner changes are absorbed at the boundary instead of rippling through the platform, an unavailable partner produces a known behaviour rather than an incident, and divergence in shared data is detected by reconciliation rather than by a customer report.
No percentages or dollar figures appear above. These are our own products, and the structural changes described are checkable; a number attached to them would not be. We would rather publish the former than invent the latter.