Show HN: Card – An interactive CSS3 credit card form | Hacker News Reader

Show HN: Card – An interactive CSS3 credit card form

jessepollak.github.io

376 pointsjessepollak112 comments

Looks great. Few notes:

1) On the already crowded payment form, I don't want to devote a hell of a lot of space to something that is otherwise inconsequential (a picture of a credit card)

2) Is it a great idea to broadcast someone's card numbers so clearly? The graphic is so obviously a credit card, it would be easy for any onlooker to spot and steal.

Really, this seems like aesthetics for aesthetics' sake, which I traditionally shy from, but I always like seeing people take a swing at something.

> 2) Is it a great idea to broadcast someone's card numbers so clearly? The graphic is so obviously a credit card, it would be easy for any onlooker to spot and steal.

yes - anything that signposts card data clearly to an onlooker is problematic, but any malicious shoulder surfer will probably be able to spot a payment page a mile off in any case. This might however, have a small possibility of encouraging opportunistic theft.

I think the bigger threat to this probably comes from the networks (MC, VISA, AMEX etc) who get VERY possessive about mock-ups / card image facsimiles that use their logos. The brand logo protection that they enforce is pretty strict and I would imagine this approach would not be welcomed. I'd like to be wrong, but my experience with the networks makes me pessimistic.

I'm less concerned with the reuse of their logos and more concerned with the fact that their logos are implemented in HTML/CSS rather than as images, which means there will be subtle differences.

Basically those aren't their logos. They're slightly inaccurate imitations. Most big brands will be upset if even a few pixels are off when their logo is displayed.

You're right, point 2 is THE show-stopper for this. It looks amazing, but if amazon or the likes ever tried this I'd close my account - credit card security, in this day, is not the place for gimmicks. Sorry.

Looks gorgeous. I can't help but wonder if people unfamiliar with technology and ecommerce would be deterred by such a form? It might give some users the impression that the website is "copying" the credit card. It would be interested to test the opinions of non-tech savvy users.

I don't know about people unfamiliar with technology, but as someone very familiar with technology, my first thought is that this could easily be a vector for copying the card information!

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?

Well, of course untrusted code dealing with CC info is insecure. That's why this is open source, and you host it yourself. It's just a library. Whose source you can see. Whose source you can compile. With a third-party compiler.

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.

Because it's open source, we can figure out exactly what's going on. OP brings up the point from the users' perspective and they might not trust an interface that looks this flashy.

That's a far cry from

  Make your credit card form better in one line of code

and

  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

Which certainly could be used by someone who doesn't understand all this.

All I am saying is that for us as developers it is not so simple either. . . we also have to be vigilant.

If somebody who doesn't know what they're doing is writing a CC form, you've already lost. Making app development easier isn't "dangerous" because it allows less experienced people develop applications. You will always have people making mistakes and screwing up security, regardless of the actual ease of development. The more the developer has to do, the more they can screw up.

This is what my point is: as much as the customer has to slow down and say, "Wait a second, is this legit?" - so do we.

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.

I don't really understand your point. The thing about timing channels is absurd - we have the code right in front of us. Right there. It either calls third-party servers or it doesn't, and we can see that. Very easily.

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.

we're not disagreeing

Because you couldn't just generate a similar image on the server-side if you're already asking for that information?

OP is trying to get a job at stripe, stop making it so obvious he was blending in

Same thoughts!

Same here, I mean if I saw this on my paypal account I would kind of worried, looks too "flashy".

But it looks gorgeous for sure and it's probably part of the future.

This is amazing, I love how it handles the CVC even on AmEx. The only way this could be better is to type directly on the card or move the fields above (mobile) or to the side of the card to make them more prominent.

This is great work.

You mean like this: http://kenkeiter.com/skeuocard/

This is neat, and I love the look and feel. The only problem is that it's completely unnecessary and possibly confusing for potential customers. But that's just my opinion. It would be interesting if someone would put this on their own payment page and share the conversion metrics.

There's a few annoyances that threw me off:

1) Like others mentioned in this thread, I first tried to enter credit card details directly on the card. I was initially blind to the text inputs underneath the card. If the card was initially hidden, then faded in to the left/right of the input form that might alleviate this confusion. The problem is the card is so beautiful and neat looking I immediately anchor to the card instead of the input form.

2) When entering an invalid date or credit card number there's no visual feedback. It's very common to be blind to your own input errors, which necessitates clear communication of error state.

3) Even more confusing, I can't tab to the CVC field when the date is invalid. But I can tab to the name field when the credit card number is invalid. This inconsistent behavior initially made me think the form was "broken".

It's confusing because my first instinct was to type my credit card info on the card itself. It took me a few seconds to realize there was a form below it.

Same here, but aside from that, I think this is very neat. Maybe if instead of the card being grayed out before you enter input, it could be entirely invisible. But then the empty space above the form would seem strange at first.

or just the empty recognizable outline of a card (the rectangle with the rounded corners) with no fields. then on first keystroke populate the fields, etc.

I also tried clicking on the card itself. Why not allow that? Otherwise maybe have a hover div to the right of the input fields that only is displayed while any of the credit card fields are active.

Let me be the first to rain on your parade (sorry).

If you're not the merchant of record using this form could very well violate your terms of service for whatever credit card company you have your merchant account with, and/or the IPSP terms of service.

Using this can result in terminating your merchant account or temporary suspension depending on how they take it.

The reason why is that the logo's are only allowed to be used by the merchant of record, for many of the parties interested in that this will be their IPSP. So verify prior to doing this that you actually are allowed to use the card association logos. (And for that matter, that you're authorized to capture the card details!).

Please be careful, if you lose your merchant account it could be a while before you get it back, if ever.

Overreact much?

Most people that will be taking credit cards directly via a form like this will have merchant account and be authorized to use the credit card logos. If they are using a service like PayPal they are mostly redirecting to their service providers site for processing not taking the card info directly.

The usage of the network logos are not as strict as you are implying here, even if you use paypal you can use the Network logos. https://www.paypal.com/us/webapps/mpp/logo-center

There are many approved banners and logos that make use of the card network logos.

I have never had a payment processing agreement where I was barred from using the Network Logos, nor would I sign up for such a service, in the off chance I am wrong please back up your claims with citations to actual laws or statements to support your claim

> Most people that will be taking credit cards directly via a form like this will have merchant account and be authorized to use the credit card logos.

Using logos in combination with a credit card capture form comes with a different set of rules (and a different contract!) than just being allowed to use some third party processor that does all the work for you.

If you want to capture the cards yourself instead of outsourcing the job to an IPSP then you're going to have to be at a minimum PCI compliant. This goes for any company that stores, processes or transmits credit card information. The tipping point is somewhere around a million $ US per year. Below that the cost of being in compliance outweighs the fees the IPSP charges for their service handily.

The word 'credit' in credit cards stands for 'trust'.

https://www.google.com/search?client=ubuntu&channel=fs&q=ori...

People trust those companies and by extension trust those logos. That's why when you use them you will be held to the rules so strictly because credit card companies do not like it when their logos are used to give an aura of trust to an otherwise non-trustworthy situation. Just the PDF about what you can and can not do visually with the logo runs to lots of pages.

Yes, there are plenty of ways in which using those logos is absolutely ok, and where using this form is (probably) just fine.

Everybody that is PCI DSS compliant can likely use it without any problem. Yes, there are also plenty of ways in which using this form is strictly against the terms of service, typically this includes everybody who is not PCI certified, which is almost every two bit merchant on the web that outsources their payment processing and credit card capture to some third party.

So, if you use a 3rd party solution that serves up the payment form and that handles the card capture and subsequent processing for you and you have a contract with them rather than with the card company you can use the logos and nobody will care, mostly because you can't do much harm (such as your paypal example).

But if you are in a situation where you have a merchant account but you are not the merchant of record (this means you are a sub-merchant, such as when using any one of a number of IPSPs) then using this form is most likely not a good idea.

As for me backing up my claims, I'm not going to attach a copy of my merchant agreement to a comment on the web, you are totally free to disregard what I wrote. This advice is worth exactly what you paid for, and everybody that has a merchant account but is not the merchant of record (aka a 'sub-merchant' in payment processing lingo) is totally free to inspect their own personal copy and for everybody else this does not matter at all.

Further reading on the subject:

https://www.pcicomplianceguide.org/pci-faqs-2/

A list with a sample of payment facilitators (if you use one of these you are quite possibly not the merchant of record):

http://www.mastercard.us/merchants/accept-mastercard/payment...

Note that this is not an exhaustive list by a long shot.

The mastercard FAQ which has a nice little blurb about who is and who is not a merchant or record:

http://www.mastercard.us/merchants/assistance/faq.html

Also of interest:

http://www.mastercardbrandcenter.com/us/images/acceptance_ma...

Less interesting (branding, not acceptance marks):

https://www.mastercardbrandcenter.com/us/getourbrand/index.s...

Oh, and an afterthought: there is yet another important logo, the VBV one, you can only use this if you're actually part of the program.

I am fully aware of PCI, I used to develop billing systems, Utility Billing Systems to be exact a heavily regulated industry that has even more rules than normal ecommerce. Further anyone that collects credit card data must be PCI Compliant, period. There are 4 Levels of PCI Compliance and depending on what your doing with the Credit Card data and how many transactions you process determine where you fall, many small merchants are only Level 4

Edit:

I Just looked at your list of "Payment Facilitators". If you use one of those processors YOU DO NOT HAVE A MERCHANT ACCOUNT. I think that is where the communications break down is happening, a merchant account is a specific thing, Using 2 Checkout, or Stripe (which is the service this seems targeted at) does not mean you have a "merchant account". None of these services claim to give you a merchant account.

Further I can find thing to support your claim that using this form with Stripe or another "Payment Facilitators" would be in violation of any agreements. However when I replied I was not talking about people that use these "Payment Facilitators", a person with merchant account, a person that uses a full gateway like Authorize.net which a huge number of merchants do should not be at all concerned with using this form

None of the links you posted have supported your claim, nor can I find any supporting documentation to back your claims. You do not need to post your mythical very restrictive merchant agreement, you should just post the text about that your talking about. Or find me any company most of which have their standard agreements and terms online, that says anything about this. I have look at most of the major payment gateways, 3rd party processors, and various others people, plus I have contacted some people I know that still work in development of payment systems (I have been out of that game for about 5 years now) and none of them have any clue what your talking about.

Well, some people that I contacted verify my story and I worked on payment systems as recently as 6 months ago. But what statements like that do to bolster a position is not clear to me.

I'm not sure what you're trying to achieve here, some kind of anecdotal proof that I'm wrong?

You're completely missing the point of the sub-merchant situation, one where you have a contract with both the card companies (one for VISA, one for MC etc) and a contract with an IPSP. This is the situation I'm talking about and it is one that is quite common for mid-sized merchants, just a bit too large for the various parties listed in those links and too small to be dealing with the overhead of becoming PCI compliant.

Whether you and your friends are aware of that or not is frankly immaterial, I happen to be in that precise situation so I think I know what I'm talking about, whether you believe me or not is your problem.

I'm under no obligation to post any text here whatsoever, this is an internet forum, not some kind of court proceedings and the claim I'm making is not so outrageous that it requires extraordinary proof to satisfy you.

No you are not under any obligation to post anything, however when posting something you claim to be a violation of law or policy is customary to support that claim with citations to where you have gained this knowledge. To date you have not posted any citation to support your claim in a verifiable manner. You have posted no terms, no laws, given no citations of any regulations or policies that are open to the public review, My own investigations have found nothing in any written documentation to support your claims. I believe you are wrong, and have asked you to provide a citation back your claims, which to date you have not.

If this was an official position of either Visa, MC, or an "IPSP" you would be able to post a link to their official terms that spell out that position, since you can not your comment should be ignored.

As to PCI Compliance, I will say again, ALL PERSONS TAKING CREDIT CARD MUST BE PCI COMPLAINT. Small, medium, large it does not matter, if you accept credit cards at all you much be PCI Compliant. Level 4 Compliance is a joke, and even the smallest of small business can become Level 4 Complaint...

Level 1, which is what a Walmart would be, is hard to get and most online merchants do not even attempt to get that.

On the "Before" it says "painful". What is painful about it?

And as someone else said, I also tried entering ON the card rather than below it.

that would be a neat feature.. kinda hard to do the CVV thing though.. unless you have a "flip me" link somewhere...

Well there is this one which flips https://news.ycombinator.com/item?id=6143604

And this one which doesn't https://news.ycombinator.com/item?id=6692075

Was thinking the same thing about the "painful" descriptor. I'm thinking it was just a joke...?

Very cool experiment but as others have pointed out it's tough to beat simplicity from a conversion perspective.

Example Amazon:

http://i.imgur.com/aK8K4UY.png?1

Single name on card field Card # Dropdown for EXP

Example Stripe:

https://stripe.com/checkout

Single name on card field Card # Exp / CVC

Less is more when it comes to this point in your conversion funnel.

And the fundamental conversion issue around collecting a CC at this point in cycle isn't usually design, it's trust.

(disclaimer: balanced employee)

There's a direct statistical correlation between less fields and the amount of chargebacks received.

So, yes, less is more for a conversion funnel, but do not assume that it comes without a cost.

"direct statistical correlation between less fields and the amount of chargebacks received"

Spot on and completely agreed.

But in my experience getting that CC at nearly any cost, even @ the end of a long sales process, delivers net gains even measured against returns etc.

For enterprise (eg anybody that can afford it) there are fraud prevention solutions in place to balance the outcome and I've been thrilled watching STRIPE strip away the complexity for "the rest of us".

But point well taken, multiple considerations in testing anything in your funnel and always optimize to highest LTV / KPI.

Point of reference for the above is spending the last ~10 years running CRO projects across dozens of verticals, millions of transactions.

I'd be most interested in seeing the correlation between fewer fields and overall conversions, accounting for chargebacks. Neither conversions alone nor chargebacks alone tells the whole story.

Looks nice, perhaps you can implement the Luhn algorithm to ensure the CC is not known-invalid (to prevent data entry error)?

http://en.wikipedia.org/wiki/Luhn_algorithm

Validation on the expiry date would be nice too.

This is really pretty. Kudos to the dev/designers. However, if there's one thing on my website I don't want to be exciting, it's entering payment data.

There's nothing painful about a regular form with the minimum amount of fields.

Great, so instead of worrying about someone peeking over my shoulder, I now have to worry about the person 30 feet away, with the size of that font.

It's a nice display, but as others have said it invites attempts to type on the card itself (which doesn't work). It also doesn't scale with increased font sizes; the card remains the same size and text within it wraps or gets cut off.

Interesting experiment! I'd like to see some data on how effective it is versus typical card entry fields.

At first glance I think users would be extremely confused by what is happening in terms of what to fill out, if not full out distracted by the animated card.

FWIW, Chrome blocked your calls to load various JS and CSS files from Yandex because you used HTTP, not HTTPS.

Yep, example does not work for HTTPS users of GitHub. I use HTTPS everywhere, so I'm always defaulted to HTTPS where available.

And in this case, where not available as well.

I once saw a detailed analysis of skeuomorphic credit card input, and it turns out the general population is less likely to fail on a non-moving credit card input box, largely because of difficulties with entering the CVC code. This combines both the skeuomorphic nature of Skeuocard by Ken Keiter (http://kenkeiter.com/skeuocard/) with the simplicity of creditcardJS (creditcardjs.com). I love it!

I'm no design or UX expert and this does look smooth.

However, how does this stack up against the recent UX trend of moving away from skeumorphism? Why should a CC number be represented by an actual plastic card that is coming to life and flipping around on my screen?

I believe the future of plastic credit cards is limited given the security loop holes etc. Companies like Square, Google, etc. are already championing transferring money over native internet identities like email addresses.

I think that assessment is fair. Consider though that many users struggle with matching the data they have on the card with what goes on the form. Specifically the cvv code since some vendors use a 4 digit code instead of the more mainline 3 digit code. So I see a valid use case in here in presenting them a reasonable facsimile of whats in their hand to match up.

Pretty nice, pretty similar to JS Skeuocard (http://kenkeiter.com/skeuocard/)

I actually like this one a lot better. Not being able to enter information onto the credit card itself was frustrating.

This is great! There's also Skeuocard (http://kenkeiter.com/skeuocard/) which offers a bit more of a skeuomorphic design. I think I favour the form as part of the card, however this may be confusing/inaccessible to some people - nice work on the library!

I like skeuocard's experience a lot. But it's not responsive, so it was a no-go for me. Ended up rolling my own.

One great optimization skeuocard has is it only asks for the cc# at first, then the other fields appear as you type it in. So the form is less daunting at first.

I have a few problems. To fill out the security field I have to actually flip the digital card over. To do so requires me to click on something that looks like a close button. It made me feel like clicking on it would invalidate all the card info I had just typed in.

When one field is valid that field no longer appears editable, so if there was a mistake in the spelling of my name it took me a minute to figure out I can still click on my name to change it.

It doesn't tell me the card number is invalid until after I enter an expiry date, that may be legitimate but it caught me off guard.

I don't like it. It's too confusing for what should be name, card number, expiry and security number. It doesn't address the fact that after I fill out those four fields, I still need to enter my billing address in what would be at least four additional fields regardless.

This code looks eerily similar to Stripe's jquery.payment (https://github.com/stripe/jquery.payment/blob/master/lib/jqu...)

For me the whole thing took too long to load. I didn't even see the card until I had filled in most of the data in the fields (and I was thinking, 'What's so different about this?'). Then the card loaded and all the data I had put in already was automatically deleted and I had to do it all again. If I was buying something on a whim, this might just be enough for me to think 'Forget it'.

More generally, while I do think that entering card details is a bit of a ball-ache, I don't think the solution is having a picture of the card on screen...

It doesn't seem to be working to tab between fields in Chrome. Once I've entered the expiration date it just fails to go to CVC or let me tab into it. had to use the mouse to switch fields.

It is validating that the card is in date, if you enter a date that is in the future, it will let you tab to the ccv field.

I can't imagine I would ever use this, as a developer or as an e-commerce customer. But it is certainly a well-executed, fun exercise... Folks on CodePen.io would go bananas over it.

Used in production today on an internal tool that we do some billing/card running on. After some small jquery options struggles, it worked as it says on the tin.

Interesting reaction by test group when deploying....test group being a small group of coworkers. Without announcement, they immediately were untrusting of it and thought it was somehow consuming the credit card information maliciously. This is the security climate we find ourselves in. heh But after assuring them, they thought it was pretty neat/fun.

Fun.

I really want to like this because the design and functionality of is very cool. Like others I tried to start typing on the card so there is definitely an element of confusion that isn't there with a normal form. The last place I want to risk any confusion is the stage at which the customer is trying to pay me! A variation of this where you could type on the card might be interesting.

Looks nice, but doesn't play well with autocomplete in chrome (tab completing my name didn't show up on the card)

I was about to say the same thing, also doesn't work for credit card number. I autocompleted in a phone number and it didn't show up at all.

This looks great, but any code that attempts to guess the card type using the first few numbers always makes me nervous

Why does it make you nervous? I was under the impression it was pretty fool proof? See: http://stackoverflow.com/questions/72768/how-do-you-detect-c...

FYI, the expression is "fool proof"

Fixed, thanks! :)

Maybe there could be a version that doesn't try to guess the card and uses a generic card background.

Credit card numbers contain a unique ID for the issuer: http://en.wikipedia.org/wiki/Bank_card_number#Major_Industry...

Any reason why? It's a pretty straightforward system that card companies use. For example every Visa card begins with a 4, and only Visa cards begin with a 4.

Also fun if the last digit would be autofilled based on Luhn algorithm :)

He's not really "guessing" the card type, there's a pretty standard algorithm called the Luhn Algorithm that all credit card companies use when issuing their cards.

The algorithm is public domain and all it does is tell you who issued the card which doesn't seem like an issue to me

It isn't providing a visual for all credit card issuers, though (eg Diner's Club, JCB). Those cards may still be processed correctly (I don't have any way of verifying), but visually treating a correct input like an invalid input isn't going to help conversion much.

Easily solved by simply adding treatments for more card types, and styling the entire card isn't that much more effort than just displaying an issuer logo.

Where this starts to get really interesting (from a slick + branded perspective) is when you start handling gift cards.

Looks absolutely beautiful. But I stopped for a second and did not, at first, give my real card number.

Are we so used to crappy CC forms, that a nice, flashy one (which I know is open sourced on github - I can validate if they are doing something bad) is slightly scaring me?

Wow that's the power of crappy design fed to us for years.

Tab from expiry to cvc doesn't work in the interactive. Other than that, honestly, I was just impressed by the "boring" version. Very tidy form, nice to see a new take on it. Existing cc forms around are seriously painful to use. Really digging the card vendor detection, neat touch.

That's a lot of code for a sliver of functionality. Does that concern developers these days?

If it increases credit card signups at all, it's worth it.

Oh, wow. The first time I loaded the page the image didn't form correctly and it was just a block of text which was hideous. Then I read the top comment calling it gorgeous so went back, and now that it loaded properly, I agree! Quite awesome.

thank you for this. i've never understood why credit cards are printed w/ spaces between the numbers, presumably to reduce transcription errors, but 99.9% of web forms force you to enter the number without any spaces.

Its broken for American Express cards. Amex cards don't do the number as 4 groups of 4, and the security code is on the front.

EDIT: I apologize it works! (note I did try it but apparently mis-typed my first four digits ....)

It worked fine for me on my Amex tests. 4-digit security code showed up in the right place, numbers were grouped correctly.

Did you try it? It gets the 4+6+5 and CVC on the front just right!

Doesn't seem to show the card at all in Safari. Works in Chrome, however.

Which version of Safari are you in? I've tested it in all of the latest versions, but it could easily be broken in an older one.

Looks like it's not Safari's fault - I'm using Disconnect, which blocked the highlightjs lib from loading from yandex.st.

Fixed :)

Doesn't work on Lion: Safari 6.1.2 (7537.74.9)

Anyone seen a similar implementation which doesn't need jQuery?

http://www.doxdesk.com/img/updates/20091116-so-large.gif

Except that I would have to use the mouse to navigate from Expiry Date to CSV field. I would prefer a simpler one where i wouldn't need to touch the mouse.

Love it, reminds me of the Dropr design when paying with credit cards. I guess it's not for every webpage, but it's a playful payment design

I see no difference. This error is displayed in my console.

  ReferenceError: hljs is not defined

On line 123. Hope this helps, good luck.

If you're looking at this and not seeing any difference between the "before" and "after" versions, it's because HTTPS Everywhere is redirecting all github urls to their SSL version, so http://jessepollak.github.io/card/ redirects to https://jessepollak.github.io/card/ then can't load any of it's javascript dependencies due to the http/https mismatch.

Bonus points for the form still working right through all of that.

Same for me, the yandex domain they're loading hljs from seems to be blocked. The hljs call is in the same script block as the line to initiate the fancy stuff, so it fails and that line's never reached. Paste this into the console to run that manually:

    $('.active form').card({ container: $('.card-wrapper')})

yandex was being blocked by Disconnect for me

https://camo.githubusercontent.com/312e819c130acb5d17a5a8568...

Same issue here, but that's what it should look like.

Gorgeous.

Two minor points...

It would be nice if it checksummed the card to ensure the entered number was a valid credit card number on form exit.

You can get 17 digit credit card numbers now.

Can't tab out of the expiration date field FYI

Looks really nice, but right now it's quite buggy on IE 11. I see a lot of flickering and it keeps scrolling to the top of the page.

Another point, I tend to rely on iCloud Keychain and 1Password to store card information.

Perhaps you should ensure it works with those data entry methods?

If you need something easy, nothing is better IMO than Stripe Checkout.

It's insanely easy to integrate, and has an awesome (modal) payment form.

Mouse scrolling is broken on that page in IE 11.

looks cool.

Any A/B test results on conversion rates?

Haven't gotten to that point yet — I originally just set about implementing all the cards in CSS then decided to actually make it into something people could drop in really easily.

Love the design, thanks for this! The conversion rate must be analyzed but it definitely looks gorgeous.

If anyone ends up doing some user testing with this form, please let us know the results!

2nd coolest thing I ever saw, just behind Psy's Gangnam Style :-)

I like it a lot; one suggestion: increment the card colours contrast.

Very Very cool!

This looks great and without using images - kudos!

Reply on news.ycombinator.com