E-commerce Website Development

Running your own online store is usually pictured as a catalogue with buy buttons. The real work is keeping five numbers in agreement: stock shown, price charged, shipping billed, amount paid, and quantity recorded. Compute one of them in the wrong place and the shop still looks fine, right up to the first broken order.

So the work on a shopping cart website starts with product data, not page design. A product needs a name, SKU, weight, dimensions, price, and stock, and every variant needs all six of its own. Clean data scales to 500 product and content pages without slowing down, while messy data keeps producing orders somebody repairs by hand.

The most expensive mistake is treating variants as a text choice. Size and colour go in one dropdown, stock stays one number for the whole product, and the shop sells a sold out size all week without anyone noticing. Every variant combination needs its own SKU, price, weight, and stock.

The second problem is harder to see: two buyers ordering the last unit seconds apart. If stock is deducted only when an admin marks the parcel shipped, both payments succeed and one has to be refunded. We deduct at payment creation, with a hold that releases itself when the payment expires.

A buyer closing the tab after paying is normal behaviour. If the order is only marked paid by the thank you page, the money lands while the order hangs, and your team ends up matching bank entries by hand.

The paid flag has to come from a server to server callback, and that callback can arrive twice, arrive late, or arrive for an order already cancelled. So each one is processed once per order number, with its signature verified and its amount checked against the order total. Skip the amount check and an IDR 1,500,000 order can be settled by an IDR 15,000 payment.

The test for this gets skipped regularly: pay for one real low value order, then close the browser before the redirect. Five minutes later the order should read as paid, with stock deducted, the notification delivered, and the invoice issued.

Flat shipping is the fastest way to lose money on delivery. Couriers bill on whichever is greater, actual weight or volumetric weight, which is length by width by height divided by the courier's divisor. A baby goods store selling pillows and small mattresses shows it best: light items, big boxes, and an invoice several times what the scale suggested.

Destinations resolve to district level, not city level, because rates and coverage differ between districts and an address outside coverage surfaces only when the parcel is rejected. The figure is computed on the server at checkout from each variant's weight and size, then shown before the buyer presses pay. Free shipping is fine as long as the threshold comes from margin per zone, not from a round number that sounds appealing.

The package holds up to 500 product and content pages, and that volume creates problems a ten page site never meets. Colour filters, price sorting, and page numbers easily produce dozens of URLs for the same content, and Google splits the value across all of them. We fix one canonical address per product and keep filter combinations out of the crawl.

Sold out products need the same care. Deleting the page throws away ranking that was hard to earn, even though the item may return next month, so we keep it, mark it out of stock, and link to the nearest replacement. Every photo is compressed and resized on upload, because a five hundred product catalogue carries thousands of images and category pages have to stay light on mobile networks.

An ecommerce build is handed over only after one real transaction runs end to end in front of you: order, pay, settle, stock deducted, notification sent, invoice issued, and one refund tested. We walk that checklist on a call rather than send it as a report, because an owner needs to see where order numbers land and what to do when one hangs.

Once the store is trading, price changes, new products, and content pages are handled by our team for a year at no extra cost through the WhatsApp group. Work beyond the website, such as multi warehouse stock or a shop till, is built as application modules at IDR 5,000,000 per module per year including the server, with five modules bundled at IDR 20,000,000. Our office is in Gunung Putri, Bogor, and product data work at a client warehouse can be done on site.