Handle encrypted card details

greydnls commented 9 years ago

From @alexw23 on February 18, 2015 21:56

Building out the eWay's new Rapid 3.1 Direct API. They have functionality to support client side encryption for those who don't want to forgo PCI-DSS compliance.

http://api-portal.anypoint.mulesoft.com/eway/api/eway-rapid-31-api/docs/client-side-encryption

The issue is I can't validate card as it doesn't contain any valid card details. This is what the card details turn up like.

["EWAY_CARDNUMBER"]=> string(353) "eCrypted:LkY4WI6HL/5JHWSLA4KIUnaGZCshOjxxQduNCkb59H3ZJCmKP3XoqsSxPbKak5Wr8VjQjGBV47fSsddLE+ks92gMBkj49QkrfjmMDUUrBl01biwNjNZ45Q7wQwi3UGBjTL19QIT5NLtzjXdwMfDl381ij0iR6Xc00fqG/OGPCg/2jsqDvuctRtQeJ0LhNA5Y1dJLH8BlY/DJL1L1K+cmg8bnM4InTXWUmTg/oTF4g+/kYdwYCBd6E64B+enZcuATFii79Jwz/EGfZcWGiyGjV2gpwCppSoIdXwVSrRu8l6tOnGXbqxxCNJpSvr0XLh9NzNulPr9hCKXP7cYxoyHnAA==" 
["EWAY_CARDCVN"]=> string(353) "eCrypted:KuvL5OuwKqfIyXBwMPTRQEw1LQFAAa1QJ5fI1oaj5Gk7Kr9TwjLKPC2tok7P7NfSlfvRMcAY3/lbx+zzKM9BYoDzDKHqezM8KutjR8DJ2NbPxs+ZhDoh9IdrYen7/dxIrQk4v9SmHAPHbGvF25jFEeHAnrg2ydI8NfJEqx83dSkgHzhLbXHxKnVB69LblzL0V+Nt3Qqy+UE7cfkU69ACuBJ1MfLrUXenLPHgdZWCCazGfhHa4kYBONXAgr90bb01N13KKP1KiZQIcGZt7XIB21CSTYDQ3twMXY/VO2H1A7yRFRRw/HpFsC7V6XAUdAc8IWHWFCBg6AbYp58cX/3ayA==" }

Copied from original issue: thephpleague/omnipay-common#32

incarnate commented 9 years ago

I think what @alexw23 is after is a way to handle the encrypted card details with the CreditCard object. I'm not sure if any other gateway handles card details like this, which I'd imagine would be needed for a change to the generic omnipay-common library.

Given most of the card data is encrypted, the only test that would work in CreditCard's validate() function is the expiry data tests. While the validate function isn't designed to be called outside the gateway, a possible solution may be to decompose the function into component parts (validateExpiry etc.) - this could also be a means to adding some extra validation checks like for issue number & start date which aren't always required.

I guess it's a question as to how in-scope such changes would be for Omnipay, or if validation should be taken care of elsewhere.

alexw23 commented 9 years ago

@incarnate I guess it really matters as to whether or not CSE will be a future trend in an effort to bypass PCI compliance.

Maybe the best method would be to have an encryptedCardNumber and encryptedCvc on the CreditCard object. This abstract field can then be used for future implementations of CSE.

In addition we could pass along the first 6 digits and last 4 digits which could later be pulled (when storing payment details to the database). This would also allow for getBrand and other similar functions to be used. As we have the first6/last4 the getNumberMasked function would remain to work (with some minor refactoring).

eileenmcnaughton commented 8 years ago

My feeling is that CSE WILL be a future trend - isn't that what Stripe does? I think Authorize.net offers it too. Maybe Payment Express as well

garhbod commented 7 years ago

Does anyone have a fix for this yet? Maybe adding a public function to the CreditCard object called setEncryptedNumber That sets the number parameter but preserves non-numeric characters from being stripped out

incarnate commented 7 years ago

No fix as yet. There is issue thephpleague/omnipay-common#57 to provide a function for this which Graham flagged for version 3. I can see an alpha for v3 was released last week, so a good time to follow up there.

eileenmcnaughton commented 5 years ago

I've added a PR which provides a way forwards on this with a very small amount of code - https://github.com/thephpleague/omnipay-eway/pull/29

It may be that the upstream solution suggests a better change later - but I don't think that should hold this up as it would stay internal to omnipay-eway and be invisible to the calling function

thephpleague / omnipay-eway

Handle encrypted card details #9