Building a Merchant Commerce Platform
Start with the primitives, not the dashboard.
Table of Contents[ 4 ]
The primitives Build the engine first Build surfaces second Design for extensionA merchant platform can look simple from the outside. A merchant sees products, orders, customers and transactions.
Underneath, however, those objects are deeply connected. A good architecture starts by defining those relationships.
The primitives
A product needs identity, pricing, availability, media, variants and metadata.
A customer needs identity, contact information, history, segmentation and relationships.
An order connects customer, products, pricing, payment and fulfilment.
A transaction records the financial event associated with commerce.
These primitives become the foundation for every surface.
Build the engine first
The commerce engine should sit underneath the website, the merchant console, point of sale, payment links and the APIs.
Every surface should consume the same underlying commerce system. That is how you avoid creating separate systems for every channel.
Build surfaces second
Once the primitives exist, experiences can be composed around them.
A merchant console might expose products, orders, customers, payments and analytics. A website might expose products, cart, checkout and orders. A point-of-sale system might expose products, cart, checkout and payment.
Different experiences. Same infrastructure.
Design for extension
Commerce changes. A platform that supports products and orders today may need subscriptions, loyalty, bookings, membership, gift cards, reviews and digital goods.
The architecture should make those additions possible without rebuilding the core. That is where packages and APIs become important.
