Looks interesting. Is there an option to also display certain billing address fields? I use minFraud and it requires a country, state, city, and postal code for distance checks.
Personally, I also hate dropdowns for expiration. Isn't it far easier to just type in what's on the card and validate that as a valid date?
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.
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.
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.
$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.
That's my point, there's not many advantages over an open source/free alternative (subjective). And it's contextual, there's no way I'm going to argue for my [insert superior here] at [insert agency, studio,etc here] to buy this when their tech savvy enough to seek other alternatives.
It looks nice, but who would pay $300 for a single Javascript widget? Big companies might, sure, but there are plenty of good free implementations out there that have effectively the same features.
You minified half of the Closure Library for a modest product. 50kb of inline JS for card processing, just to obfuscate. This is terrible, you need two libraries doing the same thing.
Very high price point, developers who can afford to buy it can likely code it themselves.
I'd say that the ? for explaining the CCV should be a hover effect rather than a click. In every other CC form I've ever dealt with it's been a hover effect.
I have bad experience with the hover effect. Like showing up when I don't want it to show, and also it doesn't work quite well on tablets, phones and touch devices. I think the button is better approach.
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.
Agreed. I wouldn't be opposed to paying $150 for a form that would take me a while to build, but there's already a lot of good open-source solutions for card inputs.
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 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?
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'....
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.
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.
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.
Oh, they're already switching keyboard and mouse? Let's make them do it even more! /sarcasm
Seriously though, what makes you think people have to "scroll" through 11 months to get to December? 12 options can be comfortably displayed all at once on screen. Have you ever seen a dropdown?
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_.
"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 :)
I thought that was only for American Express? It allowed me to enter 4 numbers with an American Express card number. There wasn't 4 little placeholder dots, which was confusing.
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.
111 comments
[ 3.1 ms ] story [ 273 ms ] threadPersonally, I also hate dropdowns for expiration. Isn't it far easier to just type in what's on the card and validate that as a valid date?
If it requires JS, then it isn't compatible with any payment form.
[1] http://kenkeiter.com/skeuocard/
Edit: here's the original post - https://news.ycombinator.com/item?id=6143604
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."
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.
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.
Good luck selling this.
EDIT: Also, if anyone needs help with jCCV, get in touch at @PawelDecowski.
- 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.
Some helpful pointers and a nice example. Open source it and that's that. But $149?
But surprisingly handles JCB and Diners Club.
Very high price point, developers who can afford to buy it can likely code it themselves.
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.)
https://stripe.com/docs/checkout
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!
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.
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?
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'....
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.
http://en.wikipedia.org/wiki/List_of_Issuer_Identification_N...
edit: which doesn't change your point that initial format could move around after you type the first digits. I'll leave this here for trivia.
Seriously though, what makes you think people have to "scroll" through 11 months to get to December? 12 options can be comfortably displayed all at once on screen. Have you ever seen a dropdown?
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
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.