The partner is not ready and go-live is not moving. Stubs, mock endpoints and recorded payloads — and WHAT EACH OF THEM CANNOT TELL YOU.
This situation is normal rather than exceptional. The bank's test environment appears in week nine of a ten-week project; the partner's API is documented and not yet built. You build against something you invented, and the whole risk is forgetting that is what you did.
A RECORDED PAYLOAD IS THE STRONGEST OPTION AND IS USUALLY AVAILABLE. A real response captured from the real system once, replayed. It is real data in a real shape, so it tells you the mapping handles what that system actually sends — and it tells you nothing about any other response, including every error.
A MOCK ENDPOINT ANSWERS THE SHAPE YOU WROTE INTO IT. It exercises the call, the parsing and the mapping, and it is entirely a description of your own assumptions. Every difference between your reading of the specification and the system's behaviour is invisible, because the mock agrees with you by construction.
A STUB THAT ALWAYS RETURNS SUCCESS IS THE WEAKEST AND THE MOST COMMON, and it is genuinely dangerous. It proves the flow can send a request. It cannot tell you about a rejection, a timeout, a rate limit, or a slow response — so every failure path in the integration remains untested while the test report reads green. Lesson 7's second failure.
SO USE THEM, AND WRITE DOWN WHAT REMAINS UNPROVEN. The deliverable is not "tested" but "tested against a mock; connectivity, authentication, real payload shapes, error responses and timing are unverified." That sentence in a handover is what makes the first day of real connection a planned event rather than a discovery.
AND BUDGET TIME FOR RE-TESTING WHEN THE REAL SYSTEM APPEARS. It is not a formality — it is where the differences between your mock and reality all arrive at once, and it needs days rather than the hour usually left for it.