But it looks gorgeous for sure and it's probably part of the future.
All you need is to load some encoded image off of a third server to leak card info via a side channel, if your code is underhanded.
I would trust "one line of code" if it's a solution from Google or something, but for something this small I don't see how going with a small third-party solution is secure.
- OP: why not sell this solution to a larger payment processor as a complete solution, so they don't have to develop it themselves?
You'd say you'd trust it if it was from Google - in this case, if you use it, it's coming from you, on your server, under your control. I'd trust this far more than a Google-hosted closed-source library - not because I wouldn't trust a Google payment endpoint, but because this is totally under my control, and something from Google isn't.
Not sure what you're talking about with the encoded image. Doesn't make much sense.
There are no real security problems with this whatsoever. The problem is, unsavvy users may think there is, due to the visual resemblance of the onscreen card.
Make your credit card form better in one line of code
With one line of code..
$('form').card({ container: $('.card-wrapper') });
You get..
Animations for 4 different card types
An intuitive experience for your users
Pure CSS, HTML, and Javascript (no images)
100% free and open source
All I am saying is that for us as developers it is not so simple either. . . we also have to be vigilant.
That doesn't mean the customer won't conclude it is legit, or that we don't conclude the same thing.
Recall that I had responded to,
>Looks gorgeous. I can't help but wonder if people unfamiliar with technology and ecommerce would be deterred by such a form?
Certainly I personally would be deterred (to an extent) from using this form without at least a cursory audit and verifying the identity of the person who wrote it.
This will naturally be less and less important the more eyeballs this sees. But as a simple tool, perhaps it is not that many.
Do remember that if I were wanting to get my hands on people's credit cards, getting developers to use this kind of script while having a well-hidden side channel (perhaps quite well-hidden - it could somehow encode cc details in the timing delays to a different server, potentially, so that it is not at all obvious that the delays even correspond with the data, it could just look like visualizations getting loaded as the person types) -- then this would be one of the more clever ways I could go about doing so.
I don't see how we're 'arguing' about this? We need to check what we are using, just like customers need to check that this is legit.
The idea that anyone would successfully steal CC info by putting up an open-source client-side jQuery plugin under his real name is just silly. It's not something that you ever have to worry about in the real world. Sure, I'll concede that if a number of absurdly unlikely things happened, something like this could steal CC info.
Besides, you're missing the point. We're paid to vet this stuff. Customers aren't. Your choice of whether to use this or not harms no one - but customers being scared of an odd-looking CC form is harmful to business, and a valid and interesting point.
This is great work.