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.
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. -->
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. ;_;
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.
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.
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.
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.
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.
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! :)
> 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.
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
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:
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.
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.
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.
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 :)
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.
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!
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.
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'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.
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
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.
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.
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.
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].
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.
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.
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!
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.
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.
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.
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.