Hacker News new | comments | show | ask | jobs | submit login
Stripe Elements: Pre-built UI components to help you create checkout flows (stripe.com)
494 points by edwinwee on Oct 3, 2017 | hide | past | web | favorite | 122 comments

Stripe front end developers are a true inspiration. I know the linked project isn't anything revolutionary, but as someone with a decade of experience in the field, it's impressive to see such attention to detail.

Their work somehow manages to be the right combination of cutting-edge flashiness (think Apple product landing pages) and a very down to earth usability. I can't quite put my finger on it, but it's rare to see interfaces that don't compromise one or the other at least slightly.

If any of you are reading this - congratulations, you should be really proud.

Oh God, yes!

I love the attention to small details they're giving here. It's the kind that I absolutely admire but so rarely see. For example, in the section "Less code. Fewer edge cases." - a) the code "image" scrolls in the direction you scroll, and b) the code is actual code, made to look that way through use of a font (Flow-Circular). They could have went with a nonsense PNG with horizontal lines, but instead, they put actual code. They even went as far to leave this in the HTML just above that place:

<!-- This is a trimmed down real Stripe.js v2 basic integration. The full version would be much longer. -->

Hats off to them.

Not to mention the correct use of 'Less' and 'Fewer'. Well done copywriters.

Stripe has some great copy writing for sure, but I don't think correct grammar should be listed as one of the reasons why. :)

Wow, that's a pretty cool easter egg! I copied the "image" and pasted into Sublime, and there you go: actual code!

Very cool little detail, color me impressed!

Yeah super cool! It's apparently just done by using a font called "Flow-Circular" that comes out looking like that.

Every time I see a Stripe page I just stop and stare for a minute. They're always so, so well done.

Stripe is gorgeous, though they have one of my pet peeve UI issues on the front page:

The nav Menu buttons are hover elements, and clicking them closes the menu. So if your first instinct is to navigate to "Developers" by clicking it (and it probably is), you're rewarded with a brief view of the menu before it fades back away.

AWS has the same issue on their "My Account" button. ;_;

It brings me a lot of joy to see companies like Stripe and Apple put so much effort into polishing their products.

Most companies can't even build their fucking landing pages without inconsistencies in design and content.

I believe a healthy obsession with detail reflects a company's overall attitude and pervades much deeper than visuals.

Thank you Stripe! <3

I agree. It's refreshing to see a company not jumping on the completely flat, mono-color bandwagon.

Sometimes simplicity doesn't seem revolutionary, but a beautiful attention to detail combined with customer empathy can yield dramatic results.

The converse of:

“I didn't have time to write a short letter, so I wrote a long one instead.”

― Mark Twain

To add to the praise for Stripe, their API docs are a pleasure to use.

I feel like half of the internet copied Stripe's REST API documentation design. They were the first to make them a pleasure to read, now almost everyone's docs are pretty.

In the linked page on the right, is that a video? https://i.imgur.com/qloK4xE.png

I was just wondering how they made that.

It's all CSS animations!

I am very curious to how exactly they made these animations! Surely they didn't hand type all of the transforms.

I see a lot more of similar animations appearing on the internet.

Are there tools that people use to help with the animations?

Most tools put out a lot of unnecessary code and often rely on JavaScript, so my guess would be that this is handwritten. The animation consists of three phases for each element, which they reordered using pixel value transforms. The background containers are fixed in place and the opacity is changed depending on stage 1/2/3. To ensure them not having to adjust any values for smaller devices, they scaled the parent element to fit the browser size. Time consuming, but the best way to get the performance you need.

I’ve used BounceJS in the past: http://bouncejs.com

It can be done using Adobe After Effects and the Bodymovin plugin.

..except you will end up with a 300kb js file and a massive Json file. Whilst this plugin generates magic your speed suffers with it.

http://animista.net/ is quite handy for quickly putting something together.

Stripe and Apple. I thought i was the only one noticing these two. Out of all the other Major tech companies. They happens to be the least consumer Web focused and have the best Web page design. ( Stripe isn't really mass consumer facing Web Company, And Apple is more about their Hardware and Software Product rather then Web )

You cant say the same for Yahoo / Oath, Google, Facebook, Amazon or Ebay.

I wish some could share how Apple design and what Apple uses in the Web Stack.

Minor nitpick: there's no way to see the tooltips on the checklist at the bottom on android for more than a second.

And on iOS there’s no way to see them without triggering the copy/paste menu.

Can't express enough how much I love stripe's design. It's so inspiring. After working in a SAAS company for 3 years, I learned how difficult it is to fight for a good design with engineers, PM and managers. Lots of them don't care or respect about design.

This is from Apple Special Event 2017

(Steve Jobs’ voice) "There’s lots of ways to be as a person. And some people express their deep appreciation in different ways. But one of the ways that I believe people express their appreciation to the rest of humanity is to make something wonderful and put it out. And you never — you never meet the people, you never shake their hands. You never hear their story or tell yours but somehow in the act of making something with a great deal of care and love, something is transmitted there. And it’s a way of expressing to the rest of our species our deep appreciation. So we need to be true to who we are and remember what’s really important to us. That’s what’s going to keep Apple, Apple, as if we keep us, us. "

The design of stripe is definitely a good example of this statement.

Stripe is really, really good at marketing to developers. I have to imagine it’s earned them a lot of business.

To the extent that devs are involved in vendor selection, I have to imagine that a large majority of them suggest Stripe to their CFOs or whoever ultimately decides.

Yep, that's what happened at our company. Developer experience matters.

Stripe in the pinnacle of what startups should aspire for. Their commitment to solving pains for smb's is what's propelled them to unicorn status.

I also love the story of their founders - https://www.bloomberg.com/news/features/2017-08-01/how-two-b...

Here's the same URL but without all the utm_* tracking garbage:


I'm curious, what is the motivation for avoiding that stuff? It seems to just be there to make it easier for Stripe to see where traffic is coming from, in this case.

Why? I mean you're still sending the referer header, right?

No, browsers don't send the referer header for https links.

That's only if linking from https to an http page which is not the case here.

Off topic: Is there a chrome extension that will strip these query parameters off automatically when a user clicks on links?

I found https://chrome.google.com/webstore/detail/url-tracking-strip... but wasn't sure if someone might have found a superior extension.

I created this [1] some time ago to manipulate links in the pages that I visit.

This part [2] removes the UTM parameters from the links in certain websites.

However, I stopped updating the extension when I switched to Safari some time ago.

I used to use this one [3] which was actually my inspiration to create my own project.

[1] https://github.com/cixtor/markasread

[2] https://github.com/cixtor/markasread/blob/08726ce/markasread...

[3] https://github.com/jparise/chrome-utm-stripper

I prefer "Ghostery" which is more efficient in "Tracking" overall. try it out.

Aren't ghostery the ones who sell your personal info and allow advertisers to pay them to get on a whitelist? UBlock Origin is my recommendation.

> UBlock Origin is my recommendation.

You may prefer it to Ghostery, but it doesn't actually address GP's request, for query parameter stripping does it?

Can someone explain how that utm_* stuff got there if the original poster didn't include it? And if he did, where did he get this URL from?

utm_source is set to 'HN', so the original poster did include it, or it would say something else.

OP is Stripe employee, so that'd make sense

Google Analytics.

damn, another lesson in reading the comments before clicking on the article

Stripe Elements is really good. It has been an absolute help.

Now if only we could get something similar for the Connect account stuff. So many different edge cases for countries and businesses, that the only reasonable approach is to autogenerate a form, and hope it makes sense.

Example: Japanese business need to put in their address in kana and kanji, both personal and business address. They also need to specify their gender (and are the only ones who have to do this). I believe they also need some form of personal and business IDs.

Form validation? Forgettaboutit!

Note: I realize these requirements are most likely not strictly determined by Stripe.

Here's hoping Elements expands to Connect accounts in the near future! :)

Engineer on the Connect team here.

> Now if only we could get something similar for the Connect account stuff. So many different edge cases for countries and businesses, that the only reasonable approach is to autogenerate a form, and hope it makes sense.

We're working on it! Express international support will ease most of the pain in this space (coming soon), and we have talked through ideas for how we can make Elements that handle things like international bank account and routing numbers. We also want to make it easy to migrate from Custom to Express, since you'll get i18n/L10n for free as it lands, and we'll handle things like requesting additional information from your users and showing the right (validated!) fields.

Thanks for the reply! Really looking forward to the development of this :)

Keep up the good work!

Awesome ! It's currently a painful form to maintain :)

Elements works with Connect! Any platform can integrate it.

We're also working to improve the connected account flow. In the US, we recently launched Express Accounts to help with this, and we hope to bring it to Japan soon. https://stripe.com/docs/connect/express-accounts

Interesting to see the contrast between the love for Stripe's design team vs. yesterday's Dropbox UI refresh discussion:


> mugsie: Wow. that is (from my perspective - but only mine) terrible.

> supernintendo: This is the worst UX I've seen in a long time. Not only that, it's visually garish.

> chrissnell: That typeface is just dreadful.

Maybe I will check back in a few days to see if any of the same users commented on both threads!

So, is there a way to use this without the iframe (by going to stripe.com and then back)?

As a customer, when ordering something from a shop I prefer to send my CC details to stripe.com instead of the vendor. With an iframe i usually cannot tell that this is the case.

Actually, CC details never transit to the shop server. The CC inputs don't have a "name" attribute, so the browser doesn't add them in the request. Instead, the stripe javascript catches the submit, sends the CC details to stripe with ajax, and add an hidden input containing an authorization token the server can use.

Of course the customer don't know that, but as a developer I'm very happy not to handle any CC details in my server/app :)

This is why i love paypal.

I don't want to input my credit card info in whatever site, I'd rather do it in paypal.com.

Agreed. That's why it's weird that on eBay nowadays they make it very hard to get paypal.com up in the address field of the browser. If you use the standard workflow it will be in an iframe and you will be none the wiser.

Slightly OT : With Stripe elements, we noticed an error in about 5% of the requests, something like "Stripe is not defined". Some of these errors were traced to older browsers with JS issues that couldn't execute "https://js.stripe.com/v3/". But some remain unexplained. Unfortunately, it's hard to debug a client side error unless a client reports it.

Just thinking out load about possible issues that could cause this failure:

1) Extension blocking Stripe (as @Artemis2 mentioned below)

2) An older browser that's unable to execute Stripe JS (but uses a fake user agent that confuses us into thinking that a modern browser might be failing).

3) Unreliable internet client connection that is unable to load Stripe script intermittently.

Stripe elements is beautiful & flexible and the team is super helpful. We'd love to use it, but with the above problem, it's a bit scary to lose customers silently. For now, we are sticking with the Checkout flow.

We'd appreciate any tips on how to catch/fix an error like this ?

It could be because tracker-blocking plugins (I use Ghostery) have started blocking Stripe.js. This is because they are now recommending to include it on every page of your site for fraud protection, which is a use case of user tracking: https://stripe.com/docs/stripe.js#including-stripejs.

Thanks for the tip. It seems that ghostery's issue was fixed in August [1]. The latest version of ghostery does not block Stripe elements. Preventing an extension update isn't straight forward so we are left wondering if there's some other extension that's blocking Stripe.


I can imagine there's other similar addons that use the same list, but don't update it as frequently.

Stripe could/should offer a self-hosted version of the .js file for just this case, as a fallback to the official .js file; enabling basic payments, but with a notice that an addon is blocking the official stripe.js file and fraud protection is not enabled. Maybe even charge a slightly higher fee to the end-user? Probably not the right thing to do. Offer a fallback that survives external JS blockers.

True, didn’t realize they had pulled the block. Would be interesting to know how the decision was made with respect to user privacy (vs. breaking sites). I don’t know which other extensions may block Stripe.js unfortunately!

We used to experience this exactly with stripe.js V2, our conclusion was it was some sort of connection issue and using this code to include stripe.js on both the checkout page but also our basket helped to ensure it has been loaded by the browser before it was needed. It massively reduced the instances of the error.

  <script src="https://js.stripe.com/v3/"></script>
  <script>window.Stripe || document.write('<script src="https://js.stripe.com/v3/"><\/script>')</script>
  <script>window.Stripe || document.write('<script src="https://js.stripe.com/v3/"><\/script>')</script>

That's quite interesting. Was the issue specific to any particular browser/platform/country combination ?

Stripe's server log might record/report failures in loading scripts. Perhaps someone from Stripe can chime in on the issue.

I can't remember exactly what browsers were affected but I think it was fairly broad. Certainly, mobile browsers and maybe people on a VPN but it was mostly random from memory which is why we concluded it was just a temporary connection problem.

As an aside we also saw similar errors loading jQuery from a CDN and so used similar code to load it from our own server if it wasn't loaded from the CDN first. You cant do that with Stripe though.

A client side error capture script like Sentry helps with debugging these sorts of errors. We have been using it successfully for some time now.

We are able to capture the error / stack with vanilla JS. Tried sentry too. Wondering how would it help in debugging. What we have is the error message and the user agent but unable to reproduce the same problem unless we no more about the extensions installed or if the user agent is fake.

I was wondering if it's possible for e.g. Sentry to list installed extensions, but that'd give websites another means to do fingerprinting, probably not a good idea for browser manufacturers to have implemented.

Can this be used for just frontend and not integrate with Stripe's backend? ie. use the "elements" form and not create the token to transmit card information. Sort of like a beefier Card library by jessepollak (https://github.com/jessepollak/card)

Setting up a little Express server that deals with the backend stuff is not too difficult. [0][1] Looking forward to update the article for using Stripe Elements. Great job Stripe team!

- [0] https://github.com/rwieruch/react-express-stripe

- [1] https://www.robinwieruch.de/react-express-stripe-payment/

I don't believe so. You don't get the card info from the form, you only get the generated tokens. I could be wrong, but I believe that's how it works.

That's fundamentally a big part of the point: you never directly handle any payment info, which frees you from most of the tremendous liability and security concerns that come with directly handling payment info.

Indeed. And with the upcoming stricter EU laws on data handling, I think this is a big plus.

Nope. I'm prety sure that's completely intentional, both for security reasons and for branding reasons (e.g. anybody using a Stripe form knows that the website they're on can't actually see their payment info).

I think the css for the different forms can be found here: https://github.com/stripe/elements-examples

I've used these vanilla and in a react app, all with great success. I really hope they build web component versions, would cut down a lot on the vanilla usage boilerplate.

I love Stripe and used them for 4 years, but unfortunately have to use Braintree now because of Paypal.

Please Stripe, figure out how to integrate with Paypal. And my company is yours again.

For those wondering ‘why PayPal?’ I run a SaaS product using Stripe, and a lot of people have asked if they can pay by PayPal. Although in the West it’s a no-brainer to enter credit card details and be done, in a lot of other countries people don’t feel so comfortable doing so. In some cases it’s actually very foreign, for example Amazon et al in India allow you to pay cash on delivery.

PayPal is a good option in these cases as it means you don’t need to give you card details directly to the merchant. Although in reality this doesn’t happen due to PCI if something like Stripe is done properly, you are still typing in your details on a website you don’t 100% trust, so there is a mental barrier. I wonder if Stripe have considered having a ‘Stripe Account’ for consumers where you can link your cards/payment methods so they can have a checkout process like PayPal...

You can enable "Remember Me" when using stripe checkout [0], and you won't need to retype CC* on other sites that use checkout, but I don't think it's obvious to users that it's connected to Stripe and not the merchant's site...

* as soon email is entered, Stripe sends a code to phone as means of validating the user

[0] https://stripe.com/checkout

People in the west still use Paypal a lot.

Out of thousands of transactions (video courses for developers), about 40% of them are done with Paypal and most of my audience is North America.

Now, I do give the option to use either a CC or Paypal and I'm sure a lot of those 40% would use a CC if Paypal wasn't an option, but it does show a ton of people want to use Paypal.

For me I tend to use Paypal because I'm too lazy to type/paste in my card number, address etc. Paypal is usually one or two clicks.

Yeah, I'm developing a new product at the moment - I surveyed a bunch of end-users and a LOT of them had PayPal accounts - so Braintree's PayPal integration is a compelling feature to me. That said, here in Europe, Stripe's fees are better than Braintree's, and PayPal's Eurozone fees are quite eye-watering.

That said, I'm Irish and therefore totally biased toward Stripe for that reason alone. As if their stellar tooling and the friendly, truly excellent customer and tech support I've experienced from them so far isn't enough :)

I am really pleased to see payment gateways finally offering something worth paying the fees for. With this, or Braintree's hosted i-frames we get easy PCI compliance (SAQ-A) and proper UX. No more pop ups! Well done Stripe. If it was a bit cheaper it would be a great service.

They automagically figure out what country the card is from so they can set the numeric/alphanumeric postal code.

Can I get that BIN list from somewhere so I can use this even if I'm not submitting to stripe?

Most bin lists haven't been very accurate or able to be scraped. Looks like the tracker is pretty active. I'll have to check it out. Thanks!

... it says the github repo "constitutes roughly 2 % of the data." So, not very much is open source?

That either takes a lot of time (and volume) to gather on card usage because it's not available as a list from Visa and co, or you require certain processing rights to access and can't share it due to confidentiality.

I forget the details, but I'm pretty sure it's the former, so it's not exactly easy -- which is yet another testament to how much work goes on behind such a seemingly simple new product.

That's speaking from experience though, I didn't mean to be dismissive of the request of the OP. If there happens to a group who collects this and is able to share this through legal loopholes, power be to them!

This is actually quite annoying. I have some Chase cards from when I lived in the US that now have UK billing addresses and therefore alphanumeric postal codes.

It's not uncommon for these to be unusable online because the form expects me to have a US address/numeric zip code.

I know I'm an edge case, but it's surprising how often sites over-validate form data and exclude all sorts of things like telephone country codes, non-US states, shorter zips etc.

I built a little Polymer wrapper for stripe elements </plug> unfortunately, it only works with the polyfill. It seems at first blush to be an issue between Stripe's react components and shadowDOM.


I upgraded our payment capture a week or so ago. It was easy to do (we don't have a complicated form) but I was bummed to find out that there is extremely limited support for ACH capture with elements.

Working on it!

(I work at Stripe)

This is great news! Any rough estimates on when this will be available?

Support for what? Electronic banking?

Support for capturing ACH data (account number, routing number, etc) with the 'Elements' UX toolkit.

I miss the JS tokenizer on plain text fields. It's hard to match validation and font styles in iframe fields.

That said, their React stripe elements library helped me use these in a project recently.

Elements lets you define validation behavior and styles by listening to event handlers that emit errors[0], and you can specify custom web fonts with the `fonts` option[1].

You can see a few examples of Elements using custom validation and fonts here: https://stripe.com/elements/examples

[0]: https://stripe.com/docs/stripe.js#input-validation

[1]: https://stripe.com/docs/stripe.js#stripe-elements

I am sad that this has been phased out. I have recently been working on a Square backed project, which uses this same iframe approach, but you cannot customize the fields or do any kind of validation: you just get the textboxes they give you with no way to add in things like specialized input types for numbers to help on mobile. To Stripe's credit, they at least go through the trouble of adding more intelligent validation & input handling. Will give this a closer look and may replace the Square version.

FYI, v2 of the Stripe.js API isn't being deprecated last time I checked with them.

Playing around with some of these I clicked on one button and discovered that Chrome has a built in payment system -- the button opened up a dialog with all my saved information. Neat.

Better yet if you have Apple wallet set up on your phone, and visit: https://stripe.com/elements/examples, you'll see that you have the option to to pay via Apple Pay. Which is powered by their Payment request element: https://stripe.com/docs/elements/payment-request-button

It's been there for around 4 years. It automatically generates a one-time card for the payment, too, so you never hand the merchant your card.


I think this API ended up being deprecated from lack of use (not surprising as no one used it and is amazed it existed), but it may have paved the way for https://developer.mozilla.org/en-US/docs/Web/API/Payment_Req....

Genuinely surprised that this didn't catch on, it was amazing.

RequestAutocomplete is indeed deprecated and Stripe is using PaymentRequest (which doesn't do anything fancy except pull your CC info from Chrome autofill for the record, so no one-time card for the payment).

RequestAutocomplete had some weird quirks that made adoption slow and full of friction. You're right to say that PaymentRequest is a fixed RequestAutocomplete in most regards, and it's amazing (I'm biased though, I'm one of the people implementing it on desktop Chrome :) ). It's being implemented by all major browsers too!

Stripe continues to impress me. UX/UI, product, documentation, website performance, API... all beautiful.

I trust/hope they compensate their workers just as well too.

Keep it up!

Stripe elements is awesome. The one thing I miss from stripe is help collecting sales tax across states.

There's also an official stripe elements react component. I tried it recently, and it felt like completely overengineered garbage. It was convoluted, involved implementing 3 different components as separate layers of implementation, required the use of component context (a huge red flag IMO) and was completely unusable from typescript. Compared to other projects I've seen from stripe, it left a lot to be desired.

Not really sure if I place that blame on Stripe though...React makes interop with non-react SDKs needlessly difficult.

That library is in beta. I agree it is convoluted, but it also isn't finished. It isn't nearly as polished as the elements themselves.

Damn, Stripe's design is the best in the world, I get inspired just by looking at it. It's like the girl/boy of your dreams.


No, because PCI DSS considers using iframes to host card entry fields cannot impact "the security of the payment transaction": https://www.pcisecuritystandards.org/documents/Understanding...

But there is AGP CD-ROM CC0 QQZ, so, you know. There's that.

why is this a tracking link.

so stripe can bucket the traffic that comes from this submission.

Can't they just look at the referrer?

It lets them identify clicks specifically from the post link as opposed to links in the HN discussion thread.

Can't they see the path in the referrer URL? Wouldn't that differentiate which page on HN referred the visitor?

https doesn't pass the referrer

Building smart checkout flows ... but that would include things like showing overviews of a shopping cart, allowing the user to make changes, and handling of physical products by the postal service, and I don't see that covered here.

"Stripe Elements are rich, pre-built UI components that help you create your own pixel-perfect checkout flows."

Stripe is addressing a component of e-commerce checkout UI with which they're most familiar. They aren't attempting to cover every single base.

That's more of a Shopify thing. Stripe is an API for processing payments, and you can build what you'd like on top.

Stripe has dropped its key advantage.

It started out with outstanding software support for the most popular platforms but now it doesn't.

Develop an application in ReactJs? Stripe hand wave: ahh go build your own solution or use some third party thing somewhere over there in "the community, sure you can trust it".....whatever, we're busy, and ReactJs, hmmm haven't heard of that.

Wait, what? The official React wrapper for Elements is on GitHub: https://github.com/stripe/react-stripe-elements

So they have a solution that works for everyone and you are complaining its not just made for $INSERTYOURFRAMEWORK. Interesting point of view.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact