Appearance
E-commerce flow
One flow from the shop listing to a placed order: browse, open a product, set a quantity, check out, pay. It is the commerce counterpart to the authentication flows — same player, same idea, and each step names the call it makes and what the server does with it.
The three pages under this section go deeper on one leg each. This page is the whole journey in order.
Play the flow
Two paths: a signed-in shopper, and one who tapped skip for now on the landing screen. They diverge more than the screens suggest — a guest calls the open twin of half these endpoints and places the order through a different one entirely.
4:4713
what are you looking for?
750 ◉
Sample Pack$15.00
500 ◉
Single Tin$10.00
500 ◉
Refill Pouch$10.00
Sold Out1750 ◉
Gift Boxnotify Me
Space plays and pauses, ← and → step. The "place order" screen is drawn from what the flow requires — it has no design yet, and the player says so.
What carries this flow
Three facts explain most of the step list, and each one is the opposite of what the screens imply:
syncBagis the entire cart. Not a line-item endpoint — you send the whole bag and get totals, taxes and applied discounts back. "Increase quantity" is a re-price of everything. Detail in the purchase flow.- There is no "get cart" call. The cart the app draws is whatever the last
syncBagresponse said, which is also where the badge count comes from. - The order exists before the money does.
createOrderruns on confirm & go to payment, and the payment step takes itsorderId. What state that order is in if the shopper abandons payment is an open question.
Where each leg is documented
| Leg | Page | What it adds |
|---|---|---|
| Listing, search, filters | Shop listing | The two search engines, the two filter vocabularies, and why stock depends on the token |
| Product page, cart, shipping | Purchase | The full syncBag contract, guest checkout, and the address field mapping |
| Payment | Payment | The hosted card link, and the two buttons with no endpoint behind them |
| Every endpoint by hand | Cart, discounts, orders and payments | Field lists, and a console to call each one |
Two screens the API does not back
The payment screen draws a your wallet button and a points entry beside the totals. Neither works the way the screen implies:
- No endpoint in the mobile set exposes a spendable wallet balance. Three different things in Batch answer to "wallet", and the payment flow sets out which one this probably means.
- Points are spent through the cart —
pointsonsyncBagand oncreateOrder, withpoints_sourceper line — so by the time the payment page is on screen, the points decision has already been priced in.