Posted on

Fast Brings One-Click Checkout to WooCommerce Stores

Fast, a startup backed by Stripe, has just added WooCommerce support to its new Fast Checkout experience. The company was co-founded in March 2019, by Domm Holland and Allison Barr Allen, with investment from Stripe, Index Ventures, Susa Ventures, and Global Founders Capital. It has received $22.5M in funding to reduce the friction that remains deeply embedded in login and checkout experiences.

Online shopping almost always involves a lengthy checkout form where customers have to enter passwords, addresses, and payment information nearly every time. This tedious experience is magnified when gift-giving holidays roll around. Fast’s founders have set out to solve this problem with products aimed at modernizing the checkout experience to enable one-click purchasing.

Fast Checkout launched in September 2020, so if you haven’t seen it around yet it’s because it is relatively new and was previously limited to a handful of platforms. Expanding support to WooCommerce was a strategic move, as WordPress accounts for 39.3% of the Alexa top 10 million websites. WooCommerce is running on 18% of the WordPress sites W3techs can detect. Fast CEO Domm Holland said the product’s availability to WooCommerce increases the company’s addressable market by over 2,500%.

“We’ve received inquiries from thousands of sellers asking to add Fast on a variety of e-commerce platforms, including WooCommerce sellers,” Fast CCO Jason Alderman said. “We prioritized WooCommerce as it automatically gives millions of new sellers access to Fast.”

The company has seen a strong uptick in Fast Login adoption since launch, and Fast Checkout has had a promising debut.

“For Fast Checkout, the value of merchandise purchased on the platform has more than tripled each month since launching in September,” Alderman said. “Although not WooCommerce sellers, Fast merchants such as Gerard and Hardwood Lumber are seeing up to 30% (and rising) adoption rates since deploying Fast Checkout and up to a 10% increase in order volume within just 30 days of implementation.”

In order to gain all the benefits of Fast login and checkout, users have to sign up with a new service, which seems like it would be hurdle. Fast has embedded this process within the normal checkout flow so that it doesn’t feel like the consumer has to sign up for something new. The first time a shopper makes a purchase on a site using Fast Checkout, they enter their contact information. and payment details as they normally would.

Fast Checkout form on mobile for first time checkout

After that purchase, their details are stored and every subsequent checkout experience on any website using Fast Checkout will only require one click. It works regardless of the device or browser used and does not require a password, the same as the Fast Login product.

Fast Checkout on mobile purchase complete

Although Fast Checkout and Login are free to use for buyers, getting store owners on board is going to be the primary challenge for Fast. It charges US sellers 2.9% + 30c per transaction. Fast’s fees are not quite as steep as the 5% per shipment that Instagram will be charging for the new Shopping Checkout feature that WooCommerce is testing. However, it may still be prohibitive for stores with narrow profit margins. Fast also has competition from the multiple one-click checkout extensions available for WooCommerce that do not charge transaction fees.

Fast claims that the one-click checkout button “increases conversion, boosts sales, and delights customers” If the checkout experience can deliver on those claims, then some store owners may be willing to part with the 2.9% fee in order to capture a larger percentage of the potential customers that are already arriving at their stores, instead of risking cart abandonment with a frustratingly long checkout process. Store owners are looking for any edge in an increasingly competitive landscape where the online retail giants continue to dominate.

The pandemic has caused radical shifts in the retail industry, creating unprecedented opportunities for independent stores. Many WooCommerce developers and store owners have sought help for optimizing their stores after the pandemic caused business to increase exponentially overnight. A product like Fast Checkout is landing at the right time, as consumer spending habits have become forever altered by the rapid acceleration of the essential role of e-commerce for homebound people across the globe.

“E-commerce giants have heightened consumers’ expectations for online shopping,” Alderman said. “And with the COVID-19 pandemic this year, more people than ever opted to shop online, but many independent businesses were not prepared to prioritize the online experience. By adding Fast Checkout to their stores, businesses of all sizes can access one-click checkout that offers the seamless experience consumers expect (and eliminates shopping cart abandonment that happens to up to 80% of potential purchases).”

Fast is planning to expand its Checkout support to multiple new platforms in the coming months but did not have any details to share at this time. In addition to providing one-click checkout, Fast centralizes purchases across stores so that users can manage transactions, track shipments, and handle returns through a unified dashboard. Long term, the company is working on launching a universal subscription manager, which Alderman said is currently in development.

Posted on

A Bit on Web Component Libraries

A run of Web Components news crossed my desk recently so I thought I’d group it up here.

To my mind, one of the best use cases for Web Components is pattern libraries. Instead of doing, say, <ul class="nav nav-tabs"> like you would do in Bootstrap or <div class="tabs"> like you would in Bulma, you would use a custom element, like <designsystem-tabs>.

The new Shoelace library uses the sl namespace for their components. It’s a whole pattern library entirely in Web Components. So the tabs there are <sl-tab-group> elements.

Why is that good? Well, for one thing, it brings a component model to the party. That means, if you’re working on a component, it has a template and a stylesheet that are co-located. Peeking under the hood of Shoelace, you can see this is all based on Stencil.

Another reason it’s good is that it means components can (and they do) use the Shadow DOM. This offers a form of isolation that comes right from the web platform. For CSS folks like us, that means the styling for a tab in the tab component is done with a .tab class (hey, wow, cool) but it is isolated in that component. Even with that generic of a name, I can’t accidentally mess with some other component on the page that uses that generic class, nor is some other outside CSS going to mess with the guts here. The Shadow DOM is a sort of wall of safety that prevents styles from leaking out or seeping in.

I just saw the FAST framework¹ too, which is also a set of components. It has tabs that are defined as <fast-tabs>. That reminds me of another thing I like about the Web Components as a pattern library approach: if feels like it’s API-driven, even starting with the name of the component itself, which is literally what you use in the HTML. The attributes on that element can be entirely made up. It seems the emerging standard is that you don’t even have to data-* prefix the attributes that you also make up to control the component. So, if I were to make a tabs component, it might be <chris-tabs active-tab="lunch" variation="rounded">.

Perhaps the biggest player using Web Components for a pattern library is Ionic. Their tabs are <ion-tabs>, and you can use them without involving any other framework (although they do support Angular, React, and Vue in addition to their own Stencil). Ionic has made lots of strides with this Web Components stuff, most recently supporting Shadow Parts. Here’s Brandy Carney explaining the encapsulation again:

Shadow DOM is useful for preventing styles from leaking out of components and unintentionally applying to other elements. For example, we assign a .button class to our ion-button component. If an Ionic Framework user were to set the class .button on one of their own elements, it would inherit the Ionic button styles in past versions of the framework. Since ion-button is now a Shadow Web Component, this is no longer a problem.

However, due to this encapsulation, styles aren’t able to bleed into inner elements of a Shadow component either. This means that if a Shadow component renders elements inside of its shadow tree, a user isn’t able to target the inner element with their CSS.

The encapsulation is a good thing, but indeed it does make styling “harder” (on purpose). There is an important CSS concept to know: CSS custom properties penetrate the Shadow DOM. However, it was decided — and I think rightly so — that “variablizing” every single thing in a design system is not a smart way forward. Instead, they give each bit of HTML inside the Shadow DOM a part, like <div part="icon">, which then gives us the ability to “reach in from the outside” with CSS, like custom-component::part(icon) { }.

I think part-based styling hooks are mostly fine, and a smart way forward for pattern libraries like this, but I admit some part of it bugs me. The selectors don’t work how you’d expect. For example, you can’t conditionally select things. You also can’t select children or use the cascade. In other words, it’s just one-off, or like you’re reaching straight through a membrane with your hand. You can reach forward and either grab the thing or not, but you can’t do anything else at all.

Speaking of things that bug people, Andrea Giammarchi has a good point about the recent state of Web Components:

Every single library getting started, including mine, suggest we should import the library in order to define what [sic] supposed to be a “portable Custom Element”.

Google always suggests LitElement. Microsoft wants you to use FASTElement. Stencil has their own Component. hyperHTML has their own Component. Nobody is just using “raw” Web Components. It’s weird! What strikes me as the worst part about that is that Web Components are supposed to be this “native platform” thing meaning that we shouldn’t need to buy into some particular technology in order to use them. When we do, we’re just as locked to that as we would be if we just used React or whatever.

Andrea has some ideas in that article, including the use of some new and smaller library. I think what I’d like to see is a pattern library that just doesn’t use any library at all.

  1. FAST calls itself a “interface system,” then a “UI framework” in consecutive sentences on the homepage. Shoelaces calls itself a “library” but I’m calling it a “pattern library.” I find “design system” to be the most commonly used term to describe the concept, but often used more broadly than a specific technology. FAST uses that term in the code itself for the wrapper element that controls the theme. I’d say the terminology around all this stuff is far from settled.

The post A Bit on Web Component Libraries appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.