The merchant ID is how an Apple VAS reader says which pass it wants. Every reader configured for a loyalty program carries the ID for that program, includes it when it polls for nearby devices and again when it selects the VAS applet, and the iPhone or Apple Watch matches it against the passes in the wallet. If a pass matches, the phone answers with that pass's payload; if none does, nothing is presented.
It is not a secret and it is not assigned. The merchant ID is derived from the program's pass type identifier by hashing it, which means anyone who knows the identifier can compute the ID, and every pass of that type carries the same one. Terminal and reader vendors typically ask for the pass type identifier and derive the ID themselves, or accept the computed value directly.
The secret sits next to it. Alongside the merchant ID, a reader holds the private key of the program's VAS encryption key pair, and the pass carries the matching public key. The ID selects the pass; the key decrypts what it sends. A reader with the right ID but the wrong key gets a payload it cannot read, which is the usual cause of "the pass presents but the terminal shows nothing". Keys are exchanged as DER-encoded material, see X.509, and are the part of the setup that needs to be handled with care.
Because the merchant ID is tied to the pass type identifier, it is also tied to ownership. If a program's passes are reissued under a new identifier, every reader must be reconfigured. Keeping the identifier in the merchant's own Apple Developer account keeps the merchant ID stable across providers.
The Android counterpart is the collector ID used by Google Smart Tap. A reader configured for both sends both, and a phone on either platform answers with its own pass.