I'm not quite sure whether irreversible encryption is a thing in this context (its sometimes used to talk about e.g. password storage, but I think that's a very different use-case), so I'll sally in with an interesting tangent:

https://en.wikipedia.org/wiki/Homomorphic_encryption

   Homomorphic encryption is a form of encryption that allows
   computation on ciphertexts, generating an encrypted result
   which, when decrypted, matches the result of the 
   operations as if they had been performed on the plaintext.

   Homomorphic encryption can be used for secure outsourced
   computation
   ...

That's interesting, but how do you prevent bad guys from "generating an encrypted result" that you don't want?

If the variant of the homomorphic encryption you are using is secure, then the bad guys can not generate specifically crafted cyphertext that would decrypt into the result they specifically want.

This doesn’t really exist yet.

I would agree with this sentiment, however, there are a number of things that you can to to make the job of the attacker harder, or to notice internally when there is inappropriate usage. Service abstractions to encrypt/decrypt the data will limit the surface area where you might store keys. Logging usage to know what operations were made. Also, you can use a system like vault such that the keys are not extractable to do all the crypto operations offline thus massively increasing the chances you would detect such a breach / unauthorized access.

No, not the "we store decryption keys on our user facing app servers" part.

The decryption should happen on back-office payment processing server, with the keys held by a hardware security module.

Or better yet don't store the card details at all, but there are valid business reasons that is sometimes necessary.

In my early days, I had to write a payment processor and it pass a PCI "inspection."

TL;DR - PCI compliance was a joke in my experience.

The payment page didn't log requests (made figuring some things out hard), it submitted the encrypted card data (public key) to another server through the firewall with only a single non-standard port open, to the data store with write only access. There was then a trigger on insert that would launch a small console app that passed the decrypted (private key stored locally) card and charge information to Authorize.Net, if successful it would then write a success to the charges database, and send that charge identifier to the application's data store.

Only access to the payment server was from behind the firewall over RDP and MSSQL over non standard ports.

Just the description of this satisfied the PCI guy, and no physical inspection of the hardware was ever done. I'm not sure if what I did was best practice, and I was always so scared it would get hacked. Thankfully after so many fraud charges that my boss couldn't handle the $15 chargebacks we switched to paypal and I no longer had sleepless nights.