The fiat-to-crypto onramp passed verification on my laptop every run. Approved, instantly, each time.
In production that same code left people suspended mid-signup.
The difference was not config, and it was not the code. It was which states the provider was willing to emit. The sandbox I had built against answered with a decision. The live integration answered with pending manual review, then came back later through a webhook, sometimes asking the user to resubmit a document, sometimes expiring the session before anyone looked at it.
My state model had two outcomes. The real system had a queue with humans in it.
The cost was not an outage, which is why it took a while to feel urgent. It was a stall: users who had already committed money sitting in a state my code had no transition out of, and me moving them along by hand while I rebuilt the flow around the states I had never seen.
What I do differently now: I map the dependency's full state machine before I write the happy path, and I keep fixtures for the inconvenient states (pending, resubmit required, expired, approved after an initial rejection). Local success has to mean my environment reproduced those, not that the call returned 200.
A vendor sandbox is a simulator of the vendor's optimism.
If you integrate KYC or payment providers, your state model probably comes from their documentation rather than from the responses you have actually observed in production...