Encryption and debit card numbers

Online retailers would like to make it as straightforward as possible for existing customers to make multiple purchases. Clearly they would like to store the credit and debit card numbers of their clientele, so when they come back, they don't need to re-enter their card details. However, when the sensitive data is stored, it might be leaked, the consequences of which would be severe. It would of course make sense to encrypt the data before saving. But to use the card number, it will need to be decrypted and so, there is a risk that the unencrypted data will be obtained by a criminal due to staff incompetence or corruption. So what should a retailer do?

One option would be to use public key encryption, but rather than use the retailer's own public key, they could use the card issuer's public key. The card number could be encrypted in the browser of the client and then sent to the retailer's server to be stored. In this case if there were some dishonest employees working for the retailer, they still wouldn't be able to decrypt the card number. When the retailer wants to request a payment from the card issuer, it can send the encrypted number and the card issuer will be able to decrypt it.

However, if it were to become standard practice for firms to use the encrypted number, then that encrypted number would be like a proxy for the original card number. In that case if it were leaked, it would once again be problematic. One way round that would be to tag the card number with the retailer ID first, before encrypting it. That encrypted data would be useless to any other retailer, corrupt or otherwise. In that case the head of information security at the retailer would sleep well at night.

All that assumes that the public key encryption of the card issuer hasn't been compromised. But just in case it has been, one option would be for the retailer to put an extra layer of encryption. On the retailer's website, it may make sense to first encrypt using the card issuer's public key and then encrypt again with the retailer's public key. The doubly encrypted data would be transmitted and then stored. Before the payment request is sent to the card issuer, the outer layer of encryption would need to be removed (decrypted).