Marketplaces in OrderCloud

Suggest an edit
Todd Menier

Published by Todd Menier

April 2nd, 2021

Organizations, their relationships with one another, and how those relationships affect order flow have always been core tenets of OrderCloud. As these features continue to evolve, let's take a look at where we started, where we are now, and where we're headed.

In the Beginning

When OrderCloud first launched, it aimed to solve one specific problem: enabling a merchant to set up shop and receive orders from one or more buyer organizations. In this model, that single merchant is king: they own and manage everything, from product catalogs to buyer organizations to application concerns like API clients and webhooks. They also recive and fulfill all orders. This model proved effective for both B2B (multi-buyer) and B2C (single "buyer" as a container for consumer users) scenarios.

Single Seller Multiple Buyer Order Flow

Enter Suppliers

In some scenarios, the merchant is a pure sales organization that doesn’t actually fulfill the orders they receive. They own customer accounts and provide eCommerce and other services, but separate supplier organizations fulfill the physical product. OrderCloud has evolved to accommodate suppliers as a distict organization type with indirect fulfillment capabilities. Suppliers can own products and catalogs and, perhaps most notably, receive purchase orders containing line items forwarded from end-buyer sales orders.

Single Seller Connecting Multiple Buyer and Suppliers Order Flow

Toward Marketplaces

Now that we support networks consisting of a sales organization, multiple buyers, and multiple suppliers, we’re poised to handle additional scenarios common to marketplaces. If you want to implement an Amazon.com-like model where all orders flow to a single entity (Amazon in this analogy) but other entities may handle the actual fulfillment, this is a perfect fit. But we’re increasingly encountering scenarios where the relationship between buyers and end fulfillers is more transparent. In other words, buyers need to be able to order from multiple merchants directly.

Rearchitect or Repurpose?

When we looked at our current model and imagined what would happen if there were multiple sales organizations in a single environment, things got messy quickly. Even in a decentralized marketplace with lots of buyers and sellers transacting directly, the need for a single entity to own and operate the marketplace as a whole still exists. After all, somebody built (or bought) an application that runs on top of OrderCloud, and they’re going to want to maintain sole control of it.

Our next idea was to define a new organization “type” that would be sort of light-weight sales organization that can own product catalogs and receive buyer orders but does not own or operate the marketplace itself. That could work, but is another rigidly defined org type really necessary?

As it turns out, a better answer was right in front of us, and it was mostly built already. We already have an entity that can fulfill orders, create products, and whose access to the marketplace is more or less limited to the things they own: suppliers. Direct relationships between buyers and suppliers in terms of visibility and order flow is all that was missing. This is not only simpler than adding a new org type, it’s also more flexible. Could the same organization take orders directly from a buyer and indirectly fulfill orders for another merchant? Sure! Could a supplier create and manage their own buyers? Why not!

Rethinking "The Seller"

Back to that singular controlling entity. Traditionally, we've simply called this organization "The Seller". But in a world where multiple suppliers are selling directly to end buyers, this no longer makes sense. This organization might not even participate in commerce at all; it could be a pure technology/application provider inviting independent merchants to join their marketplace, and to bring their own products and even customers. So we're making a shift toward calling this singular entity the “Marketplace Owner” (or MPO) instead. They may or may not sell, and they may or may not fulfill. But they can see and control everything in the entire marketplace.

MPO Order Flow

The Rules of Ownership

In a marketplace where a single entity doesn’t necessarily “own” everything, the rules around who can see and edit what become a bit more complicated. So we’re establishing some rules that will generally apply to anything that can be created/owned:

  1. Any organization (given the proper roles) can create and “own” things such as products, catalogs, and even buyer organizations.
  2. Exactly one organization owns the marketplace. They are omniscient, i.e. they can view and edit virtually anything in the marketplace.
  3. Permission to view/edit things follows a hierarchical ownership structure. For example, a supplier creates a buyer. An administrative user within that buyer organization creates a shared address. Technically 3 different organizations could (with the proper roles) see and edit that address: the buyer, the supplier who owns them, and the MPO.
  4. Ownership can be transferred from one organization to another, but only by the MPO.

When is this coming?

Soon! In recent months we’ve released the ability for suppliers to own things like products, catalogs, and shipments. Direct relationships between suppliers and buyers, including direct order flow, is well underway. Stay tuned for details!