Ventra Marketplace
Launched
Software Engineer
MVP build | May-Jun 2026
Overview
A full-stack multivendor ecommerce marketplace for local commerce, spanning customer discovery, seller operations, admin workflows, Stripe and Cash on Delivery checkout, shipping, returns, and vendor accounting.
Project toolkit
Tools that shaped the build
A compact map of the frameworks, services, and interface layers behind the final experience.
11 signals
Case study
Ventra is a marketplace operations project disguised as a shopping experience. The storefront stays familiar for customers, while the system underneath coordinates vendors, stock, payments, shipment states, refund holds, returns, and administrative controls without collapsing those concerns into one oversized flow.
Outcomes
3
Connected experiences
Customer storefront, vendor workspace, and Filament operations panel.
2
Checkout paths
Stripe Checkout for online payments and Cash on Delivery with reconciliation.
1:N
Order architecture
One customer order can split into seller-specific fulfillment and accounting flows.
Problem
A multivendor marketplace is not a larger version of a single-store cart. One checkout can include products from several sellers, but each seller needs an independent preparation flow, shipment, accounting trail, and return path. The customer still expects one clear purchase experience.
The difficult part was keeping those views consistent without giving the frontend authority it should not have. Stock, pricing, payment state, seller eligibility, and refund behavior all need server-side validation because each one affects money or fulfillment.
Solution
Ventra uses a Next.js App Router storefront and seller workspace backed by a Laravel API. Laravel Sanctum sessions protect authenticated flows, React Query manages server state, Zustand keeps the cart count responsive, and Filament provides an operational admin surface.
The backend treats a purchase as a parent order with seller-specific child orders. Each vendor order can move through preparation, shipment, payment settlement, returns, and ledger updates independently while the customer sees a unified order history.
Process
1
Frame the marketplace around real roles
The product was shaped around three audiences from the start: shoppers, approved sellers, and platform operators. That made it easier to keep the public storefront search-led and retail-dense while giving vendors a focused operations workspace.
The design exploration tested several homepage lanes before settling on a deep-navy marketplace shell, strong search affordance, compact product rails, approved-seller cues, and a restrained lime accent reserved for deals and cart state.
2
Build vertical frontend slices
Each Next.js route composes a feature panel, React Query hook, API helper, and shared Axios client. That structure keeps catalog, cart, checkout, orders, addresses, wishlist, reviews, notifications, vendors, finance, and analytics close to the behavior they own.
The catalog prioritizes product imagery, price, seller identity, availability, wishlist actions, sorting, pagination, category and brand filtering, plus public category, brand, and vendor storefront routes.
3
Model checkout as an operational transaction
Checkout revalidates products, sellers, ownership, price, and stock on the server. Stripe orders are created after a signed webhook is verified, while Cash on Delivery orders are created immediately with a pending payment state.
Provider event IDs are persisted so duplicate Stripe webhooks are ignored. Stock deduction, cart clearing, payment records, vendor ledger credits, and order creation live inside transaction-aware backend services.
4
Carry the workflow past checkout
The implementation continues after the purchase button: seller fulfillment advances to courier handoff, shipments expose tracking states, COD deliveries generate reconciliation records, and seller earnings remain protected by a refund hold.
Delivered-item returns preserve item snapshots and quantities. Approved returns restore stock and reverse earnings; rejected returns create a shipment back to the customer instead of disappearing into an ambiguous status.
Responsibilities
Designed the full-stack architecture across the Next.js storefront, Laravel API, and Filament admin panel.
Implemented catalog discovery, product details, variants, wishlist, cart, checkout, account, and seller workspace flows.
Built multivendor order splitting, stock validation, Stripe webhook handling, Cash on Delivery reconciliation, and immutable seller ledger updates.
Added shipment tracking, cancellation, delivered-item returns, refund holds, payout requests, notifications, and admin merchandising controls.
Documented the product surface, backend modules, API routes, data model, and verification workflow.
Highlights
Guest carts merge into the authenticated backend cart after login or completed email verification.
Products support up to three option groups with SKU-level price, stock, threshold, active, and default states.
Homepage merchandising is API-driven so operators can update banners, flash deals, and featured products without a frontend deployment.
The backend separates courier shipping amounts from seller earnings and tracks COD settlement per vendor shipment.
Responsive storefront behavior was audited down to a 320px viewport with route-shaped loading skeletons.
Gallery
Lessons
Marketplace architecture becomes easier to reason about when order, fulfillment, payment, and accounting states are explicit instead of compressed into one status field. The customer order is a useful umbrella, but the vendor order and shipment are where operational truth lives.
Payment UI should describe backend state, not invent it. Stripe webhooks, persisted provider events, transaction-aware services, and server-side totals keep the frontend responsive without making it the source of truth.
Production hardening remains on the roadmap: connecting a real courier provider, configuring production credentials, deployment, monitoring, security review, and deeper analytics.
The current deployment is slower than the production target because it runs on limited free hosting services.