Welcome to Ollie Shop! We are a headless checkout solution that allows merchants to fully customize their checkout experience without compromising performance.

Use Ollie Shop to build multiple user journeys and find the best-converting checkout experience for each user. Leverage our infrastructure to host your custom checkout or use our APIs in a true headless fashion to power your self-hosted application.

Whatever avenue you chose, you'll be able to (re)use your Functions from any application.

Ollie Shop Overview

It's common for e-commerce platforms to have a more strict checkout, not allowing merchants to fully customize them. This is understandable, the original purpose is to help prevent badly implemented code to break the purchase flow and stop orders from being placed.

However, we believe that instead of controlling what merchants can do, we should empower them. In the last 10 years, the entire ecommerce ecosystem has evolved its tech skills. It is about time that merchants can have full control of the experience they wish to provide their customers with.

We propose to invert the concept of a controlled interface. With Ollie Shop, merchants are finally free to build multiple experiences. To achieve this we have completely decoupled the interface layer. We created a dedicated back-end application to run customizations server-side. The users will interact with your UI and the UI components can be developed more generically. The component interaction is with a simpler API (we provide REST APIs and an SDK). The functions are where the manipulation of data happens, these are triggered by events, giving extreme control on when to run each customization.

Organization, Stores and Versions

Organizations

The Organization is the highest entity for a user/store within Ollie Shop. The purpose of the Organization is to function as an umbrella artifact for other resources.

For instance, let's consider a big retail company called Acme Retail.

Acme has two online stores (different brands): one for appliances and another one for grocery. They use different e-commerce platforms for each one and wish to use Ollie Shop as their checkout solution.

Acme Retail will be able to have multiple stores under its organization and have users assigned to each store. As if an organization was to reflect a holding company.

Stores

The store is the representation of a Brand. A store has its own set of configurations, being the main one the e-commerce platform and its identifier (name/brand) which allows Ollie Shop to connect the checkout with the website, requesting the right APIs and properly handling the checkout flow.

As explained above, an organization can have multiple stores.

Going back to the Acme Retail example. Acme Retail Organization will have two stores within Ollie Shop: one for appliances, called "Eletro" and another one for grocery, called "Super".

Important to note that users can be constrained to Stores, meaning their access can be specific to a store.

Versions

The version is the materialization of the checkout page and it allows clients to have more than one version of their checkout, whether for AB testing, multiple customer journeys, navigation segmentation, or simply operating as a draft.

Our intention is for each store to have as many versions as it wants, each one with its template and props to customize the look and feel of their checkouts. The objective is to have a great variety of checkout templates with specific themes and features to provide the best experience for the user.

The templates are developed using Nextjs. It was chosen because of its maturity and completeness of first-party features and its development ecosystem, which allows Ul's with high standards of quality. It also offers great web performance, allowing to send less javascript code to the user's browser, improving performance and stability.

Functions

Functions are the core of the Ollie Shop application. It enables merchants to reach the full potential of their e-commerce platforms and even exceed them.

Functions are designed to work on top of any platform by extending its native features to implement complex business rules.

All business rules (custom code) are applied directly in the back-end, creating a separation between UI components and the commerce engine.

Going back to Acme Retail example and its store "Eletro", let's consider the following customization requirement:

Like most stores in ecommerce, the Eletro store wishes to offer an up-sell in their checkout for Services, such as Assembly of a product, or Warranty.

While "services" can be a native feature of ecomm platforms, Eletro Store has a specific requirement where it wishes to dynamically calculate the value of this service, meaning that there is an external engine responsible for this action.

Using Ollie Shop, they can register a function that will run when triggered by "add cart item" event.

This function will:

1. check if the user added the product that is marked as a serviceable product,
2. intercepts this request before sending it to the ecomm cart
3. make the external request using the cart data
4. based on a successful response, change the value for the service for that specific product

Components

If we have the functions as the core feature for composability, we also have a way to address the communication of the Ul with the server, providing an easy and decoupled way to customize user journeys and business rules. In summary, the Ul interacts directly with the Ollie APIs but without handling the complexity of the business rules. The Ul performs the native operations for any checkout such as: changing item quantity, customer profile input, delivery type selection, and so on.

The UI is only responsible for sending the action to the server and letting it resolve the requests and answer with the updated cart.