

jQuery.payment - Lightning
https://stripe.com/blog/jquery-payment

======
mey
There are several incorrect assumptions about this library

    
    
      Cards can be up to 19 digits
      Bin ranges are constantly updated, so cardType in static code is a broken concept.
      I expect in the future American Express will issues cards longer then 15 digits.
      Minimun card length is 13 digits not 10
    

I don't feel like validating the luhn check, but historically I've seen
systems that don't correctly handle the luhn check of variable sizes.

Edit: Reference material <http://en.wikipedia.org/wiki/Bank_card_number> If
you are actually getting into credit card processing, please talk to your
acquirer about data feeds of this type of info on bin ranges.

Edit 2: Wikipedia claims Maestro has 12 digit cards, but I've never seen one
in the wild, I could be wrong about 13, but it's the assumption we've made
processing international payments.

~~~
pc
(I work at Stripe.)

Thanks. I don't think these are so much incorrect assumptions so much as
things we should change if the world changes.

19-digit IINs are found on UnionPay, Maestro, and other international cards
that Stripe doesn't support today. We might add support for them in the
future.

As to the others (e.g. American Express cards with more than 15 digits): we'll
certainly add support if this changes.

~~~
badgar
> Thanks. I don't think these are so much incorrect assumptions so much as
> things we should change if the world changes.

Is that not the definition of an assumption? Something you rely on being true
and not changing, and which if it does change, requires reaction?

These are incorrect assumptions. It's okay to have them, you don't have to be
perfect, but don't redefine "assumption" because you're embarrassed.

~~~
cwp
Gimme a break. The assumptions are correct, for now. If they become incorrect,
Stripe will update the software accordingly. This is exactly how good software
is written and managed. Patrick has nothing to be embarrassed about.

------
niggler
EDIT 2: appears that the issue was fixed:
<https://github.com/stripe/jquery.payment/issues/1>

Original Message: The card number is not linked to the CVV length:

343725117665768 is a valid american express number (generated from
<http://www.getcreditcardnumbers.com/>)

Their CVV numbers are 4 digits, yet the inputs

    
    
        343725117665768
        12 / 21
        123
    

seems to pass ...

EDIT: filed issue: <https://github.com/stripe/jquery.payment/issues/1>

~~~
pc
We make it easy to do card type-specific CVC validation:

    
    
      $.validateCardCVC('1234', 'amex');
    

More at <https://github.com/stripe/jquery.payment>.

~~~
niggler
I would think a combined validateCardAndCVV (taking both the card number and
the CVV) would be the correct approach here ...

------
batuhanicoz
This may be useful with Node too. I wish it wasn't a jQuery plugin but a
framework independent library.

(I'm aware I can use jQuery on the server-side, but why load jQuery only for a
credit card number validation library?)

Other than that, this looks good. :)

~~~
dsl
I love that you are running server side JavaScript, but loading jQuery is the
part that feels unclean to you.

~~~
tracker1
Node is very lightweight and fast... jQuery requires jsdom which means loading
a virtual DOM environment which is very heavy for server-side processing.

------
kt9
The thing I love about stripe is that they're so focused on building the best
customer experience and software that solves customer problems!

~~~
jpdoctor
> _The thing I love about stripe is that they're so focused on building the
> best customer experience and software that solves customer problems!_

As long as your customer problems are not about low fees or ACH, that is.

------
lbarrow
How does this compare with <https://github.com/PawelDecowski/jQuery-
CreditCardValidator/>?

------
sethist
This looks nice, but I ran into an immediate usability issue. The Card Expiry
requires a leading 0 for January. It seems like bad UI to prevent a user from
enter 1/13 or 1/2013 in those fields.

~~~
maccman
We don't prevent that. If you type '1/' the library turns it into '01 / '.

~~~
sethist
Fair enough, I haven't dug into the code yet. I was basing my comment on the
live demo which prevents it.

~~~
dasil003
Huh? If you literally type '1/13' into the live demo it works as one would
expect. '113' works too, it just assumes the month is eleven, and the year
starts with 3.

~~~
sethist
I was referring to the live demo at
<http://stripe.github.com/jquery.payment/example/>. Either way, I wouldn't
consider the library interpreting 113 as 11/3 as a "working".

~~~
zaidf
So what do you suggest "113" should be interpreted as?

~~~
sethist
There are three ways to interpret it. It is either 11/3, 1/13, or an error.
Since 11/3 isn't a valid date, I think it is safe to rule that out as an
incorrect interpretation. Either of the other two interpretations seem
acceptable to me.

~~~
aiiane
Er, since when is 11/3 not a valid date?

~~~
tracker1
Not for a credit card expiration date...

~~~
dasil003
How would you type in 11/30 if it blurts out a big error the moment you type
113?

~~~
sethist
The same way the system allows you to type in 0213 without blurting out a big
error the moment you type 02. Just don't validate the input while the user is
still inputting it.

Secondly, remember this is for credit card expirations and not normal dates.
You can probably make an assumption that 11/30 (November 2030) isn't currently
valid input either. I have never seen an expiration date further than 10 years
in the future. Although more research on the topic would be needed to figure
out the true restrictions.

~~~
dasil003
I don't know why the live demo is broken, or why they even need is since there
is a live demo on the main page, but the usability for all cases strikes me as
exceptional _on the main page where it works as intended_. I am not convinced
that your cherry-picked restriction improves the usability.

------
jordan_clark
Very nice. They just keep making it easier and easier to use their service.
Good job @stripe!

------
borski
The JS load is failing on this page. :(

    
    
      Failed to load resource: the server responded with a status of 403 (Forbidden) https://raw.github.com/stripe/jquery.payment/master/lib/jquery.payment.js
      
      Uncaught TypeError: Object [object Object] has no method 'formatCardNumber' jquery-payment:50

~~~
oellegaard
Refresh fixed that for me.

~~~
borski
Hm. I'm still getting the 403. I emailed them just in case.

------
alpb
This is why I love Stripe, thanks for contributing bits and pieces to Open
Source world!

------
nirvdrum
Supporting 4 digit years might help on the usability front. I'm probably a
special case, but I forgot what the format was, as it disappears immediately
upon clicking on the field, and naively went with a 4 digit format. There's no
helpful error message on the demo page either -- the field just highlights in
red.

I don't immediately how much is just how that form was constructed vs. what's
done in the JS lib.

~~~
maccman
4 digit years are supported :)

~~~
nirvdrum
Ahh, maybe it's the demo page that doesn't support them then? They came up as
an error for me.

------
remear
No formatting occurs when input is pasted into the field. Is this by design?

~~~
ceejayoz
The readme shows a `$.fn.formatCardNumber()` function, so I'd guess they left
whether to manipulate the user input up to you.

------
TazeTSchnitzel
The fields seem nice, but use the cursor keys to edit and they fall apart.

~~~
deadbeef404
Just because I like breaking things; they've tried to stop text getting into
the fields by typing/pasting in the fields. A way around it is to highlight
text/characters in the browser or the address bar etc and drag them into the
field.

------
theycallmemorty
Isn't it bad form to add 7 functions to the jQuery plugin 'namespace' in a
single plugin?

------
fijal
any hope for us poor souls that dwell outside of the United States?

