Thanks for the reply.
1. The difference between Option 1 and Option 2 is so subtle for me. They sound nearly the same. Is Option 2 a parameterized (the payment amount being the parameter) version of Option 1?
2.
... we must use property-based tests for those contract tests, because otherwise we risk sampling with values above 0 but below the threshold
That is exactly my concern (sampling values from invalid range) and I like the solution. Didn't know there exists another test methodology, property-based testing, that addresses the issue: providing a specification or a formula for test inputs instead of concrete values, to put it simply, if I didn't get it wrong. Need to explore it further.
3.
... the Client only needs to know how the Gateway signals failure. Maybe the Client only needs to know how to distinguish a technology-based failure (connection timed out) from a business failure (payment is the wrong currency, not high enough, account not recognized).
Agreed with error reporting: only one generic exception for business rule failures (with sufficient information for user as message string) will do. In my current scenario, payment failure due to payment threshold is a reasonable information that client must be aware of; a property-based testing tool too needs that information to generate inputs I suppose.
Can't see any other way than exposing the information (payment threshold) through the gateway interface and providing a degenerate threshold value (0) for the first variant (BTW, is it violation of Interface Segregation?)
4.
What is the WEAKEST assumption about the Gateway's behavior that the Client can make, but still say something useful about the Gateway's behavior?
I'm using one simple guideline, based on the Interface Segregation Principle: I want my Client to know as little as possible about its collaborators. This means agreeing on a contract with the fewest demands/constraints possible.
Concise though, these somewhat guides writing contract tests. Thanks.