The pass web service is the server side of a live Apple Wallet pass. Its address is declared in pass.json as the web service URL, next to the authentication token, and from the moment a pass is added, the member's device talks to that address on its own, with no app involved.
Apple defines the conversation as five endpoints. When a pass is added, the device registers itself, handing over the push token that later push updates will use; that is device registration. When a push arrives, the device asks the service which serial numbers have changed since it last looked. For each one, it requests the latest pass, and the service returns a freshly signed PKPass. When the pass is deleted, the device unregisters. And a log endpoint lets devices report errors, which is the first place to look when a pass "will not update".
Two details in that flow explain most production behavior. The service says whether anything changed by comparing timestamps, so a well-built service answers most polls with "nothing new" and only builds a pass when a balance, tier or message actually moved. And every call carries the authentication token in its header, so a service that does not recognize the token simply refuses, which is why the token is per pass rather than per program.
The URL is signed into the pass. It cannot be edited remotely, and the passes already in members' wallets will keep calling the address they were issued with. That is the practical heart of pass migration: a new provider has to answer at the old URL, or the old provider has to forward, or every member re-adds their pass. Ask whose domain the web service runs on before the first pass is issued.
Google Wallet has no equivalent. A pass object lives on Google's servers and the issuer updates it through the Wallet API, so there is no per-pass callback service to host or to move.