A Pass Type ID certificate is the signing identity for one pass type identifier. Apple issues it to the developer account that registered the identifier, and every pass of that type must be signed with its private key before Apple Wallet will accept it. It is the concrete artifact behind the sentence "the merchant owns the pass type".
Getting one is a short ritual in the Apple Developer portal. The holder generates a key pair and a certificate signing request, a CSR, on their own machine, so the private key never leaves it. They register the pass type identifier, upload the CSR against it, and download the certificate Apple returns. Certificate and key are then usually exported together as a PKCS #12 file and handed to whatever signs passes. The certificate chains to Apple's WWDR certificate, which the signing step includes as well.
The certificate expires, and renewal is the same ritual. Passes already in wallets keep working after expiry, because their signatures were valid when made, but no new pass and no update can be signed until the certificate is renewed. That is the most common self-inflicted outage in pass programs, and a platform should be tracking the expiry date rather than discovering it.
Who holds the certificate matters more than how it is made. If the identifier is registered in the merchant's own developer account, the merchant issues the certificate and can hand it to a provider, and take it back. If the identifier lives in the provider's account, the provider holds the only signing identity for the program's passes, and moving away means reissuing every pass. The certificate is the reason the ownership question is asked before the first pass is designed, and it is tied to the account's Team ID, which the pass carries alongside the identifier.