Version every application by its Git commit SHA, record the branch it came from, and record deployments per environment. Pact now recommends branches and environments over the older tags, where "staging" was often misused as a tag on a version:

# When the consumer's tests pass: publish its pact with version and branch
pact-broker publish ./pacts \
  --consumer-app-version "$GIT_SHA" \
  --branch "$GIT_BRANCH"

# Before deploying any service: check it against what is running there
pact-broker can-i-deploy --pacticipant UserService --version "$GIT_SHA" --to-environment staging

# After the rollout completes: tell the Broker which version is now running there
pact-broker record-deployment --pacticipant UserService --version "$GIT_SHA" --environment staging

For a Kubernetes rolling update, run record-deployment after kubectl rollout status reports that the rollout succeeded, not when you apply the manifest. Mid-rollout, old and new versions serve traffic side by side, which is why can-i-deploy must pass against the version already there before you start. If you roll back, record the deployment of the version you rolled back to, so the Broker's view matches the cluster.

Sources: Pact: branches, Pact: recording deployments and releases, Pact: can-i-deploy