Cart and checkout

The cart is designed as a quick drawer rather than a separate cart page.

Opening the cart

Shoppers can open the cart from:

• header cart button
• homepage review cart button
• add-to-cart actions

Adding a product opens the cart automatically.

Cart contents

Each line item shows:

• product image
• product name
• selected variant
• quantity controls
• item price
• line subtotal
• remove action

Quantity changes are saved in the browser. If the shopper refreshes, the cart should still be there.

Empty cart

The empty cart gives shoppers a way back to products instead of ending the flow.

It links to:

• product catalog
• shelf section

Checkout state

The storefront is pickup-first by default. At review, the shopper supplies a name, email, phone number, and optional pickup note. The API revalidates the cart against the live storefront snapshot, emails the request to the shop through Resend, and only then returns a submitted status.

“Submitted” is intentionally different from “reserved.” The shop still confirms stock, pickup timing, age requirements, and counter payment directly with the customer. If email delivery fails, the cart stays available and the shopper sees the server error instead of a false success state.

The API can also run in NMI sandbox mode for demo payment processing. In that mode, the shopper is sent to a payment handoff page where NMI tokenizes payment details before the Hono API attempts the sandbox sale.

See Payment strategy for the processor research and the production recommendation.

For production, the team should decide whether checkout means:

• emailed pickup request with counter payment
• NMI-backed online payment after high-risk merchant approval
• member-only quote request
• simple contact form for high-ticket items

Recommended production direction

For a smoke shop, pickup requests are the cleanest first production step.

That lets the store confirm:

• age requirements
• stock availability
• pickup timing
• payment method

Online payment should wait for an approved high-risk merchant account and the exact product, fulfillment, geography, and age-verification rules that account allows.

Current operational boundary

The first production version intentionally has no pickup-order tables. The accepted shop email is the operational handoff, and its reply-to address is the customer's email. An unchanged retry uses the same email-provider idempotency key, preventing duplicate shop messages during Resend's 24-hour idempotency window without requiring a persistent order store.

That makes the flow useful now, but it does not yet provide:

• a customer receipt email
• staff status changes or fulfillment history
• durable customer pickup history in Locker
• inventory reservation or automatic stock decrement

Those are the signals for introducing pickup_requests and pickup_request_items later, rather than prerequisites for launching this first request flow.