I think the tabindexes should be different. When I hit tab in the security code field, it currently focuses on the question mark. It would be better if it focused on the name field at that point IMO. Otherwise, very nice!
Creditcard.js: a more usable credit card form
81–90 of 112 posts
Re: Creditcard.js: a more usable credit card form
#82Small complaint: I use Typinator[1] (a text expander for Mac) to type in my credit card numbers. I'll enter a simple string I wouldn't normally type, like "mvcd" (or "my visa card") and it expands to the full number.
But if you restrict the form to just numbers, I can't type in my text to expand to the full number. I always get super annoyed at credit card forms that do this.
/two cents
Re: Creditcard.js: a more usable credit card form
#83Earlier quoted context omitted.
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.
How does it create more work? What do you mean switching between keyboard and mouse repeatedly? Aren't they already doing that when they are entering in the credit card number, the security code AND their name? LOL.
Re: Creditcard.js: a more usable credit card form
#84Earlier quoted context omitted.
"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?
I'd also argue that a library developed and used by Stripe is pretty commercial grade too.
Re: Creditcard.js: a more usable credit card form
#85Looks good, and I like the mistakes and solutions section. 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.)
And you have a similar UI widget at https://stripe.com/docs/checkout
Lol, that looks exactly the same to me!
Re: Creditcard.js: a more usable credit card form
#86In 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.
Re: Creditcard.js: a more usable credit card form
#87Typing 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.
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_.
Re: Creditcard.js: a more usable credit card form
#88I liked that other one better.
Re: Creditcard.js: a more usable credit card form
#89what... it's not.. opensource? peeks into javascript source code
Re: Creditcard.js: a more usable credit card form
#90Interesting 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 wit…
I think it is probably the right move. 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…
If I was having a successful business that is doing $100k+/year I would think twice about integrating a new form with minified javascript from a cold email into my payment flow.
It's definitely not a bad idea to do outbound marketing for this. I just think conversions would be a lot higher if the readable source is also present in the offer.