9

There has been a lot of discussion around Stripe 'Elements' default credit card field placeholder text.

Their default is '4242 4242 4242 4242' as shown below: stripe elements 4242

There are a few vocal users complaining that they can't change it to something else. Stripe were seeking feedback from the users along the lines of 'Well, what would you change it to' - and replies varied like so:

  • "****-****-****-****"
  • "0000 0000 0000 0000"
  • "CREDIT CARD NUMBER HERE"
  • "Let me set it to whatever I like!"

The latest activity is a user threatening to change payment providers because they cant change the default placeholder text, because their users are complaining about it.

Personally, I couldn't give a rats either way, but I can understand if your customers are complaining then perhaps you would like it changed.

So UX.SE - from a UX perspective, what should Stripe do in this situation?

12

Placeholders gone terribly wrong

tl;dr
When a placeholder doesn't clarify anything, it shouldn't be there.

This is a great example of the negative impact of placeholder text pointed out by NN/g quite some time ago.

Summary: Placeholder text within a form field makes it difficult for people to remember what information belongs in a field, and to check for and fix errors. It also poses additional burdens for users with visual and cognitive impairments.

In this case, Stripe isn't adding any information by including the fake number. Users know what a credit card number looks like. The only thing it does is contribute to confusion when the user sees a number that isn't their own.

Keep the credit card icon and drop the placeholder text altogether. I'd start by testing something like this ...

Stripe controls without the placeholder noise

  • Good read - I wonder in Stripes case if having that field blank would be a good decision. In terms of a 'form', theirs falls in the 'ultra-modern' category and frankly without any text I would question upon seeing it if it was a field at all. I do like the adaptive placeholder approach in the NN/g article. – Jake Harry Apr 12 '17 at 0:43
  • 3
    So step one for Stripe is stop trying to be cool and make your form work. – plainclothes Apr 12 '17 at 1:07
5

I simply can't believe they did this. First of all, it shows a definite bias. Cards starting with 4 belong to VISA, so I can imagine all other CC card companies complaining.

Another thing: 4 groups of 4 digits, equalling 16 digits number. It sounds nice.... if it wasn't because I'm an AMEX owner. AMEX cards use the format NNNN NNNNNN NNNNN (4 digits + 6 digits + 5 digits= 15 digits number). btw, all AMEX starts with number 3, just in case.

Finally.... CC number and expiration date in the same field... wow... talk about confusing users.

What I would do

I really don't know if this sample is just a test drive or what, it really doesn't look as if they gave any thought at all, it took me literally 30 seconds to see the flagrant mistakes listed above, so I have to assume this is just a test.

Anyways, first thing first:

  • Differentiate fields: there's no way anyone will convince me that different data in the same field won't confuse users. Simply because I have tested this before! So I'd make both fields visible and clearly labeled.

  • Remove biased placeholders and hints: just take that placeholder and use text like "Enter credit card number here" . K.I.S.S. approach, so to speak. Most important part is NOT to use any number format, since there are differences between brands.

  • Give users control: If research shows complaints by users, and a desire to have control over the placeholder text, then it's quite obvious the system should have that feature available for their users. This being said, a neutral placeholder should be in place by default unless user changes it. After all, Stripe has knowledge and resources not many users have.

Disclaimer: like anything UX, recommendations should be based on real data, research and best principles. This example clearly ignores best principles, but on the other hand I don't have any research, only Stripe has it. Thus take this with a pinch of salt.

  • Looks like a case of "Two out of three ain't bad (it's worse)". Biased place-holder has gone, and the ability to customise is there, but now there's three pieces of data stuffed into one field! – TripeHound Aug 11 '17 at 11:01
1

UPDATE: Stripe have listened to user feedback and rolled out the following changes:

After a lot of research, more in-depth testing and many discussions with the team, with end customers, and with users (including some of you!), we’ve made a couple of changes to placeholders in Elements.

(1) The card Element now uses “Card number” and “ZIP” (and their localized equivalents) as placeholders. As mentioned above, we decided to make this change after testing revealed that “Card number” was more likely to result in successful payments than “4242 4242 4242 4242”.

(2) The cardNumber, cardCvc, cardExpiry & postalCode Elements now accept a placeholder option that allow you to set a custom (or empty) placeholder, as previously reported. If our default options do not fit your needs, we want to make sure you have the flexibility to build exactly the form you’d like.

Thank you all for pushing on this, for your patience, and for your suggestions along the way.

New placeholder: new placeholder

  • 2
    It's good that they've listened to their users regarding placeholder text (especially letting it be customised), but now -- against the advice in both answers -- they've crammed three pieces of information (card number, expiry date and CVC) into one field! – TripeHound Aug 11 '17 at 10:57
  • Hey @Tripehound I am just updating the issue I am not in anyway associated with stripe. – Jake Harry Aug 11 '17 at 10:58
  • Edited. Sorry, from your original message it sounded like you were connected with them. – TripeHound Aug 11 '17 at 11:00
  • What a disaster 😖 It makes me want to down vote this answer, but I know it's not your fault. – plainclothes Aug 11 '17 at 16:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.