The difference between contract tests and functional tests (or How To Do Pacts In a Way That Won't Make You Want To Stab Your Eyes Out)

Because I'm short on time right now, I'm going to copy-paste this conversation from gitter which I think explains it well.

Pierre Vincent @PierreVincent 05:09
This is pretty subtle, but I find when testing for error scenarios like these (which are pretty much “validation failed” scenarios), the scenario should not specify the why of the validation failure, but more than for some reason validation failed.
What the contract is there to validate is how the server responds when rejecting a request, but not why it rejects the request.
So rather than naming your scenario using validation rules of the provider (which is provider business logic), just name your scenario about a failure case.

Ex:
"description": "a request to allocate stock to a product",
"provider_state": "the product can be allocated",
expected status: 200 OK

"description": "a request to allocate stock to a product",
"provider_state": "the product cannot be allocated",
expected status: 400 BAD REQUEST

This is much nicer to allow flexibility to the provider to manage its own validation rules.