Modern operating systems keep processes from accessing the memory of other processes. This makes data in RAM secure for most purposes. The problems are:

1. The operating system still has access to RAM. This means the administrator has access to RAM. You need to trust the owner and administrator of the machine.

2. A user has access to the RAM of all of their processes. This is definitely true of a shared hosting environment. It likely has one web server. Your scripts are probably being run as separate processes as the same user, or in the same process (this is especially true of IIS).

3. Operating systems will swap memory out to disk. The secure data can be read later from disk. C programs can control if RAM can be swapped or not, but Perl does not have that control. The solution is to keep secure strings in memory for short times as possible. One trick is to overwrite the strings when you are done with them.

I would be most concerned about the shared hosting environment. I wouldn't be concerned about the data in RAM. It takes a skillful attacker on the same machine could potentially read it, but they have easier ways to steal credit cards. The biggest risk in unencrypted numbers in a database and you have already taken care of that. I would be more concerned about the security of the private key. The key, must be accessible to the web server, which means it is probably accessible to other on the web server.