The customer uses an SSL enabled browser to access your application. We have to assume that this is secure as the communications are going to get. If SSL is compromised then everything is in the open. The browser may similarly be compromised. If this is the case then all of the customer's transactions are compromised.

The application stores the encrypted credit card number in a database such that it is written to disk. The encryption needs a key which also has to be stored. The encrypted records are written to disk which means that they could be recovered even if they have been deleted from the database. Storing the credit card information to non-volatile storage is a security headache.

The application is hosted on a third party computer that may also host other peoples code. You cannot assume that the system is secure at all. It is subject to both physical and remote access from other people. This issue is best tackled with expensive SLAs, contracts and indemnity clauses.

If I was doing this I would avoid the problem all together and leave out screen four. The customer supplies their credit card details once and the application sends it for processing. If you do this then you don't need to store their credit card info to a database at all.