5 ms·

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

by mey 14y ago

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 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 14y ago
(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.
- maccman 14y ago
  We'll get UnionPay & Maestro support added shortly.
- badgar 14y ago
  > 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.
  - Skywing 14y ago
    > 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. What is there to be embarrassed about? Seriously.
  - wilsaj 14y ago
    It's not a redefinition of "assumption" but rather a justification as to why these assumptions should not be qualified as "incorrect".
  - cwp 14y ago
    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.
- mey 14y ago
  I took the goal of the library as general purpose, not stripe purpose. Sorry for my personal incorrect assumption.
  - pc 14y ago
    No problem. The goal is to be general purpose, though, and to that end we just added support for UnionPay, Maestro, and Laser: https://github.com/stripe/jquery.payment/pull/5 https://github.com/stripe/jquery.payment/pull/5.
    - mey 14y ago
      Awesome :)
deleted 14y ago
[deleted]
danielweber 14y ago
I do give them credit for accepting credit card numbers with spaces in them. It seems 99% of websites cannot handle spaces.
- jonknee 14y ago
  I have had this discussion a few times and at least for me it's usually sticking to ridiculous TOS from the payment gateway and less in programming competency. If your gateway says you're not allowed to change anything in the input and the gateway does not accept spaces you can either break your contract or not allow spaces.
  - pbreit 14y ago
    > not allowed to change anything in the input I've never seen such a term. Have any examples?
asimeqi 14y ago
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.
- ceejayoz 14y ago
  Gift cards aren't credit cards. The docs say "a general purpose library for building credit card forms", not "a general purpose library for building payment forms".
- jfoster 14y ago
  How does it become easier to do such validation server-side?
  - cj 14y ago
    You can attempt to process it through your payment gateway (ie. stripe) and check for a success or failure.
    - jimktrains2 14y ago
      That becomes expensive. The more you can do on your own, the less in fee's you'll accumulate.
ux-app 14y ago
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.
- alttab 14y ago
  You, but whatabout a laymen user who doesnt care ehat your justifications are? They want people to build snappy mobile web apps. This creates competition and legitimacy for them
  - ux-app 14y ago
    Not really sure what point you're making. Validating on the server will incur a 2-10sec penalty once when entering payment data... the rest of your app is unaffected.
- reaclmbs 14y ago
  You have to pay for failed authorization attempts
  - ux-app 14y ago
    Do you mean pay money for each auth attempt?? I've never heard of such a charge. Maybe time for a new gateway/bank?
    - saikat 14y ago
      You actually don't pay for failed auth attempts with Stripe, but you do with most other gateways.
jimktrains2 14y ago
I wrote a blog post about credit card numbers and how they're processed for a quick intro to the topic: http://jimkeener.com/posts/everyday-numbers-1 http://jimkeener.com/posts/everyday-numbers-1

by mey 14y ago

pc 14y ago

(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.

maccman 14y ago
We'll get UnionPay & Maestro support added shortly.
badgar 14y ago
> 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.
- Skywing 14y ago
  > 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. What is there to be embarrassed about? Seriously.
- wilsaj 14y ago
  It's not a redefinition of "assumption" but rather a justification as to why these assumptions should not be qualified as "incorrect".
- cwp 14y ago
  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.
mey 14y ago
I took the goal of the library as general purpose, not stripe purpose. Sorry for my personal incorrect assumption.
- pc 14y ago
  No problem. The goal is to be general purpose, though, and to that end we just added support for UnionPay, Maestro, and Laser: https://github.com/stripe/jquery.payment/pull/5 https://github.com/stripe/jquery.payment/pull/5.
  - mey 14y ago
    Awesome :)

deleted 14y ago

[deleted]

danielweber 14y ago

I do give them credit for accepting credit card numbers with spaces in them. It seems 99% of websites cannot handle spaces.

jonknee 14y ago
I have had this discussion a few times and at least for me it's usually sticking to ridiculous TOS from the payment gateway and less in programming competency. If your gateway says you're not allowed to change anything in the input and the gateway does not accept spaces you can either break your contract or not allow spaces.
- pbreit 14y ago
  > not allowed to change anything in the input I've never seen such a term. Have any examples?

asimeqi 14y ago

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.

ceejayoz 14y ago
Gift cards aren't credit cards. The docs say "a general purpose library for building credit card forms", not "a general purpose library for building payment forms".
jfoster 14y ago
How does it become easier to do such validation server-side?
- cj 14y ago
  You can attempt to process it through your payment gateway (ie. stripe) and check for a success or failure.
  - jimktrains2 14y ago
    That becomes expensive. The more you can do on your own, the less in fee's you'll accumulate.

ux-app 14y ago

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.

alttab 14y ago
You, but whatabout a laymen user who doesnt care ehat your justifications are? They want people to build snappy mobile web apps. This creates competition and legitimacy for them
- ux-app 14y ago
  Not really sure what point you're making. Validating on the server will incur a 2-10sec penalty once when entering payment data... the rest of your app is unaffected.
reaclmbs 14y ago
You have to pay for failed authorization attempts
- ux-app 14y ago
  Do you mean pay money for each auth attempt?? I've never heard of such a charge. Maybe time for a new gateway/bank?
  - saikat 14y ago
    You actually don't pay for failed auth attempts with Stripe, but you do with most other gateways.

jimktrains2 14y ago

I wrote a blog post about credit card numbers and how they're processed for a quick intro to the topic: http://jimkeener.com/posts/everyday-numbers-1 http://jimkeener.com/posts/everyday-numbers-1