The Shop Is a System Before It Is a Store

A shirt on a screen looks like a simple thing to sell. Give it a photograph, a name, a price, and a button. The complicated part seems to be getting someone to press the button.

But the button is where a collection of promises becomes an obligation. Which shirt did the buyer choose? What did it cost? Was that size available? How will it reach them? What happens if payment finishes after the browser closes?

Those questions are the less photogenic part of building theProject. Shop. They are also the part that decides whether the photograph can be trusted.

The okayhacker apparel showcase gives the identity a physical direction: shirts and hoodies in a small lineup. It is identity artwork, not evidence that every pictured garment has been manufactured or stocked. The distinction matters before a single price is entered.

One image does not make five products

An apparel composition can show how an identity behaves across shapes and colors. It can make a release feel coherent. It cannot tell us which combinations are actually available.

A crop of the green hoodie is still a crop of the same showcase. It is not a separate product photograph, and it should not be captioned as one. A convincing picture does not establish sizes, materials, stock, or delivery dates.

A product record has a different job. It describes something the business can supply under stated terms. It needs its own name and description, its purchasable options, and a price attached to each option. The editorial image introduces the line; the record carries the offer.

That separation lets us enjoy the visual work without making inventory up to fill a page.

The option is part of the object

A buyer does not order “a hoodie” in the abstract. They choose an available combination, such as a size and color. In the Shop’s underlying records, that combination is a variant.

The word sounds technical, but the idea is ordinary. Each variant needs a label a buyer can understand and an internal identifier that stays stable. It can have its own price and availability. An inactive option should not quietly remain purchasable because somebody kept an old browser tab open.

This is why the final check belongs on the server. The browser sends the product, option, and quantity requested. The backend reads the current record before creating checkout. The price printed on the visitor’s screen is information, not permission to invent a total.

A catalog should belong to the operator

The person running a shop should be able to enter a release without editing a source file. They should also be able to understand what the fields mean without reverse-engineering the payment code.

Our catalog lives in Studio, using the existing Payload content system. The public website reads a narrower version of the product record. Draft products stay out of the public register. Descriptions, media, options, and fulfillment notes can be edited where the other business content is managed.

The field descriptions matter. A price stored in cents needs to say that plainly. An inventory number needs to explain whether it means total allocation or remaining stock. A technically correct form can still be an operational trap if its labels invite the wrong interpretation.

Inventory is a promise about time

Two people can look at the same available item before either has paid. A page refresh is not enough to coordinate them.

The commerce foundation accounts for current checkout reservations as well as completed purchases. A reservation has a time limit. If checkout expires, the hold should stop consuming availability without relying on someone remembering to clean up a record at exactly the right moment.

For manually tracked products, the current implementation uses a stock ceiling. Earlier sales and active reservations count against that allocation. The operator increases the ceiling when adding stock. Entering only what remains on a shelf would mean something different and could produce the wrong result.

This is a small system, not a warehouse-management product. Its limits need to be visible. Refunds do not automatically prove that an item has returned to sellable stock, so that decision remains with the operator.

Payment has an authority of its own

Stripe-hosted Checkout is the payment surface in the current foundation. The website does not collect card numbers into its own form or decide that money arrived because a visitor reached a thank-you page.

A verified notification from Stripe updates the durable order record. Durable means the result survives a closed browser tab or a restarted server. The order records what was bought and the payment state needed to handle it.

This also means the same notification can arrive more than once without creating a second purchase. Payment services retry delivery. The application has to recognize a repeated event rather than treating every arrival as a new instruction.

These are implemented foundations, not a claim that live checkout is currently enabled. Configuration, production readiness, and actual product records must be checked before a release opens.

Resale has a different counter

The eBay section belongs beside the Shop, but its listings are external inventory. Their details and checkout remain on eBay.

That should be obvious before someone follows a link. A resale listing gets an external destination, not a pretend add-to-cart button. It should not be mixed into the studio’s own order history as though the same system supplied it.

When the listing connection is unavailable, a quiet seller link is more honest than invented stock. The same principle applies to the internal catalog: an empty register and an unavailable backend are different situations and should have different messages.

Fulfillment is part of the design

A beautiful product page that leaves delivery unexplained is unfinished. A short fulfillment note gives the buyer something concrete to assess before paying.

The note should describe the arrangement for that release. It should not borrow a shipping date from another product or promise a speed that has not been established. If the terms are not ready, the release is not ready to accept orders.

This is where the visual and operational work meet. The photograph draws attention. The description explains the object. The options make the choice specific. The terms tell someone what follows. None of those pieces can stand in for the others.

An object has to survive the checkout

There is room for humor and attitude in okayhacker. There is less room for improvisation in what a buyer is charged or promised.

The machinery should let the personality remain on the surface while keeping the agreement underneath precise. That is the reason to build the system before declaring the store open. When an object leaves the workbench, somebody else has to be able to receive what they thought they bought.