Ecommerce Platform
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:
- Ability to view multiple stores at once
- payments
- product filtering
- must integrate with our delivery api and compliance checks
- timely delivery of solution
other decision drivers:
- We have to be careful when using open source solutions, as certain clients have requirements around the license types and open source software used
- 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:
- Elastic Path supports multi-store either by having multiple catalogs or setting up multiple stores and assigning users to all stores
- Elastic Path integrates with stripe as a payment platform
- Elastic Path has a robust product listing/filtering system
- Integration path has been mapped out in this ADR
- 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:
- Adding an Item to the Cart

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?).
- Checkout

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.
- Payment and DroneUp Order Creation

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.
- Order Complete

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.
- Populate Product Data


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
- CPV review process
- Authentication
- Payment Process
- 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.