Martin Fowler has a good article just about that
Quoting him:
Integration tests collect modules together and test them as a subsystem in order to verify that they collaborate as intended to achieve some larger piece of behavior.
While:
Whenever some consumer couples to the interface of a component to make use of its behavior, a contract is formed between them. This contract consists of expectations of input and output data structures, side effects and performance and concurrency characteristics.
When the components involved are micro services, the interface is the public API exposed by each service. The maintainers of each consuming service write an independent test suite that verifies only those aspects of the producing service that are in use
These tests are not component tests. They do not test the behavior of the service deeply but that the inputs and outputs of service calls contain required attributes and that response latency and throughput are within acceptable limits.
To summarize it, integrations tests are about functionality while contract tests are about the interface, or the "language" the two sides speak.
PACT (a common contract testing framework) also have a good explanation to why Contract Tests are not Functional Tests
from their point of view:
Contract tests focus on the messages that flow between a consumer and provider, while functional tests also ensure that the correct side effects have occurred.