Hanzo Commerce
Products, carts, checkout, orders and returns behind an API, with no storefront attached. You write the front end; this keeps the catalogue, takes the payment and remembers what happened. Card numbers are tokenized somewhere else, so the store never holds one.
What it keeps track of
The nouns a shop is made of, each one addressable and none of them assuming what your site looks like.
Carts
A cart is a real object with its own id, so someone can leave and come back, and you can look at what they left in it.
Products and variants
A product holds the description; a variant holds the size, the colour and the price. Stock is tracked on the variant, which is the thing people actually buy.
Authorize and capture
Two steps, not one. Hold the money when the order is placed and take it when the box ships, which is what your accountant and your customer both expect.
Coupons and discounts
Applied to a cart or to an invoice, and recorded as their own line. The reason a total came out lower survives the transaction.
Prices per store
One catalogue can answer differently for different stores. The product does not have to be duplicated to be priced twice.
Subscriptions
Plans, prices and renewals sit in the same service as the orders, so a customer who buys once and subscribes once is one customer with one history.
Orders, refunds and returns
The whole life of an order, including the parts nobody demos. A return is a first-class object rather than a note in a support ticket.
Many stores, one install
Stores are scoped by organisation, so an agency or a marketplace runs several without running several copies of this.
It never sees a card
Card numbers are tokenized in a separate service and this one only ever holds the token. That is a smaller thing to secure, and a much smaller thing to be audited on.
Your data, per tenant
Each organisation's records live in its own store. Isolation is a file boundary rather than a WHERE clause somebody has to remember to write.
The endpoints
Grouped by what they are about. Every one of them is scoped to your organisation by the token you call with, so multi-tenancy is not something you implement on top.
Hanzo Commerce API Endpoints
List all carts for the current session/user
Get details for a specific cart
Update cart items and quantities
Remove a cart
Capture payment for a previously authorized checkout
Process a direct checkout charge
Authorize payment for later capture
Get a specific product collection
List all product collections
List all available coupons
Get details for a specific coupon
List all available discounts
Get details for a specific discount
Get a specific order
List all orders
Process a refund for an order
View payment details for an order
Capture payment for a previously authorized order
List all products
Get a specific product
Get details for a specific return
List all returns
List all product reviews
Get a specific product review
Get a specific store
List all stores
Deploy a site/storefront
Get a specific product in a store
Get a specific variant in a store
Get a specific product variant
List all product variants
When to reach for it
Four shapes that fit. If none of them is yours, a hosted shop is probably the easier answer.
A storefront you designed
You have a front end you like and do not want a theme system telling you how it works. This gives you the catalogue, the cart and the checkout as calls, and stays out of the rendering.
One catalogue, several stores
A brand with regional shops, or an agency running stores for clients. Stores are scoped by organisation and can price the same product differently.
Selling a subscription and a thing
Hardware with a plan, or a course with a membership. Orders and subscriptions are in one service, so the customer has one history rather than two accounts.
Taking payment inside your own product
You are not building a shop, you are charging for what you already made. Use the checkout, the invoices and the meters, and ignore the rest.
Who takes the money
The processor is a setting, not an architecture. Each one gets its own webhook endpoint, so adding a second — or leaving the first — is a change here rather than a change in your checkout.
Payment Gateways
- Stripe
- PayPal
- Adyen
- Square
- Braintree
- Klarna
- Affirm
- Apple Pay
Marketing & CRM
- Mailchimp
- Klaviyo
- HubSpot
- Salesforce
- Segment
- Meta Pixel
- Google Analytics
- Customer.io
Shipping & Fulfillment
- ShipStation
- ShipBob
- EasyPost
- FedEx
- UPS
- USPS
- DHL
- AfterShip
Accounting & ERP
- QuickBooks
- Xero
- NetSuite
- SAP
- Avalara
- TaxJar
- Sage
- Microsoft Dynamics
What you are running
Worth knowing before you put your revenue behind it.
One Go binary
A single container with no queue, no cache tier and no companion services to stand up beside it. Run it locally the same way it runs in production.
A store per organisation
Tenants are separated by where their data lives rather than by a column, so one tenant's query cannot reach another's rows.
Outside the card boundary
Card numbers are tokenized by a separate service. This one is connected to that boundary without being inside it, which is the whole point of drawing one.
Identity from Hanzo IAM
Sign-in, organisations and tokens come from IAM. There is no second user table here to fall out of step with the first.
Mounts into the cloud binary
It runs on its own or as a subsystem inside the unified Hanzo Cloud binary. Same code, same routes, one fewer process to operate.
Open source
MIT or Apache-2.0, your choice. Read how your money is handled instead of taking our word for it.
Create a product, then sell it
The whole thing runs from one container. Point your front end at it and take an order.
Need a Custom Solution?
Our team of experts can help you design and implement a tailored e-commerce solution for your unique business needs.