search

thephpleague / omnipay-common

Core components for the Omnipay PHP payment processing library
MIT License
330 stars 244 forks source link

Set raw number #57

Open micbenner opened 9 years ago

micbenner commented 9 years ago

While easily extendable to add, I think the CreditCard class should ship with a 'rawNumber' attribute, thereby allowed a credit card number to be set without the code stripping non-numeric characters.

The reason being that many providers, such as Eway, allow for credit card numbers to be encrypted before being sent. The fact that this field unknowingly removes non-numeric characters is quite a "gotcha"

greydnls commented 9 years ago

The non-numeric characters are stripped for the Luhn validation. It might be a better idea to create a separate class such as EncryptedCreditCard that has the raw number as you suggested, and skips the luhn check.

Would that solve the problem that you're currently having?

micbenner commented 9 years ago

This was awhile ago but it sounds like the perfect solution.

greydnls commented 9 years ago

Awesome, I've got it marked for V3 release which will hopefully be coming in the near future.

micbenner commented 9 years ago

Great to hear!

Thanks a bunch.

On Tue, Oct 13, 2015 at 5:42 PM, Kayla Daniels notifications@github.com wrote:

Awesome, I've got it marked for V3 release which will hopefully be coming in the near future.

— Reply to this email directly or view it on GitHub https://github.com/thephpleague/omnipay-common/issues/57#issuecomment-147599872 .

SilverPreece commented 6 years ago

V3 is out now - was this included? Client is asking if we can support this for PCI-DSS.

barryvdh commented 6 years ago

I don't think so.

judgej commented 6 years ago

I tend to use the cardToken field to supply non-lunn strings that represent a card. Never done it for an encrypted card number though, normally it's a reference to a CC record (which usually includes all details entered for the card) temporarily stored at the gateway. Could an erupted card number arguably be a card token?

I'm just looking at a gateway that separately encrypts the CVV, expiry date and name too, all in individual fields, so it's going to be fun working out how that is going to fit in. We don't want to end up with rawExpiry, rawCvv, etc

eileenmcnaughton commented 5 years ago

Having just dug into this with eway I think one design consideration is that the Omnipay plugin rather than the calling code should be making the decision about whether the card has been encrypted. The addition & success or otherwise of an encryption script is hard to detect in a gateway-agnostic way in the calling code - but pretty easy to check within the plugin as each Gateway has it's own conventions