The state can be an arbitrary value. In the future , the state parameter is used to prevent Cross-Site Request Forgery (CSRF) attacks. In addition to this, because the redirect_uri parameter is fixed in the production version, the state can be used to distinguish users.
The same value will be returned to the [REDIRECT_URI] as a state parameter. For example: if you included parameter state=4cac8f43 in the authorization URI, when the user is redirected to [REDIRECT_URI], the URL would contain that same value in astate parameter. The value of state should be unique for each request.
In terms of differentiating merchant, you can do so by state. In the first call, the authorization call, you set a state. MobilePay then returns this state, when you obtain the authorization_code. This way, you can differentiate, if you have more merchants working on the Consent process. Afterwards, it is your responsibility to manage, which tokens belong to which merchants. This is solely a security aspect, that we do not enclose information about this, when you get the refresh_token. But this is also a response for a call, that you initialised yourself, and the response comes instantly. This is why there shouldn't be any confusion.
Identity server will echo back the state value on the token response, this is for round tripping state between client and provider, correlating request and response and CSRF/replay protection.