X.509 is the standard shape of a digital certificate: a public key plus who it belongs to, who vouches for it and how long it is valid, signed by an issuing authority. Every certificate in wallet pass work, Apple's Pass Type ID certificates, the WWDR intermediate that vouches for them, the equivalents on the Google side, is an X.509 certificate.
DER is how those bytes are written down. It is the strict binary encoding of X.509 structures, one exact byte sequence for a given certificate or key. The same content is often wrapped in base64 with BEGIN CERTIFICATE markers to survive text channels; that wrapper is PEM. One certificate, two encodings, and most tooling converts freely between them, so "DER-encoded" describes packaging, not a different kind of certificate.
The encoding becomes visible at configuration edges. The NFC block of an Apple Wallet pass carries its encryption public key as a base64 DER-encoded EC key; readers and payment terminals expect keys in specific encodings when they are configured to decrypt taps; signing tools want the certificate chain in one form or the other. Most integration friction with certificates is not cryptography at all, it is a PEM file where DER was expected or the reverse.
Certificates rarely travel alone; paired with their private key they move as a PKCS #12 bundle. And as with those bundles, a managed platform keeps this below the waterline: Stell emits keys and certificates in the encoding each counterpart expects, so the terms matter mainly for reading an acquirer's setup form correctly.