I'm surprised that there doesn't seem to be a canonical question and answer or at least a duplicate of this on this site - but a quick search failed to turn up anything relevant.
(There is no OS independent answer to this question - but I will address Unix/Linux for various reasons not worth going into right now).
In order to use the password it must be accessible in an unencrypted form to your application. That means the user account under which your application runs and root will have access to the plaintext. Most likely it will also be present in backups of the system, and definitely will be present in VM snapshots.
So it is impossible to be completely certain that the password will not be exposed. That means that you (or the other relevant system administrators) should be taking taking steps to mitigate this. The obvious ones are:
1) Password Rotation this limits the window in which a captured password will be of any use to an attacker. In most cases, to get a seemless change, you need to alternate between two accounts - so one is in use while the other is getting changed. Surprisingly few people bother with this.
2) Token based authentication - the password bootstraps a change of single use tokens (and is immediately forgotten by the client). Deployment of this is even rarer.
3) The use of a machine identity is growing in popularity (due to the availability of the service in clud environments). To avoid a plaintext password being stored on a computer (or an equivalent substitute such as a private key) the infrastructure vouches for the client, e.g. by providing a signed attestation which can be presented in lieu of a password. This generally requires custom software at client and server to handle the authentication.
Given your current constraints then these are not very practical solutions - that you only have a single account, using off the shelf software and no control over the server you are trying to authenticate to. A further consideration is that, using PHP, you need a low overhead on whatever mechanism you choose to store the password. Although not ideal, the most practical solutions I can think of are:
4) use the Linux kernel key storage (assuming this is linux). AFAIK, there is not a PHP extension for this - so you'd need to run an external program to retrieve the password each time.
5) store the password in a file on a ram drive (with appropriate permissions). You could use shared memory instead but the tools for interacting with the file and its contents are more limited.
6) Store the password in the webserver runtime memory and pass it to PHP at runtime as an environment variable
7) store the password in an encrypted filesystem - there's a lot of choices here, but encfs is probably the least painful and easiest to integrate with the backup.
Note that the first three require that you provision a method for injecting the credentials at boot time (not sure how you would do this for the webserver), while encryption requires that you provide a decryption key at boot time.