Bank account/routing numbers with input type="number" cause type error about balanced-js

[mjallday]

@daliwali, can you take a look at this?

[gr0uch]

@mjallday I was able to replicate this. The problem is that it's missing some type coercion on the input. I will submit a PR for this.

[mjallday]

Thanks. Can you please submit pull-request for both the rev1 and master branches as well as test scenarios?

[msherry]

Is there ever a situation in which omitting leading zeros from a bank account/routing number will cause issues? Looking at a completely non-official list of routing numbers at http://www.gregthatcher.com/Bank/Routing/Numbers/Q , I see some that start with 0.

[matthewfl]

considering the number of edge cases around using a javascript integer and then transforming it into a string, I am -1 on allowing the number type. We should always take bank account, routing, card, cvv a string.

[gr0uch]

@matthewfl actually tokenizing a card with integer values works. Why would you want to break this now? Furthermore, we can prepend the leading zeros if the length of the string is too short. Do you mind explaining the issues that may arise?

[matthewfl]

maybe I am misunderstanding the issue, but there are issue with integers in general in javascript and I think we should avoid these in general.

[0 14:58:06 matthew]% node                                                    ~
> 9999999999999999
10000000000000000
> '9999999999999999'
'9999999999999999'
> 

[msherry]

What @matthewfl said, plus prepending digits onto what was provided by the user is magical and unexpected. How do we know how many zeroes to prepend? Bank account numbers are not standardized, and may be of various lengths, and include letters as well as numbers. I think strings are the only safe thing to accept, in general.

[matthewfl]

plus if you have a leading 0, and all the rest of the digits are < 8, then the number will be interpreted as base 8.

basically this issue will degrade into all the problems with javascript integers when used like this. IMO we should not support taking number types. I am -1 on any changes to add this bug to the js

[mjallday]

nb - the original issue is about an input with the attribute type="number". this is a good ux for users since on a mobile device it gives you a numeric keyboard. routing numbers are fixed to 9 digits so this is OK.

bank accounts are not supposed to be numeric so we shouldn't encourage or document them as so. it's entirely legal to have a bank account "number" of "abcasdwe"

[gr0uch]

@matthewfl the 16-digit rounding issue doesn't apply to routing numbers. However, the bug already affects the card tokenization, since it accepts the number type, but realistically, I don't think anyone has the card number 9999 9999 9999 9999.

The parseInt('08') === 0 problem doesn't really affect anything discussed since there's no need to coerce a string into a number here.

Perhaps bank account number must be a String, routing number can be Number or String. The error message for passing in a bank account number as a Number should be much more explicit.