Most commerce platforms make you choose. Sell physical goods, plug in a subscriptions app. Sell services, plug in a booking app. Sell credits, write your own admin script. Run a second storefront, keep a second catalog.
Four plugins, four checkouts, four places for a sale to go missing.
The catalog was never a database
Until this week, a product in ONE’s catalog was a fixed list. No filter. No saved view. No board by status. Every other type in the system — tasks, contacts, deals — got that database for free. Products didn’t, because commerce ran through its own tables and its own everything.
So we gave it the database.
products and order now opt into the same views rail as every other type: filter rail, saved-view tabs, a board grouped by status. One binding flag — views: true — replaces five separate hardcoded gates in the admin. The view-switcher now reads from the one registry every other type already reads from, instead of a second hand-written list.
Owners see their draft products for the first time too. And customers stopped being an empty generic table and became what it always should have been: a live read of who bought what, grouped straight off the orders table.
One checkout, not two
Credits used to mint from a bare admin script — a human, a number, a grant call, no receipt trail worth the name. Now a credits pack is a product like any other: priced, listed, sold through the same checkout as a t-shirt. Buying one doesn’t create credits out of nothing. It debits the seller’s own balance and credits the buyer’s, through the same acceptPayment spine every settled payment on ONE already runs through. At mint time, we check the seller can actually cover it. Replay the webhook twice, the second one grants nothing.
Bookings had their own checkout too — a standalone Stripe payment, wired straight into the calendar, invisible to every other report in the system. A paid booking didn’t show up in orders. Didn’t show up in sales. Didn’t show up if you asked chat what sold this week, because as far as chat was concerned, it hadn’t. Bookings now pay through the exact same storefront checkout the shop uses, card or crypto, same as any other sale.
Baymard Institute measured average e-commerce cart abandonment at 70.19% in 2024 — most of it checkout friction, not price. Every extra checkout path is one more place to lose a sale. We didn’t add a fifth. We deleted the fourth.
We test money like it’s money
The wallet-shop — the zero-signup, crypto-only storefront at /w/shop — used to be a dead end. Build a product there without an account and it lives in your browser’s local storage until you close the tab. Sign in now and a “Publish to your storefront” button pushes it into the real catalog, through the same receiver every other product goes through.
None of this shipped on faith. While building the booking payment path, our own verification caught something worse than a missing feature: the booking ID was defined in the payment data but never actually reached the checkout call. A booking would have charged the card and never confirmed the slot. Caught in the same build, fixed, tested against the actual wire, not just the function that looked right on its own.
Separately, the customer rollup nearly shipped against the wrong column. A privacy migration had already moved customer email into a sealed vault, months after the original design was written. The build caught the drift and grouped by the sealed ID instead.
The receipts
- Five cycles, zero new payment engines. Everything above composes four things that already existed: the views rail,
acceptPayment, the storefront checkout, the binding registry. - New type errors introduced: zero, across all five cycles.
- 33 files changed. 1,511 lines added, 281 removed.
- The promise behind this work — fifteen checkable deliverables — re-ran its own proof after every cycle and settled kept.
And the honest line, because there always is one: the crypto rail for credits packs isn’t wired yet. The minter refuses a credits product outright rather than ship a half-built claim flow. Card only, for now.
One catalog. One checkout. One ledger.
Shopify sells you a storefront and a plugin marketplace to fill the gaps. ONE grew the gaps shut instead — same database, same payment spine, same chat that already runs your business.