Handle encrypted card details #9
Comments
|
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. |
|
@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). |
|
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 |
|
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 |
|
No fix as yet. |
Eway already supports encryptedCardNumber as a paramter. However, that relies on the calling code 'knowing' whether the card has been encrypted - which would not happen if a script blocker was in play and is hard for the calling code to adapt to generically. However, at this point in the code we know that if it is following the eway format for being encrypted then it has been encrypted. I would note that it is supported by the Request object not the credit card class but a) that is already the case, this just makes it a bit simpler to use and b) the encryptedCardNumber does not hold sensitive data in the same way that the 'card' parameters do. The upstream plan appears to be to have another class to handle this - in which case this bit of handling code and the code that interacts with it could be updated later to reflect that
|
I've added a PR which provides a way forwards on this with a very small amount of code - #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 |
Eway already supports encryptedCardNumber as a paramter. However, that relies on the calling code 'knowing' whether the card has been encrypted - which would not happen if a script blocker was in play and is hard for the calling code to adapt to generically. However, at this point in the code we know that if it is following the eway format for being encrypted then it has been encrypted. I would note that it is supported by the Request object not the credit card class but a) that is already the case, this just makes it a bit simpler to use and b) the encryptedCardNumber does not hold sensitive data in the same way that the 'card' parameters do. The upstream plan appears to be to have another class to handle this - in which case this bit of handling code and the code that interacts with it could be updated later to reflect that
Eway already supports encryptedCardNumber as a paramter. However, that relies on the calling code 'knowing' whether the card has been encrypted - which would not happen if a script blocker was in play and is hard for the calling code to adapt to generically. However, at this point in the code we know that if it is following the eway format for being encrypted then it has been encrypted. I would note that it is supported by the Request object not the credit card class but a) that is already the case, this just makes it a bit simpler to use and b) the encryptedCardNumber does not hold sensitive data in the same way that the 'card' parameters do. The upstream plan appears to be to have another class to handle this - in which case this bit of handling code and the code that interacts with it could be updated later to reflect that
Eway already supports encryptedCardNumber as a paramter. However, that relies on the calling code 'knowing' whether the card has been encrypted - which would not happen if a script blocker was in play and is hard for the calling code to adapt to generically. However, at this point in the code we know that if it is following the eway format for being encrypted then it has been encrypted. I would note that it is supported by the Request object not the credit card class but a) that is already the case, this just makes it a bit simpler to use and b) the encryptedCardNumber does not hold sensitive data in the same way that the 'card' parameters do. The upstream plan appears to be to have another class to handle this - in which case this bit of handling code and the code that interacts with it could be updated later to reflect that
Eway already supports encryptedCardNumber as a paramter. However, that relies on the calling code 'knowing' whether the card has been encrypted - which would not happen if a script blocker was in play and is hard for the calling code to adapt to generically. However, at this point in the code we know that if it is following the eway format for being encrypted then it has been encrypted. I would note that it is supported by the Request object not the credit card class but a) that is already the case, this just makes it a bit simpler to use and b) the encryptedCardNumber does not hold sensitive data in the same way that the 'card' parameters do. The upstream plan appears to be to have another class to handle this - in which case this bit of handling code and the code that interacts with it could be updated later to reflect that
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.
Copied from original issue: thephpleague/omnipay-common#32
The text was updated successfully, but these errors were encountered: