Engineering behind the checkout
Deciding honestly between platform and custom
We ask four questions. Is pricing a function of who is buying? Does checkout need steps a consumer store lacks, such as approvals or credit terms? Does fulfillment branch? Must the store share live data with another system you own? One yes can usually be handled on WooCommerce with a focused plugin. Three or four, and you will spend more maintaining workarounds than you would on a build. A custom store also means there is no plugin marketplace to lean on. Every feature is built or integrated, so we keep the first release narrow.
Prices are calculated in one place
The pricing engine is a single service that takes a product, a customer, a quantity and a date and returns a price with its reasoning attached. Catalog pages, the cart, quotes, the admin order screen and the API all call it. Money is stored as integers in the smallest currency unit, never as floats, and tax is computed per line with rounding rules agreed with your accountant. When a customer asks why they were charged a certain amount, support can read the answer off the order.
The cart is checked again before money moves
Carts live in the database, tied to the account or a signed guest token, so a buyer can start on a phone and finish on a desktop. Prices and stock shown in a cart can go stale. At checkout we recalculate everything, reserve stock inside a transaction with a row lock, and only then create the payment. The payment itself is confirmed by the gateway's webhook, not by the browser redirect, because customers close tabs. Card data never touches your server, since the gateway's hosted fields keep it out.
Orders, payments and shipments as separate state machines
An order can be partly paid and partly shipped at once, so a single status column cannot describe it. We model three linked lifecycles with explicit transitions. Refunds, cancellations and returns are transitions too, each with its own stock and accounting effect. Every transition fires an event, which is where confirmation emails, warehouse notifications and ERP postings attach.
Search, speed and the back office
Product search runs on a dedicated index kept current through Scout as products change. Category and product pages are cached and rendered on the server for search engines, while price and stock for logged-in trade customers load per request. The admin panel is built for the people who use it all day: order queues by state, bulk actions, stock adjustments and a customer view with full order history. Where the back office is really an operations system, we connect or build it as described under Laravel ERP development.