Contact your third party and ask them to configure their server/service to send the intermediate certificate(s) as per RFC 5246 Section 7.4.2. Specifically, the section marked certificate_list which is sent as part of the Server Hello message.
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
If the intermediate certificate(s) change, it's up to the sender to update their service to send the new certificate. That is, it is not up to all the recipients to realise that things have broken, find the replacement certificates, then install them on all their relying parties.
There is also the option for the operators of the service to use certificates which contain the AIA extension (RFC 5280 Section 184.108.40.206 -
accessLocation field) which can contain an URL which points to a repository (HTTP more than likely) that contains the issuer certificate for download. This requires both the extension to be present (that's up to the issuing CA) AND your app to check it (that's up to your developers). This extension is a Microsoftism, added to compensate for substandard service administration - the RFC is quite clear about what should happen.