"JavaScript libraries like jQuery aren't well equiped to handle form input, so Creditcard.js uses the more robust and comprehensive Google Closure Tools, the heavily tested JavaScript framework behind Gmail and Google Plus."
really? you're gonna do jQuery (+ all validation plugins) bashing for what? 5 fields + a luhn algo? please, take your snake oil elsewhere.
"the heavily tested JavaScript framework"? you must not follow jQuery's own pedantic development and testing, i would argue it is more heavily tested than Google's we-only-support-latest-2-versions-of-any-browser libs.
if anyone needs to do client-side cc pre-checks, there's a pretty up-to-date regex list [1] and a luhn implementation [2] which will get you 99.9% there. if you feel that the 0.1% (but probably much less) is worth a monthly licensing fee, you now have options :)
The presentation of Creditcard.js is great in terms of styling, and I'm sure the practical example goes a long way in selling something like this to non-developer decision makers. This is probably the market they are aiming for.
Personally, I would much rather use the MIT-licensed jQuery.payment by Stripe. I think $300 or even $149 is prohibitively expensive, and would prefer a script that is actively used and reviewed in public by many developers.
From the initial docs of jQuery.payment, it looks like a lower-level tool -- the OP provides the promise of "you just drop it in, and you get these things, designed for you." jQuery.payment looks like "Here's a toolset you can use to do whatever you want!"
But I don't want to spend time figuring out what I want and putting it together. I also don't want to spend $150/year on it though. :)
If you built a higher-level abstraction on top of jQuery.payment, that made the good design choices for the developer, so the developer could just 'insert form here'....
- It is possible for the security code and card number fields to be green, indicating they have been filled out correctly, using a 3-digit security code for an American Express card number or a 4-digit security code for any other card number.
- The security code help probably should not display the American Express case when no card type has been identified.
- The security code field should display 4 dots when American Express is detected.
- The card type detection is so faint as to be invisible to inattentive users or people with awful displays.
- Drop-down for expiration is a disaster and a huge regression from the status quo.
I played with the checkout form some and discovered these additional issues:
- Email validation is wrong, valid emails are flagged as incorrect.
- At almost all reasonable browser widths, the right 2/5 or so of the security code tip is cut off, rendering it useless.
- After clicking "Purchase License" without completely filling out the form, the button permanently changes to "Please Correct Errors Above." Correcting the errors will not allow you to actually purchase a license. You will need to refresh and enter all your data again.
- You can actually successfully submit the form using a Visa with a 4-digit security code or an American Express with a 3-digit security code. It was declined :(
- "The 'exp_month' parameter should be an integer (instead, is MM)." is not a very usable way of phrasing this error.
I would not buy $149 closed-source beta software for making my purchase form more usable from people with such an unusable purchase form.
Great list. Can you elaborate on "Drop-down for expiration is a disaster and a huge regression from the status quo."? Are you saying the norm is to have it typed?
I really liked Skeuocard. Skeumorphic design is on the out, but when it resembles what you're looking at while you input it - it might still be beneficial.
Typing 4321432143214321 results in 4321 3214 2143 1234 in Chrome. Works right if I type spaces, but I shouldn't need to do that. Also, let me type the expiration date in if I want to - I hate it when I can't complete a form by tabbing through fields.
I don't know how your browser works, but for the date fields, I could tab to them, press space, type the digits, press enter, tab to the next one, rinse, repeat.
Yeah, I was going to say -- I can't even type a credit card number in correctly without the form mangling it (Safari 6 on OS X 10.8.4). All the fanciness in the world isn't worth anything if you can't _type in a credit card number_.
I was actually pretty keen on purchasing this. Today I'm building a payment page. I don't mind paying for something good that will save me time.
But it doesn't look like you provide an uncompressed version for review. I can't use a third party library that deals with credit cards without first reviewing the code.
Thought the same as the above, but also have an issue with the design decision to use dots as placeholder text. Conventionally, dots indicate that text had already been entered into a (password) field. Even though they are slightly greyed, I think it's confusing.
I don't have immediate need for it, but I'd take the other side of the bet from all comments saying "That is too expensive. OSS will eat your lunch. I bet I could do it in a weekend."
It's a brilliant idea for a project and we all should be absolutely kicking ourselves for not having done it years ago. Do you know how many tens of thousands of dollars of dev time I've seen thrown at this, across a dozen companies operating in waste-causing parallel, to produce something less usable and less likely to increase sales across the company? Do you know how many hours of my life I've wasted on it myself? The mind boggles.
We built some custom inputs just for handling number formatting (currency, percentages and separators) using AngularJS (directives) and I can say from experience it is much harder than anyone would imagine. The basic concepts are simple, it's always the implementation details, edge cases, browser quirks that will eat up your time.
Bottom line, saving money vs. time isn't a good reason not to buy this.
I still wouldn't be surprised if someone goes and builds an FOSS version of this anyways. FOSS people have far more than just "a weekend" for things like this, and it actually looks like a fun thing to build. Also a buggy prototype could probably be whipped up in a weekend if you leverage a good JS framework like Angular or Ember. Perhaps not but I'm sure someone will try.
$149 is a extremely high price-point for this with so many alternatives out there. I also don't see the value vs. the price. I've implemented http://jquerycreditcardvalidator.com/ with authorize.net with zero issues.
It's $299 (that's the beta-price). But I don't think it's expensive. I think it's quite correct. If a developer value his time, he should probably buy it. That is if he finds that it has advantages over the free alternatives.
In addition to all the other criticism here, the EULA for this product is terrible. There are so many silly claims (not to mention typos that completely undermine much of it anyway) that I would walk away no matter how good the code on offer was.
Also, if your primary selling point is that you are "a more usable credit card form", you look weak without a clear statement of what you're more usable than and producing empirical data to show where you convert better. You're talking about a critical part of my payments system, so I'm hardly going to take your word for it just because you've got some red and green on your web site. This goes double for any sort of web form tool, because these are notorious for actually making things worse if they don't properly support all platforms, all the edge cases in the inputs, all accessibility aids, and so on.
Sorry to be so negative, because I'm sure a lot of hard work went into this, but taking card payments is not a game, and clearly this product is nothing like ready for production use. I worry for whoever is charging for this, because if someone did buy it and then wind up losing real money as a result of problems like the ones mentioned throughout this HN discussion, liability could be a real concern.
Interesting price point; it seems to be in a no-mans land where developers who can pay $300 would probably be in a position that they'd want to implement it themselves, yet it might be prohibitively expensive for smaller clients who'd better spend their efforts elsewhere and could use Skeuocard or Stripe.js for free.
Surprised to see the 'one website' clause, as well -- as someone who spends a lot of time working with Stripe integrations, I'd love to buy this once and then plunk it down everywhere. Still, this is a cool effort and I hope to see it succeed!
He has a way better chance of selling 100 licenses for $300 each versus 3000 licenses for $10 each.
The smart move would be to actually do some amount of outbound sales to sell licenses. There a ton of random vendors out there doing $100k+/year that have broken credit card flows. Find their checkout page, save it do disk. Spend 10 minutes integrating this verification into their own form, and cold-email the webmaster with the zip'd up demo and already done integration. Let's say it takes 6 hours to 40 of those. If 10% to convert, you're making serious money.
My observation is that I wish the dots that are place holders in the box, turned into numbers as I typed them. When I went to type in a cc, the text box went blank, leaving me aesthetically with the same cc form as any one of them on the web.
Great component and I would not mind paying for it.
However, if you are going to claim that it has 'Accurate Card Type Detection', you need to make sure that you cover common cases.
E.g. I live in NY and my Amex starts with 3723 and the input form doesn't recognize it.
As a developer, I understand that there are bugs in software. But if you are selling me a component which can not handle my own card, I would really wonder how comprehensive your card type detection is. They link to this page http://en.wikipedia.org/wiki/List_of_Issuer_Identification_N... which lists 37 as a valid Amex number. I think they need to go through their code and make sure all those numbers are handled correctly.
Very cool looking, would love to use it, but there's two main problems:
1. No free trial, dropping $300 on a javascript plugin that I don't even know works yet is a lot of money.
2. I don't know if the value it offers is THAT much different from other credit card validation tools. If I'm making $50/hr freelancing, that's 6 hours of my time and I could easily customise some other alternative to fit my needs in that time.
I can't stand credit card forms that split the credit card number into 4 inputs ("[XXXX] [XXXX] [XXXX] [XXXX]") because I can't paste my number in (the first box has a maxlength of 4 usually)
Yet, for people who are typing in the number (vs pasting it), the 4 sections makes it easier.
Doesn't work under Chrome/Linux (older version 26.0.1410.63). The first group of digits in the card number field show up correctly, but then something goes wrong when the script tries to insert a space for formatting.
The first digit in the second block shows up correctly, but then the cursor is positioned before the first digit/second block, so that the remainder of the block gets inserted in front of the first digit, completely messing up the card number.
[+] [-] leeoniya|12 years ago|reply
really? you're gonna do jQuery (+ all validation plugins) bashing for what? 5 fields + a luhn algo? please, take your snake oil elsewhere.
"the heavily tested JavaScript framework"? you must not follow jQuery's own pedantic development and testing, i would argue it is more heavily tested than Google's we-only-support-latest-2-versions-of-any-browser libs.
if anyone needs to do client-side cc pre-checks, there's a pretty up-to-date regex list [1] and a luhn implementation [2] which will get you 99.9% there. if you feel that the 0.1% (but probably much less) is worth a monthly licensing fee, you now have options :)
[1] https://github.com/Shopify/active_merchant/blob/master/lib/a...
[2] https://gist.github.com/ShirtlessKirk/2134376
[+] [-] maccman|12 years ago|reply
However, it's pretty much all covered by Stripe's open source jQuery.payment, which is also agnostic to your payment gateway.
https://github.com/stripe/jquery.payment
(Disclaimer - I built it.)
[+] [-] niel|12 years ago|reply
Personally, I would much rather use the MIT-licensed jQuery.payment by Stripe. I think $300 or even $149 is prohibitively expensive, and would prefer a script that is actively used and reviewed in public by many developers.
Thanks Alex!
[+] [-] sgustard|12 years ago|reply
https://stripe.com/docs/checkout
[+] [-] jrochkind1|12 years ago|reply
But I don't want to spend time figuring out what I want and putting it together. I also don't want to spend $150/year on it though. :)
If you built a higher-level abstraction on top of jQuery.payment, that made the good design choices for the developer, so the developer could just 'insert form here'....
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] Killswitch|12 years ago|reply
[+] [-] anonymoushn|12 years ago|reply
- It is possible for the security code and card number fields to be green, indicating they have been filled out correctly, using a 3-digit security code for an American Express card number or a 4-digit security code for any other card number.
- The security code help probably should not display the American Express case when no card type has been identified.
- The security code field should display 4 dots when American Express is detected.
- The card type detection is so faint as to be invisible to inattentive users or people with awful displays.
- Drop-down for expiration is a disaster and a huge regression from the status quo.
I played with the checkout form some and discovered these additional issues:
- Email validation is wrong, valid emails are flagged as incorrect.
- At almost all reasonable browser widths, the right 2/5 or so of the security code tip is cut off, rendering it useless.
- After clicking "Purchase License" without completely filling out the form, the button permanently changes to "Please Correct Errors Above." Correcting the errors will not allow you to actually purchase a license. You will need to refresh and enter all your data again.
- You can actually successfully submit the form using a Visa with a 4-digit security code or an American Express with a 3-digit security code. It was declined :(
- "The 'exp_month' parameter should be an integer (instead, is MM)." is not a very usable way of phrasing this error.
I would not buy $149 closed-source beta software for making my purchase form more usable from people with such an unusable purchase form.
[+] [-] xixixao|12 years ago|reply
Click on security code question mark, then change type of the card - two "cards" appear for a second on the right than the old one disappears.
[+] [-] yalooze|12 years ago|reply
[+] [-] storborg|12 years ago|reply
- only minified source provided
- not out of the box compatible with a module loader
- no public bug tracker
- doesn't handle all edge cases (for example, type some numbers, place the cursor after the space, and hit backspace).
Good luck.
On the other hand, this is a nice list of edge cases for someone to check when they implement the open source weekend project version of this.
[+] [-] srhngpr|12 years ago|reply
[1] http://kenkeiter.com/skeuocard/
Edit: here's the original post - https://news.ycombinator.com/item?id=6143604
[+] [-] jasonlotito|12 years ago|reply
https://news.ycombinator.com/item?id=6143829
I still stand by what I said:
"That fancy CC form will not sell a single thing. It will however stop people from paying."
[+] [-] Navarr|12 years ago|reply
[+] [-] vonseel|12 years ago|reply
[+] [-] ryan-c|12 years ago|reply
[+] [-] kalleboo|12 years ago|reply
[+] [-] geofft|12 years ago|reply
[+] [-] cstrat|12 years ago|reply
[+] [-] mratzloff|12 years ago|reply
[+] [-] coenhyde|12 years ago|reply
But it doesn't look like you provide an uncompressed version for review. I can't use a third party library that deals with credit cards without first reviewing the code.
[+] [-] glennos|12 years ago|reply
[+] [-] patio11|12 years ago|reply
It's a brilliant idea for a project and we all should be absolutely kicking ourselves for not having done it years ago. Do you know how many tens of thousands of dollars of dev time I've seen thrown at this, across a dozen companies operating in waste-causing parallel, to produce something less usable and less likely to increase sales across the company? Do you know how many hours of my life I've wasted on it myself? The mind boggles.
[+] [-] lucisferre|12 years ago|reply
Bottom line, saving money vs. time isn't a good reason not to buy this.
I still wouldn't be surprised if someone goes and builds an FOSS version of this anyways. FOSS people have far more than just "a weekend" for things like this, and it actually looks like a fun thing to build. Also a buggy prototype could probably be whipped up in a weekend if you leverage a good JS framework like Angular or Ember. Perhaps not but I'm sure someone will try.
[+] [-] thoughtpalette|12 years ago|reply
Good luck selling this.
[+] [-] csomar|12 years ago|reply
[+] [-] PawelDecowski|12 years ago|reply
EDIT: Also, if anyone needs help with jCCV, get in touch at @PawelDecowski.
[+] [-] pbreit|12 years ago|reply
[+] [-] Silhouette|12 years ago|reply
Also, if your primary selling point is that you are "a more usable credit card form", you look weak without a clear statement of what you're more usable than and producing empirical data to show where you convert better. You're talking about a critical part of my payments system, so I'm hardly going to take your word for it just because you've got some red and green on your web site. This goes double for any sort of web form tool, because these are notorious for actually making things worse if they don't properly support all platforms, all the edge cases in the inputs, all accessibility aids, and so on.
Sorry to be so negative, because I'm sure a lot of hard work went into this, but taking card payments is not a game, and clearly this product is nothing like ready for production use. I worry for whoever is charging for this, because if someone did buy it and then wind up losing real money as a result of problems like the ones mentioned throughout this HN discussion, liability could be a real concern.
[+] [-] jmduke|12 years ago|reply
Surprised to see the 'one website' clause, as well -- as someone who spends a lot of time working with Stripe integrations, I'd love to buy this once and then plunk it down everywhere. Still, this is a cool effort and I hope to see it succeed!
[+] [-] hemancuso|12 years ago|reply
He has a way better chance of selling 100 licenses for $300 each versus 3000 licenses for $10 each.
The smart move would be to actually do some amount of outbound sales to sell licenses. There a ton of random vendors out there doing $100k+/year that have broken credit card flows. Find their checkout page, save it do disk. Spend 10 minutes integrating this verification into their own form, and cold-email the webmaster with the zip'd up demo and already done integration. Let's say it takes 6 hours to 40 of those. If 10% to convert, you're making serious money.
[+] [-] rickdale|12 years ago|reply
[+] [-] skeoh|12 years ago|reply
[+] [-] some1else|12 years ago|reply
[+] [-] solutionyogi|12 years ago|reply
However, if you are going to claim that it has 'Accurate Card Type Detection', you need to make sure that you cover common cases.
E.g. I live in NY and my Amex starts with 3723 and the input form doesn't recognize it.
As a developer, I understand that there are bugs in software. But if you are selling me a component which can not handle my own card, I would really wonder how comprehensive your card type detection is. They link to this page http://en.wikipedia.org/wiki/List_of_Issuer_Identification_N... which lists 37 as a valid Amex number. I think they need to go through their code and make sure all those numbers are handled correctly.
[+] [-] rheotron|12 years ago|reply
1. No free trial, dropping $300 on a javascript plugin that I don't even know works yet is a lot of money.
2. I don't know if the value it offers is THAT much different from other credit card validation tools. If I'm making $50/hr freelancing, that's 6 hours of my time and I could easily customise some other alternative to fit my needs in that time.
[+] [-] mrchess|12 years ago|reply
[+] [-] kalleboo|12 years ago|reply
[+] [-] pud|12 years ago|reply
I can't stand credit card forms that split the credit card number into 4 inputs ("[XXXX] [XXXX] [XXXX] [XXXX]") because I can't paste my number in (the first box has a maxlength of 4 usually)
Yet, for people who are typing in the number (vs pasting it), the 4 sections makes it easier.
This form is the best of both worlds.
[+] [-] ohazi|12 years ago|reply
The first digit in the second block shows up correctly, but then the cursor is positioned before the first digit/second block, so that the remainder of the block gets inserted in front of the first digit, completely messing up the card number.
[+] [-] colinbartlett|12 years ago|reply
Some helpful pointers and a nice example. Open source it and that's that. But $149?
[+] [-] joeblau|12 years ago|reply
[+] [-] elmin|12 years ago|reply