
Show HN: Card – An interactive CSS3 credit card form - jessepollak
http://jessepollak.github.io/card/
======
dclowd9901
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.

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

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

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

~~~
logicallee
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?

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

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

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

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

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

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

~~~
logicallee
we're not disagreeing

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

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

~~~
squeaky-clean
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.

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

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

~~~
the_ancient
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](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

~~~
jacquesm
> 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...](https://www.google.com/search?client=ubuntu&channel=fs&q=origin+of+the+word+credit&ie=utf-8&oe=utf-8)

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/](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...](http://www.mastercard.us/merchants/accept-
mastercard/payment-facilitator.html)

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](http://www.mastercard.us/merchants/assistance/faq.html)

Also of interest:

[http://www.mastercardbrandcenter.com/us/images/acceptance_ma...](http://www.mastercardbrandcenter.com/us/images/acceptance_marks_v06.pdf)

Less interesting (branding, not acceptance marks):

[https://www.mastercardbrandcenter.com/us/getourbrand/index.s...](https://www.mastercardbrandcenter.com/us/getourbrand/index.shtml?pageId=dl_1510&expertVisible=false)

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.

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

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

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

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

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

~~~
wingerlang
Well there is this one which flips
[https://news.ycombinator.com/item?id=6143604](https://news.ycombinator.com/item?id=6143604)

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

------
aresant
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](http://i.imgur.com/aK8K4UY.png?1)

Single name on card field Card # Dropdown for EXP

Example Stripe:

[https://stripe.com/checkout](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.

~~~
mahmoudimus
(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.

~~~
aresant
"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.

------
r00fus
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](http://en.wikipedia.org/wiki/Luhn_algorithm)

~~~
BillinghamJ
Validation on the expiry date would be nice too.

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

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

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

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

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

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

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

~~~
DatBear
And in this case, where not available as well.

------
primitivesuave
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/](http://kenkeiter.com/skeuocard/)) with the
simplicity of creditcardJS (creditcardjs.com). I love it!

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

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

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

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

------
iLoch
This is great! There's also Skeuocard
([http://kenkeiter.com/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!

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

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

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

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

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

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

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

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

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

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

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

~~~
bluetidepro
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...](http://stackoverflow.com/questions/72768/how-do-you-detect-
credit-card-type-based-on-number)

~~~
recursive
FYI, the expression is "fool proof"

~~~
bluetidepro
Fixed, thanks! :)

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

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

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

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

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

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

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

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

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

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

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

~~~
jessepollak
Fixed :)

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

~~~
ceejayoz
[http://www.doxdesk.com/img/updates/20091116-so-
large.gif](http://www.doxdesk.com/img/updates/20091116-so-large.gif)

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

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

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

    
    
      ReferenceError: hljs is not defined
    

On line 123. Hope this helps, good luck.

~~~
Zikes
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')})

~~~
pix64
yandex was being blocked by Disconnect for me

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

------
smrz
Can't tab out of the expiration date field FYI

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

------
r00fus
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?

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

------
frik
Mouse scrolling is broken on that page in IE 11.

------
jpeg_hero
looks cool.

Any A/B test results on conversion rates?

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

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

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

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

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

------
czbond
Very Very cool!

------
kzanul
This looks great and without using images - kudos!

