In consumer-driven contract testing (CDCT), the provider replays every consumer's pact against its real code, which requires the provider team to add Pact verification to their build. That's often impossible with a third-party API, a legacy system or a team that won't adopt Pact.

Bi-directional contract testing, a feature of PactFlow (SmartBear's commercial Pact Broker), removes the replay step:

• The consumer publishes its expectations as before, for example a pact generated by Pact tests or converted from existing mocks.
• The provider publishes its OpenAPI description, together with evidence that its own tests confirm the implementation matches it.
• PactFlow compares the two statically and reports whether every consumer expectation is covered by the provider's spec. can-i-deploy then works as usual.

The trade-off is trust in the spec. CDCT proves the real provider handles the consumer's requests, while BDCT only proves the spec covers them, so it is only as good as the provider's own testing against that spec. For a third-party API you can't influence, BDCT at least catches the consumer relying on something the published spec doesn't promise.

Sources: PactFlow: bi-directional contract testing, Pact docs