What It Really Takes to Ship a Full-Stack E-Commerce Store

Authentication, product data, cart state, Stripe payments and order reconciliation - a practical look at what separates a real storefront from a portfolio demo.

An e-commerce storefront looks simple from the outside: show products, let people buy them. From the inside it is authentication, pricing, inventory questions, payment webhooks, and order data that has to survive the gap between 'the customer paid' and 'we got the money'.

I built a full-stack storefront with Next.js on the front, a Node.js API and MongoDB for data, and Stripe handling payments. This post covers the decisions that mattered most.

Start with the data model

Everything downstream depends on how you model products, variants, prices and orders. A price is not a number on a product - it is data that changes with currencies, offers and time. Orders are not a single document either; they need status history so you can answer 'where is my order' and 'why is this unpaid'.

Authentication before features

I added authentication early, because carts, addresses and order history all belong to a user. JWT-based sessions keep the API stateless, and every order endpoint verifies that the order belongs to the authenticated user - never trust an ID from the client.

Cart state is product logic

• Quantity limits and stock checks belong on the server, not just the button.
• Price is re-read from the server at checkout - never from the cart in the browser.
• A cart is a draft order. Model it that way and checkout becomes a status change.

Payments: the part that cannot be faked

Payment integration is where a demo becomes a product. The flow is: the server creates a payment, the client redirects the customer, and then - critically - the server verifies the result instead of trusting the redirect. Webhooks reconcile the final state, and order status updates only from those verified events.

// server-side verification - the redirect alone proves nothing
const event = stripe.webhooks.constructEvent(rawBody, signature, secret);
if (event.type === "checkout.session.completed") {
  await orders.markPaid(event.data.object.metadata.orderId);
}

Order status as a state machine

Orders move through statuses - pending, paid, processing, shipped, delivered, and the failure paths like payment-failed and refunded. Encoding that as a state machine stops you from writing inconsistent updates all over the codebase.

Lessons I keep using

• The client can tell you what the user wants, but never what is true.
• Money flows need an audit trail - store every event, not just the final state.
• Schema changes are expensive; model prices and orders right the first time.
• A payment webhook failing silently is worse than a loud error.

Anyone can show a button. Shipping a store is proving - with logs, webhooks and reconciliation - that when the button is clicked, the money and the order actually agree.

The storefront taught me the discipline behind payments, state and data integrity - the same discipline I later poured into ERPX, where every invoice and payment posts to a double-entry ledger.