top | item 5184009

jQuery.payment

449 points| Lightning | 13 years ago |stripe.com | reply

69 comments

order
[+] mey|13 years ago|reply
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|13 years ago|reply
(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.

[+] danielweber|13 years ago|reply
I do give them credit for accepting credit card numbers with spaces in them. It seems 99% of websites cannot handle spaces.
[+] asimeqi|13 years ago|reply
I worked for a gift card company and wrote and maintained some client side card validation code. My suggestion for client side card validation is "don't do it". As your client gets used more and more you will see a wild variety of cards. The minimum card length I have seen is 5. The maximum is 22. Some cards have correct checksum and some don't have checksum at all. Some cards have only numbers and some cards have letters and numbers. At the end we stripped all our fancy validation code and left only a check that card length was 3 or more.

All card validation must be server side.

[+] ux-app|13 years ago|reply
This is the reason why I don't like doing any client side validation of card data (beyond the basic check for empty fields).

I would much rather incur a 2-3sec browser roundtrip by posting raw payment details to my bank/gateway and allowing them to do the validation (they're presumably much better at it than I am).

Doing client side validation is too error prone, and considering that accepting card data is done so rarely, the (minimal) performance gain of JS validation isn't worth the risk of rejecting good data by accident.

[+] niggler|13 years ago|reply
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

[+] mauro_oto|13 years ago|reply
Also, you can enter "12/999" as expiry date, YYY. This probably just means some of the validations are done after data is submitted.
[+] batuhanicoz|13 years ago|reply
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|13 years ago|reply
I love that you are running server side JavaScript, but loading jQuery is the part that feels unclean to you.
[+] kt9|13 years ago|reply
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|13 years ago|reply
> 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.

[+] sethist|13 years ago|reply
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|13 years ago|reply
We don't prevent that. If you type '1/' the library turns it into '01 / '.
[+] jordan_clark|13 years ago|reply
Very nice. They just keep making it easier and easier to use their service. Good job @stripe!
[+] borski|13 years ago|reply
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
[+] maccman|13 years ago|reply
Fixed! Thanks for the heads up.
[+] oellegaard|13 years ago|reply
Refresh fixed that for me.
[+] daviddoran|13 years ago|reply
Same here. Might be due to serving from raw.github.com. AFAIK it's not meant to be used as a CDN.
[+] alpb|13 years ago|reply
This is why I love Stripe, thanks for contributing bits and pieces to Open Source world!
[+] nirvdrum|13 years ago|reply
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|13 years ago|reply
4 digit years are supported :)
[+] remear|13 years ago|reply
No formatting occurs when input is pasted into the field. Is this by design?
[+] ceejayoz|13 years ago|reply
The readme shows a `$.fn.formatCardNumber()` function, so I'd guess they left whether to manipulate the user input up to you.
[+] TazeTSchnitzel|13 years ago|reply
The fields seem nice, but use the cursor keys to edit and they fall apart.
[+] deadbeef404|13 years ago|reply
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|13 years ago|reply
Isn't it bad form to add 7 functions to the jQuery plugin 'namespace' in a single plugin?
[+] fijal|13 years ago|reply
any hope for us poor souls that dwell outside of the United States?