Storing credit card details

前端 未结 10 944
长发绾君心
长发绾君心 2020-11-27 11:10

I have a business requirement that forces me to store a customer\'s full credit card details (number, name, expiry date, CVV2) for a short period of time.

Rationale:

10条回答
  •  夕颜
    夕颜 (楼主)
    2020-11-27 11:32

    Lets look at the requirement a little differently. Currently it looks like this:

    As a product owner for website X i want the system to temporarily store a customers cc details so that i can recover a sale that was declined by the CC company

    Ppl tend to think like that and request features in that manner. Now i think your requirement is more conveniently described as follows:

    As a user i want website X to be able to retry payment for my purchase so i dont have the hassle of having to go thru the checkout process again coz that is a real pain in the...

    So there's no explicit requirement for storing anything (on your side) is there? Its only implied

    Payment providers can provide programmatic APIs to your merchant account and the ability to attempt a re-auth on a declined attempt. i think @bashmohandes eluded to this earlier

    Not all payment providers can do this however i think its dependent on their relationships with the banks involved. Thats the stuff you want to avoid ie. having a close relationship with banks.

    Scenario 1: Assuming all i said is true

    You don't have to store anything but a reference to the authorization attempt. Some payment providers even give you a sweet backoffice tool so you dont have to make your own to do re-auths. I think paygate does this

    Your best bet i believe is to interview a number of payment providers. they should know this stuff like the back of their hands. This is potentially a zero-code solution

    Scenario 2: Assuming i'm like totally wrong but legally this storing CC stuff is ok

    So you have to store that data somewhere temporarily. I advise:

    • use a 2-way encryption method (naturally) that is non-vendor specific so you can use any language/platform to encrypt/decrypt
    • decouple the encrypt/decrypt service from your app and treat it like a black box
    • use public/private keys for authentication to this service
    • put this machine on a private network with its own elevated firewall rules (doesn't have to be a hardware firewall but hardware is better)
    • have your app servers communicate with this machine via ssl (you could get away with a self-signed cert since its on your private LAN)

    All i've suggested in scenario 2 is hurdles but eventually persistence wins the race to get to your data. The only way to absolutely secure data is to unplug your server from the ether but that option is a little radical :-)

    Scenario 1 would be nice. Wouldn't it?

提交回复
热议问题