A storefront and administration platform that carries orders through payment, shipping and returns.
This ecommerce platform case study covers a storefront joined to the work that follows a sale. That work includes invoicing and shipping. It also covers returns and refunds. Staff handle all of it from one administration area, and every activity stays tied to the order it began with.
The catalog holds physical goods and configurable products while also covering bundles, digital downloads and bookable services. Channels let a single merchant run several storefronts inside one installation.
The challenge
The stock figure on a product page can lag the orders already placed. A payment confirmation may arrive twice. It can come once from the shopper's browser and once from the provider. Later, one part ships while another is refunded.
We put our effort into the points where one apparent status hides several different facts.
What we built
Checkout recalculates the totals and checks payment eligibility before it accepts an order. A guest basket can merge with a customer basket at login, and staff can also raise orders straight from the administration area.
Each order line tracks the quantities ordered and invoiced. It also records what has shipped, and what was later refunded or cancelled. With that detail, staff can settle part of an order without closing the whole purchase. Online and offline payments feed one shared flow.
Technical approach
Inventory keeps physical stock apart from stock promised to orders that have not shipped. The storefront shows an indexed availability figure. That figure is fine for browsing. At checkout the system reads the authoritative stock rows once more, this time under a database lock.
One transaction saves the order with its lines, addresses and payment details. A shortage stops the purchase altogether, unless back orders have been turned on for the product. The general retry path skips both stock shortages and spent coupons. Physical stock falls only when goods ship. Reservations stand in for the units promised before then.
Two confirmations, one placement function
The hosted-payment return and the provider's signed notification both call the same function. It locks the basket through the cache, then looks for an order already created from it. When one is found, the repeat call simply returns it.
If no order exists yet, the function first compares the recalculated total with the amount charged. Only then does it create one. The webhook has to stay reachable, because a shopper may pay and then close the browser without coming back.
Order events take care of email, coupon usage and index updates. Those events move to queue workers when the work should run outside the checkout request.
Project success
An operator can see what has been invoiced, shipped or refunded, even while fulfilment is only partial. At checkout, current stock is checked inside the transaction. Repeated payment confirmations return through one placement route. The purchase holds one identity, through the sale and the administration that follows.
Technology stack
Application
PHP, Laravel
Interface
Vue, Blade, Tailwind CSS
Database options
MySQL, MariaDB, PostgreSQL
Catalog search
Elasticsearch
Extension model
Modules, events, model overrides
Other engagements
Recognize the pattern?
If one of these looks like your situation, the discovery call is where we find out how close.
