It depends how we articulate the contract. What does the Client (meaning the union of all Clients) of the Payment Gateway need to know about it? What is the _minimum_ that it needs to know?
Option 1: The Client knows that the Payment Gateway might charge any positive amount.
Option 2: The Client knows that whatever amount the Payment Gateway charges, that amount is positive.
With Option 1, the situation you describe creates a problem; but with Option 2, it does not. With Option 2, both variants satisfy the contract, although it might be easy to write an incorrect test for that contract. I have in mind that we must use property-based tests for those contract tests, because otherwise we risk sampling with values above 0 but below the threshold, and the test would accidentally fail.
So what does the Client really need to know? 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? Option 2 is weaker than Option 1, so I would probably prefer it. In fact, we could even generalize Option 2 to "whatever the Gateway charges, that amount is greater than N currency units", and with Option 1, N=0.
At best the Client needs to know that some payments succeed and others fail, and maybe the Client doesn't need to know the reason for that failure. That sounds even better: different variants of the Gateway fail for different reasons (thresholds, currency, authentication failures, whatever) and 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). This way, both variants satisfy the contract.
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. I look for ways to push details out of the contract and down into the implementation. It's possible that this guideline suffices for most people most of the time!