An online store that makes buying from you simple

What to decide before choosing a platform

An online store is a business website plus three things it cannot avoid: a catalogue people search, an order that takes money and a promise about when the goods arrive. So before choosing a platform we settle a short list with you. What you sell and how. What the buyer does, from the first product view to the message confirming delivery. How complicated the catalogue really is once variants, prices and stock are included. Who runs the store day to day. And who deals with a late parcel, a failed payment or a refund.

The rest of this page uses one invented example to keep those decisions concrete: a shopper buys physical products with sizes and colours, a store operator confirms the order, stock is held by the store or sent from a supplier, payment is confirmed before stock is allocated, and a stock, payment or delivery problem can lead to a refund. Your own roles and rules are agreed for your project.

Your catalogue, stock and who ships the order

Your catalogue and your operations decide the size of the build far more than your design taste does. Six things matter: how each product is identified, whether it has variants with their own prices and stock, who owns the stock, where you deliver, how the parcel is handed to whoever ships it, and who is responsible when something goes wrong. A hundred products in three sizes is not a hundred products; it is several hundred items to sell, each needing a price, a stock figure and a photo that matches what arrives. How that data is structured decides whether filters and catalogue search can work at all.

Who ships the order changes the store more than anything else on that list. If you hold your own stock, you control allocation and the delivery promise. If a supplier ships for you, your store is placing an order with someone else, and their stock accuracy and lead time become part of a promise your customer thinks you made. When some lines ship from you and some from a supplier, you need an agreed rule for what happens when only half an order can be met.

When an item stops being available to the next shopper is a business decision, and platforms handle it differently. Odoo, as one documented example, offers three reservation methods: at order confirmation, manually, and a set number of days before the delivery date. That is specific to Odoo rather than a universal rule, but it frames the question every store has to answer.

Shopify, WooCommerce or a custom build

Compare the three by who carries which responsibility. A hosted platform such as Shopify takes hosting, security updates and payment plumbing off your hands, and charges for that through a subscription, app fees and often a share of each sale. An open-source platform such as WooCommerce gives you the code and the flexibility, along with the hosting, the updates and the occasional plugin conflict. A custom build means the checkout, the data and the admin are written for your business, with nothing included that you did not ask for. Whichever route you choose, the domain, hosting, platform and payment accounts, the catalogue data and any integrations should be in your business name from the start.

Every route still needs the same order handling underneath. WooCommerce's own documentation, as one example, treats orders placed at checkout, orders created by staff, order statuses, payment handling, test orders and abandoned carts as separate things to set up and check. That list is a fair checklist for any platform: somebody has to decide how each of them behaves.

Why we lean towards custom, and when we do not

When the decision is genuinely open, we tend to recommend a custom store, for practical reasons:

• The checkout follows how your customers actually buy, instead of a platform template, so the steps that lose customers can be removed.
• You are not paying a platform a percentage of every sale on top of your payment gateway fees.
• Stock, orders and customers live in your own database, so connecting an existing system is an integration rather than a workaround.
• No monthly app subscriptions stacking up to add back features the platform left out.
• The store is not tied to a theme system, so speed and layout are yours to control.

Custom is not automatically right. A small catalogue with ordinary needs often launches faster and cheaper on Shopify or WooCommerce, and we will say so. If you sell forty products, take card and FPX payments, ship with one courier and have nobody in-house to run a system, the hosted route is the sensible one, and paying for it is not a defeat.

The full comparison, with what each route costs over three years for a small store and a growing one, is in Shopify vs WooCommerce vs a custom store.

What Malaysian payment gateways publish

Gateway fees are an ongoing cost of trading, so they belong in the plan rather than in a footnote. The table below records what four gateways published on their own pricing pages, read on 18 September 2026. Nothing is interpreted, converted or averaged here, and where a page did not publish a figure clearly, the cell says so instead of guessing. Check the current rate at the source before you commit, because gateway pricing changes.

Four gateways Malaysian merchants regularly ask about, iPay88, senangPay, Razer Merchant Services and Revenue Monster, do not publish transaction rates publicly and quote on application. Revenue Monster publishes a RM499 setup fee and terminal rental but no transaction rates. That is useful to know before you plan around a number heard second hand: a like-for-like comparison with those four needs a written quote from each, and the quote usually depends on your volume.

Match the store to what you sell

What you sell decides how the store works, because each kind of selling revolves around something different. Retail revolves around a buyer and a product. Business-to-business or dealer ordering revolves around approved accounts with their own prices, so the catalogue changes with who is logged in and an order may need approval first. A marketplace revolves around buyers, sellers and payouts, which means running other people's shops as well as your own. Our Aruva Marketplace prototype follows one order through all six roles a marketplace has to run: buyer, seller, operations, warehouse, courier and support.

The other stores we are asked for are custom builds scoped to the business rather than off-the-shelf packages. Subscriptions revolve around a recurring agreement and a renewal that can quietly fail. Digital products revolve around access rather than a parcel. Rentals revolve around an item that has to come back in one piece. Event ticketing revolves around capacity and admission, course sales around enrolment, and restaurant ordering around menu availability, preparation time and a pickup or delivery window. Our PestaHub prototype shows the timed kind: a live floor plan where each booth is either free or taken.

Payments, order records, stock and the admin view are shared by all of them. What is never shared is the exception rule: a failed renewal, an unreturned rental and a missed collection slot are three different problems with three different owners, so we plan each one explicitly.

The order process every store shares

Whatever you sell, the same steps run underneath: choosing a product, checkout and confirmed payment, allocating stock, shipping, then handling problems and refunds. The table follows the invented example through them. The last column lists checks we run before launch, not results claimed in advance.

When you need a developer, and when a theme is enough

The honest test is where the boundaries fall. If the catalogue, payments, shipping, permissions and exceptions all sit inside one platform, a hosted store and a good theme may be all you need. Once any of them has to reach another system — an accounting package, a supplier feed, a dealer price list or a customer database you already run — the work stops being configuration and becomes engineering. That is where we help most.