With OrderCloud, a developer can create and submit an order with less than ten lines of code. While this section walks through the individual steps for you to leverage in crafting an online store, you can orchestrate this process without user interaction as part of automated fulfillment or integrations.
As you read below, you’ll see that OrderCloud has quite a few extension points and steps you can integrate your own experience. Customers have done simple B2C experiences, loyalty websites where payment is only in points for products, and B2B marketplaces with dozens of suppliers fulfilling orders. We challenge you to bring a fulfillment model that OrderCloud can’t support.
Because OrderCloud is set up to support marketplaces with a mix of buyers and suppliers, the platform has the concept of incoming and outgoing orders, depending on who is interacting with the order. We refer to this as Order Direction and it can be confusing to understand at first, but a critical underpinning to expand your ability to leverage a broader marketplace strategy with OrderCloud.
Secondly, as part of the order lifecycle, OrderCloud supports multiple statuses with individual timestamps of when the status changed. Some implementations may find it useful to extend to other statuses specific to operating their marketplaces.
While most commerce solutions built on OrderCloud may only use the interaction between the Buyer and Seller (you), OrderCloud also supports interacting with multiple Suppliers as a broader marketplace.
This is also part of OrderCloud’s robust security in supporting lots of different ‘users’ in order lifecycle management. The platform will take care of making sure only the right orders are visible based on the credentials used to access OrderCloud’s APIs.
To walk through a basic example, a buyer creates a new order with the ID of
Buyer credentials from your website access their order via the API call:
Seller credentials which administer your website would access the same order from the API call:
The same concept applies when dealing with orders from the seller (you) to the supplier, and that will be covered in the section on Order Fulfillment.
Within OrderCloud, orders flow through various statuses, some are automatically handled for you based on coordinating other order updates, such as tracking which shipments have been applied to the order.
|Unsubmitted||When the order is first created||Essentially the same as a ‘cart’ in any other commerce platform.|
|Open||When an order is submitted||After going through checkout and the user submits the order, it’s now in an open status|
|Awaiting Approval (Optional)||Submitted, but one or more rules must be approved first||Mainly for B2B solutions and the optional use of approval rules within OrderCloud|
|Declined (Optional)||When an approver declines the order||Mainly for B2B solutions, an approver can decline the order|
|Completed||Submitted and all lines and quantities have been shipped||OrderCloud automatically updates this status as part of shipping updates|
|Canceled||Manually set to close and lock the order from any other modification||Essentially the same as a soft delete to keep the order in the system, but treat it as deleted|
With each of these statuses, the order has supplementary fields to record when the status changed. These timestamps and statuses can be used to query orders from the system, including providing user experiences with tabbed or filterable views over all their orders by status.
For example, you (the seller) wants to find all unsubmitted orders (carts) created before a specific date, sorted by most recently created:
For sake of simplicity, the aspect of approvals is left out in this flow.
For both anonymous and logged in users, OrderCloud can support building an order with basic API calls, either directly from the front end experience (browser) or as orchestrated through your own middleware for greater control.
As with all areas of OrderCloud, you can store any custom data you choose at the order or order line data. Examples might be capturing additional user-entered information such as GL codes, comments, or inventory locations.
OrderCloud provides integration capabilities that allow you to plug in your own fulfillment and shipping logic from 3rd party services or driven by your own warehouse or ERP systems. This flexibility will drive greater customer stickiness and the ability to evolve as new opportunities for fulfillment arise.
Because you own this integration, you can customize applicable costs and adjustments to what fulfillment or shipping options you offer to which customers and what channels-- such as private fleet options for B2B customers and standard UPS for consumer channels.
This is an optional integration you can use. Building an order can be very dynamic, sometimes adding multiple lines at once or importing dozens of order lines from a device or file. To make your order processing efficient, you initiate calling the order calculate to re-process pricing, promotions, and taxes only when you need to. This can be after each line added or updated asynchronously depending on the experience you need to provide to users.
You can provide your own tax logic, and override line item totals, shipping, and promotions with this optional integration event.
OrderCloud has built-in support for referencing cost centers, credit cards, and spending accounts. These can be associated with individual users, user groups, or buyers to use as part of purchasing.
For any given order, you can apply one or more payments, such as a gift card, and cover the rest with a credit card or plugging in your own interpretations of various payment types.
Payments can also store transactions underneath them to track subsequent ledger changes or events related to that payment. For credit cards, you can track the original authorization amount, along with fund capture events. If you need to then credit funds, you can leverage the transaction model on the original payment to manage and track this.
As part of order submission, we will validate the state of the order. Applying custom order validation is completely do-able which is covered in the next section.
Out of the box, OrderCloud will validate for the following:
Once the order is submitted, you can pull the orders into your fulfillment system and/or split them automatically across multiple suppliers. The aspect of downstream order synchronization is in a later section.
Once an order is submitted through the checkout process by the buyer, you (as the seller) can update the status of the order or incorporate separate suppliers into the fulfillment process directly. To learn about what happens before order submission, read the Checkout Process section above.
Before we get into scenarios on who can do the shipment updates on the order, the idea of shipments in OrderCloud is pretty simple and handles most use cases:
Shipment is a concept that can be used for other fulfillment methods, some customers have used this to note in-store pick up options and utilized OrderCloud’s extensible properties (XP) to store other metadata to craft any fulfillment experience necessary.
Once all lines for all quantities have associated shipments with a shipment date populated, OrderCloud will move the status of the order to completed for you automatically.
As covered in a previous section on Estimate Shipping, OrderCloud can provide any number of ways to communicate shipment options to the buyer at checkout. This could’ve been to pick a fulfillment method for the whole order, per order line, or per supplier.
This shipment preference data is stored with the original buyer order and can be accessed through OrderCloud APIs. Depending on if you choose to do basic commerce or are setting up a more complex marketplace on OrderCloud, you can dictate what and how that buyer preference is communicated.
OrderCloud can handle basic commerce scenarios that other platforms support. The seller (you) may have systems in place, most likely an order management system (OMS) or enterprise resource planning system (ERP) such as NetSuite or SAP where your distribution and financials are centrally managed. You simply want the order to land in your system to manage from there.
For more complex commerce and marketplace setups, you may want OrderCloud to split up the order for you across multiple suppliers or systems. OrderCloud refers to this as supplier forwarding.
The supplier concept in OrderCloud is just another layer you can distribute or break up an order to be managed through fulfillment. The use of suppliers is optional, but some ideas for you to consider:
There’s nothing stopping you from using the concept of a supplier to represent all of the above scenarios in parallel to manage your marketplace.
While the below diagram is quite complex, the intention is to show what OrderCloud can manage by taking a single order from the buyer and managing multiple supplier-specific orders, and relating status updates back to the original buyer order for you.
While OrderCloud provides out of the box order capture and validation, this section covers topics that require external integrations through deployed services to augment and customize the use of OrderCloud for your business.
Example use cases for connecting your own logic:
For any domain object in OrderCloud, you can intercept API calls to validate or modify the data submitted. There are two ways to apply your own logic to any data changes or user input through APIs, may it be validating a newly created address or changing the details of a line item.
Additionally, these ideas can be used to also replicated data, real-time into other (cloud) services and solutions.
Webhooks are configured within OrderCloud directly. They allow any interaction with OrderCloud to first call out to another service you own to validate or manipulate the request before any change is applied to an order, address, line item, user, etc.
Webhooks work over HTTPS and are language agnostic. This means you can implement your logic in any language of choice and preferably deploy them as serverless functions in the cloud.
More complex solutions may have most of their website interactions first route through their own middleware or controllers. That middleware, in turn, makes calls to OrderCloud. This is very similar to employing WebHooks but is another option to consider depending on your architecture.
A more common application of middleware is if you want to publish your own service which aggregates multiple calls into one service-- primarily complex ‘GET’ scenarios to produce net new object types for your clients to use.
In both cases, it is recommended to leverage OrderCloud’s robust security architecture versus rolling your own. OrderCloud handles the roles of buyers, admins, and suppliers, along with data rights authorization. Again, you can choose to implement your services in any language of choice.
While the previous two sections with webhooks and middleware proxies covered how to intercept and augment OrderCloud through direct API calls, Integration Events work on the same premise but are initiated indirectly due to coordinating things like order checkout and also includes more robust information in the request and response lifecycle. Think of this as pointing OrderCloud to your own middleware services to own the logic of order intake.
For checkout, integration events from OrderCloud to gather specific information from your own API endpoints:
In all cases above, the message passed is what is called the ‘OrderWorksheet’ which is the order, lines, and additional metadata captured as part of these event calls (estimated shipping data, order calculate data, etc).
OrderCloud is set up to be your single platform for all commerce operations, including supporting multiple website experiences and customizations per channel. An example might be one set of complex, order validation for B2B buyers in one web experience while applying a different set of logic for orders coming from B2C consumers on another web experience-- all managed from one OrderCloud instance.
API Clients represent a specific channel that connects to OrderCloud. For the following extension points, here’s how to consider managing custom logic per channel:
For distributed systems, once the order is created within OrderCloud, you may be wondering how to get that order into other systems downstream. As covered in Order Fulfillment, the orders can be passed or accessed by just you (the seller) or providing direct access to individual suppliers.
This is the preferred method. By using Integration Events, you can receive the order after it’s been processed by OrderCloud, and the message includes a lot of additional metadata related to the checkout process you may want to use and store in your downstream systems. Specifically, you would want Order Submit and if you’re using approvals, to monitor the Order Approved endpoint also. See the above section on Integration Events.
As covered in the previous section, a common solution is to employ webhooks to intercept the order submission and create a copy into one or more systems or databases for processing. See the above section on webhooks.
Another approach is to leverage the list and filter APIs to query for submitted orders and apply your own flags or updates back on the order to indicate that it’s been replicated, along with any other downstream system identifiers needed for lookup.
(Incoming and Outgoing Orders are covered under Order Lifecycle)
Query orders by most recently submitted, where you haven’t marked them as downloaded yet:
Once you have the list of orders, you can make any supplementary API calls to pull lines or buyer information associated with the order, finally then updating the order back to OrderCloud that you’ve completed downloading it:
Your implementation may end up using a combination of solutions to leverage both real-time and an intermittent batch pass before order cut off to catch anything which may have fallen out of your system SLA.