Wrong card number validations

[luccasmaso]

The first case is when passing an empty string, the resulting object asserts true. It was supposed to return false, right?

import pagarme from 'pagarme'
...
console.log(pagarme.validate({card: {card_number: ""}})))

Another cases are bad errors handling for miscellaneous inputs:

This works and returns true, as it should be: console.log(pagarme.validate({ card: { card_number: "4242424242424242" } }))

But sending the same input as integer: console.log(pagarme.validate({ card: { card_number: 4242424242424242 } }))

Also, this returns true either: console.log(pagarme.validate({ card: { card_number: "424242424242____" } }))

It took me a while to actually realize what wrong with my code, as the documentation here says nothing about this validate method, and the documentation at https://docs.pagar.me/docs/obtendo-os-dados-do-cartao is too simple.

[MarcoWorms]

Thanks a lot for the feedback! We'll improve the code and the docs, I'll try to get it deployed by the end of this week.

[MarcoWorms]

By the way, if you have time and see that you can fix it we love PRs <3

[murilohns]

@MarcoWorms Taking advantage of the issue.

When i try to create a card_hash sending just the number 1 in the card_number, the following exception was launched:

But when i send other number, like 4, the following ocorred:

With it, i guess the problem is with the BIN validations, cause the number 1 does not belong to anyone brand, and the number 4 belongs to Visa.

(Não sabe como sofri pra escrever tudo isso em inglês, e provavelmente em um inglês deplorável xD)

[MarcoWorms]

@murilohns ta tranquilo o inglês! :smile: o @piiih estava de olho nessa issue hoje, vou marcar ele aqui pra ele ver esse comportamento

thanks!

[piiih]

@luccasmaso solved the integer input problem, but didn't fix '4242424242______' returning true, because card numbers have some varieties and is complicated to validate length of card number. So, if you send 4242424242 it'll be the same that 4242424242______.

@murilohns fixed your comment too.

=D

[MarcoWorms]

@piiih is this deployed or it's just merged on master? Because the problem will not be fixed for @luccasmaso until the fix is deployed, so I don't think the issue is closed until his problem is solved :)

[luccasmaso]

Thanks for the fixes! I just didn't quite understand what is the complication to validade 4242424242______ or 424242 to return false. It is still a problem for me if a user input's credit card number is incomplete, because I do not handle API errors for invalid inputs, only "runtime exceptions".

As I'm not an expert on those number variations I checked out some online tools like http://www.validcreditcardnumber.com, for example, that makes validations around the incomplete number case. What are the implications on adding a npm dependency like https://www.npmjs.com/package/card-validator to not reinvent the wheel and just appending an whitelist verification to filter pagarme allowed brands only?

[MarcoWorms]

@luccasmaso we tried to maintain backwards compatibility with the old pagarme-js validations. I do agree that 4242424242______ could throw and exception and we could only remove - from card numbers in the regex instead of all non-numbers. I'll chat with @piiih to see how we will proceed on this issue :)

[thalesmello]

The problem with the validation is because of this:

https://github.com/pagarme/pagarme-js/blob/master/lib/validations/validate/card/cardNumber.js#L41

const reduFinalSum = withoutLastDigit => (acc, digit, index, digits) => {

According to the documentation, the order should be

const reduFinalSum = withoutLastDigit => (digit, acc, index, digits) => {

Notice the order of the digits and acc arguments.

[MarcoWorms]

@piiih

[MarcoWorms]

@piiih was this fixed in the last deploy we did? can we close this? @luccasmaso are you still having problems with this validation after updating the lib?

[tappella]

Hey guys,

This was opened on August 14th and is still giving errors. Any ETA on getting it fixed to proceed with card validations?

Thank you, Thiago