Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Creditcard.js: a more usable credit card form

creditcardjs.com

Post reply on HN
Print view View original

71–80 of 112 posts

Re: Creditcard.js: a more usable credit card form

#71

Post by EGreg »

pclark wrote: post #59
niel wrote: post #33

Earlier quoted context omitted.

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 review…

"prohibitively expensive" ? Surely if you're a business of any merit – making even $500/month – $300 for a javascript library that'll remove bumps in the checkout process is worth it? I fail to see why this cannot co-exist alongside the Stripe alternative library. Heck, just taking the stripe library and offering commercial grade support, and charging $300 seems like a pretty good business.

Can you explain how commercial-grade support for a library that hasn't been tested by many people is better than a community of people who have run and tested a library? What exactly are they going to do for the support?

Re: Creditcard.js: a more usable credit card form

#72

Post by patio11 »

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.

Re: Creditcard.js: a more usable credit card form

#73

Post by anonymoushn »

A mix of bugs and suggestions:

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

Re: Creditcard.js: a more usable credit card form

#74

Post by lucisferre »

patio11 wrote: post #72

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 ope…

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.

Re: Creditcard.js: a more usable credit card form

#75

Post by patio11 »

lucisferre wrote: post #74
patio11 wrote: post #72

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 ope…

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'…

OSS and credit cards have existed for every single day of the last ten years. Did the community just not notice that taking credit cards on websites is done by substantially every business transacting on the Internet? Or were they just hiding their well-tested well-designed decent-UX commercially-supported OSS options on localhost until someone tried to commercialize the niche, to now be unleashed on Github with great fanfare?

People have higher-expectations-than-are-warranted for "Some OSS developer (who is not me)" deciding to bite off a project on their behalf. The threat of this is routinely invoked to scare developers into not releasing software commercially. It's almost invariably overblown. Crikey, people told me 8 years ago that BCC was commercially non-viable because there existed OSS (with XML output for linking to an upcoming multimedia engine [+]) that was going to eat its lunch "as soon as it was marketed."

+ Seriously not making that up. http://sourceforge.net/projects/bingo-cards/

Re: Creditcard.js: a more usable credit card form

#76

Post by Gigablah »

righon wrote: post #68
kalleboo wrote: post #54

Earlier quoted context omitted.

What browser/OS doesn't let you type to select in dropdowns?

Doesn't matter, that's a "power user" shortcut. You'd be surprised how many people do not think or know that can be done. Why not make it easier and just make the expiration date text fields? It's much easier to type in the month '12' than having to scroll scroll through 11 options to get to 12.

You'd be surprised how many people don't know how to tab through multiple fields. If the expiration date is broken into multiple text fields that creates more work as "regular" users need to switch between keyboard and mouse repeatedly.

Re: Creditcard.js: a more usable credit card form

#78

Post by zrail »

The mistakes and solutions section is great info, thanks. That said, there's a bunch of problems with the actual implementation. I put together a payment form that converts very well for selling my book Mastering Modern Payments[1] and it's included with the middle package ($59 instead of $149). It uses jquery.payment from Stripe which several people mentioned earlier in the thread.

[1]: https://www.petekeen.net/mastering-modern-payments

Re: Creditcard.js: a more usable credit card form

#79

Post by alixaxel »

lucisferre wrote: post #74
patio11 wrote: post #72

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 ope…

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'…

Skeuocard (http://kenkeiter.com/skeuocard/) was on the top page of HN a couple of months ago.

Re: Creditcard.js: a more usable credit card form

#80

Post by cenhyperion »

pclark wrote: post #59
niel wrote: post #33

Earlier quoted context omitted.

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 review…

"prohibitively expensive" ? Surely if you're a business of any merit – making even $500/month – $300 for a javascript library that'll remove bumps in the checkout process is worth it? I fail to see why this cannot co-exist alongside the Stripe alternative library. Heck, just taking the stripe library and offering commercial grade support, and charging $300 seems like a pretty good business.

>I fail to see why this cannot co-exist alongside the Stripe alternative library.

It certainly can, anyone is more than welcome to pay for something done by open source software available for free.

>Surely if you're a business of any merit

Just because you're a business doesn't mean you should pay for things that you can do cheaper.

The point is that a decent web developer could recreate that form in 20 minutes with jquery.payment and a little bit of CSS, so why should you pay $300 for the same thing?

Post reply on HN