An online shop in Moldova: catalogue, payments and orders

An online shop works well when customers understand what they are buying, what they will pay and what happens after ordering. Design supports that decision but cannot replace stock, delivery and return information. Start with the complete order journey, including what happens when payment fails.

Set commercial rules before choosing a platform

Record who sells, which products exist, where you deliver and who answers enquiries. Define currency, tax presentation, delivery conditions and documents supplied to customers. Check the requirements applicable to the business before publishing; do not copy another country's shop terms without reviewing them.

In a hypothetical lighting shop, some products are stocked while others are ordered from suppliers. Those situations need different messages. “Available to order” should not look like “ready to dispatch”, and estimated timing belongs before payment, including when and how the team will confirm it.

Build a catalogue you can maintain

Choose categories around how customers shop: product type, use and meaningful characteristics. Distinguish categories from filters. “Desk lamps” might be a category; colour and wattage might be filters. Avoid dozens of single-product categories and labels that only employees understand.

Give products and variants stable identifiers. A lamp in two colours may require separate stock quantities even when both share one page. Decide who updates pricing and availability. Automated imports without validation can publish incorrect prices faster than manual editing, so document the source and update rules.

For addresses and filters, consult Google's ecommerce URL guidance. Keep addresses consistent. Do not turn every temporary filter combination into a separate page competing with the main product or category for the same search intent.

Make the product page sufficient for a decision

Show the whole product, relevant details and size in a credible context. Explain materials, compatibility, package contents and separately purchased items. An attractive photograph does not establish whether a bulb is included or whether installation needs an additional accessory.

Keep price, selected variant, availability and action close together. When a selection changes the price, update it before the customer adds the item to their cart. Explain genuine variations and use only authentic reviews you have permission to publish; demonstration content must not pretend to be customer evidence.

Remove surprises from cart and checkout

Customers should be able to change quantities, remove items and see the updated total. Show delivery costs or their calculation method before confirmation. If the final amount depends on the destination, ask for it at the appropriate stage and explain why it affects the order.

Request only the information needed to fulfil the purchase. Mandatory registration may add effort without helping a first-time buyer. On phones, check field labels, keyboard types and errors. An error should preserve existing information and identify the specific correction required, rather than reporting a generic failure.

• The cart preserves the chosen variant and quantity.
• The total includes known charges before confirmation.
• Going back does not erase every entered detail.
• Confirmation explains the next step and contact route.

Connect payment to a verified state

Choose a payment provider around company eligibility, currencies, available methods and current contract conditions. Test through its sandbox. A thank-you page alone is not sufficient evidence that a transaction was authorised or that money was collected.

The server should verify the provider's notification and update the order once for the same operation. Keep states such as created, awaiting payment, paid, cancelled and refunded distinct. For payment on delivery, receiving an order and collecting money remain separate events too.

Prepare the team behind the checkout

A saved order needs an owner and a processing route. Decide how stock is reserved, who prepares the parcel and how customers learn about delays. Email notifications help, but the primary record must exist even when an email fails to arrive or lands in spam.

Simulate a product selling out between cart and payment, an incomplete address and two successive confirmation clicks. Define both the customer message and the colleague's action for each case. Reliability comes from handling exceptions, not merely making the ideal purchase look attractive.

Measure stages without inventing sales

GA4 provides events for product viewing, cart activity, checkout and purchase, with specific parameters. Use the GA4 ecommerce documentation for implementation. A button click is not a purchase: connect the outcome to the confirmed order and its identifier.

Nonessential tracking requires appropriate consent. Do not send addresses, phone numbers or order notes to analytics. Reconcile reports with distinct orders and refunds, allowing for refusal and blocking. Revenue attributed by several platforms should not automatically be added together.

Launch a small, fully checked catalogue

Complete a phone purchase in every language, including a product variant and failed payment. Check messages, inventory, notifications and refund handling. Then send paid traffic to available products with sufficient information and a margin that can support fulfilment and advertising costs.

After launch, group issues by their consequences: blocked shoppers, incorrect orders, repeated questions or hard-to-find pages. Fix obstacles that prevent purchases first. Expanding the catalogue and advertising makes sense when the team can correctly process the additional demand rather than merely generate more unfinished orders.