Skip to content
Ecommerce Platform

Ecommerce Platform

Andi Lamprecht Andi Lamprecht ·· 6 min read· Accepted
ADR-0066 · Author: Sybil Melton · Date: 2025-02-07 · Products: hubops
Originally ADR-0015-ECOMMERCE-PLATFORM (v6) · Source on Confluence ↗

Title

Context

DroneUp needs an ecommerce platform to serve as the backend for our mobile app. This backend must support the following:

  1. Ability to view multiple stores at once
  2. payments
  3. product filtering
  4. must integrate with our delivery api and compliance checks
  5. timely delivery of solution

other decision drivers:

  1. We have to be careful when using open source solutions, as certain clients have requirements around the license types and open source software used
  2. A SaaS solution is preferable so that we can “run less software”

Decision

Use Elastic Path as a headless ecommerce platform

Elastic Path meets the required criteria:

  1. Elastic Path supports multi-store either by having multiple catalogs or setting up multiple stores and assigning users to all stores
  2. Elastic Path integrates with stripe as a payment platform
  3. Elastic Path has a robust product listing/filtering system
  4. Integration path has been mapped out in this ADR
  5. By using an existing ecommerce platform, we save ourselves quite a lot of work and maintenance and can deliver much faster

Consequences

Elastic Path will be used in the following way:

The mobile commerce UI will send all traffic through the Mobile Commerce API (MC API) in order to limit the amount of connections and authentication that the frontend will have to manage. When no custom flow is required, the MC API will proxy that traffic to Elastic Path. The following scenarios will require a custom flow within the mobile commerce api:

  1. Adding an Item to the Cart

7073e1ff0599a57762b421f9d7035fdc-add-item-to-cart.png

This flow requires us to run cart validation before adding an item to the cart. This is so that we can ensure that the item being added to the cart does not exceed total weight or dimensions for the entire delivery. Anytime an item will be added to the cart, instead of proxying that call outright, the MC API will first invoke the inventory service for cart validation (would this cart be valid if this new item were in it?).

  1. Checkout

4b613cd4448408e7ce090f9c88c52dc0-checkout.png

The checkout action is what creates an order inside of Elastic Path. However, before creating the order in Elastic Path, we must run our temporal checks by creating a soft reservation via the /reservation endpoint. After those pass and the order has been created in Elastic Path, we must store a lookup of Elastic Path order Id to droneUp ReservationId. This lookup will be stored in a cloud sql database. We need a persistant storage system that is highly reliable since this lookup is necessary for order creation later in the process.

  1. Payment and DroneUp Order Creation

f47a8ff0da330acc73a792c8b8f05bf9-payment-and-order.png

The user will issue payment using the Elastic Path payment. Once the payment is issued, Elastic Path will emit an order.paid event. This event will be consumed by an endpoint in the mobile commerce api. This is the key for us to create the order in our system via the delivery api. We will need to use the lookup table created as part of the Checkout process in order to get the correct reservationId for the Elastic Path order that has been paid. Once the order has been created in DroneUp’s system, we will need to save a lookup of Elastic Path orderId to droneUp OrderId.

  1. Order Complete

6013e808c5c37ad0aabdacec85f46482-order-complete.png

When the order is completed, we need to mark the order as fulfilled inside of Elastic Path. To do this, the MC API will listen for the delivery completed event. When it receives this event, it will use the lookup table created as part of the order creation process to lookup the Elastic Path orderId. It will then use this Id to mark the order fulfilled.

  1. Populate Product Data

99ae89cbb0f1083746b620093c7f87f7-populate-product-data.pngf6398a65d0dc2ed9b410b9abcd36d5e7-update-delete-product-data.png

When populating product data inside of Elastic Path, we must first run it through the CPV review process. Vendor data will be ingested by the MC API, then run through the cpv review process. The output of that process will then be used to create/update/delete product data as needed. The first step is to determine if the cpv review process is issuing a removal, update or an addition (the exact nature of this decision is out of scope).

5a. add process - check the GTIN to Elastic Path product Id database. If the item is already there, then there is nothing to do. If not, we must create the product in Elastic Path and then save the product Id to GTIN lookup in the lookup table

5b. remove process - check the GTIN to Elastic Path product Id database. Remove the product by Elastic Path product Id. Once that has been removed, remove the GTIN to product Id lookup record for that GTIN

5c. update process - update the item based on the GTIN to productId lookup table

Out of Scope

  1. CPV review process
  2. Authentication
  3. Payment Process
  4. Vendor data ingestion

Alternatives Considered

Building our own ecommerce platform - Too long of a timeline and not a core business function for us

Using other ecommerce platforms:

Fabric - Met and they said not a fit

Magento (Adobe) - Used Magento and would be hard to make multi-store/multi-vendor without a lot of additional work

Spree Commerce - Open source - good contender, but Ruby and no support and we’d have to build a team to support it

Vendo - Authors of Spree who set up their own company

SAP - too complicated and would be a whole ERP rollout and may not play nicely with our ERP

Salesforce - built on before, but would be costly and likely a large lift

Shopify - Solid APIs and possibility to do multi-store, but limited PIM would mean we’d be heavily reliant on CPV to drive all of this - path to “now” was longer

BigCommerce - They were a contender from before and said they couldn’t. Reached out to see if that changed and it had not

CommerceTools - In progress, but setting up the demo was challenging and didn’t work at first… so likely - NO

Spryker - Limited research here. Need to dig into into it more, but didn’t see evidence of a pathway to multi-store/multi-vendor so pushed to back burner.

Swell - Examined this and passed due to multi-store/multi-vendor complexity

OroCommerce - Reached out to them a week ago and haven’t heard back from them so likely - NO

Nacelle - Looked promising, but was pretty prescriptive on the front end tech and likely needs another CMS to go with it.

Last updated on