Can I run an online store that takes Whish, OMT or cash on delivery?

The assumption every store platform makes

Almost every store platform is built card-first. The checkout ends with a card form, the order is marked paid because a processor said so, and everything downstream — the confirmation, the dispatch, the accounting — hangs off that moment.

In Lebanon that assumption breaks at the first step. Card payment is a minority of what people actually use. The money moves through Whish, through OMT, through a bank transfer, or it arrives in cash at the door. A checkout that cannot end any of those ways is a checkout most of your buyers abandon — which is why so many businesses here concluded that an online store was simply not for them. See taking online payments in Lebanon for why the payment layer, not the website, is usually the blocker.

Helm's Shop module starts from the opposite assumption. Payment that settles outside the checkout is the normal case, not the fallback.

What the buyer does

They browse a catalogue, pick a variant, and go to checkout. Then they choose from the payment methods you configured — and you name them yourself. "Whish", "OMT", "Cash on delivery", "Bank transfer": these are rows you create, not a fixed menu you pick from.

What happens next depends on which kind of method it is.

Paid before dispatch — Whish, OMT, a bank transfer. The buyer sends the money the way they already send money, then types the transfer reference into the checkout. If you marked that method as needing a reference, the field appears and the order will not go through without it. The order lands as awaiting payment.

Paid at the door — cash on delivery. No reference, nothing to confirm up front. The order lands as unpaid, which is exactly what it is until the courier comes back.

Either way the buyer leaves with an order reference on screen. They can look the order up again later with that reference and their email address.

What you do

You open the dashboard and confirm the money arrived — by eye, against your own statement. Helm does not verify the transfer, and it should not pretend to: only you can see your account.

From there the order moves through new, packed, shipped, delivered. Stock came off the moment the order was placed, counted per variant, so the site cannot sell you into a hole while you are confirming payments. If you cancel an order, the stock goes back exactly once, even if you and a colleague cancel it at the same moment.

Two details that matter more than they sound:

A surcharge belongs to the method, not to cash. If cash on delivery costs you something, you can put a fee on that method. If a transfer method costs you nothing, it carries no fee. The fee is a property of how people pay, which is the honest way round.

You choose when money counts. Orders that settle offline can count as revenue when they are placed or when they actually settle. The dashboard shows both figures regardless; this only decides which one leads. It defaults to counting on settlement, which is the conservative choice and usually the right one when payment arrives by hand.

Delivery, priced the way it actually works

You define delivery regions — a name, a flat fee, and a rough time ("Beirut, same day"). You can set a threshold above which delivery is free. That is deliberately simpler than a courier rate engine, because for local delivery the honest answer is usually a small number of named areas with a price each, not a weight-and-distance calculation.

What it does not do

This matters as much as the rest, and it is better to know now than after you have built the pages.

No online card payment. Not "not yet configured" — a card method is refused at checkout, and the storefront never renders a card button. Nothing in Helm can confirm a card payment arrived, so it does not offer to.

No emails, in either direction. The buyer gets no confirmation email. You get no alert when an order comes in. You find out by opening the dashboard, so if orders are sporadic, build the habit of checking, or you will find one on Thursday that arrived on Monday.

No tax by region, and no discount codes. Neither exists. If you need either, this is not the tool.

No carrier integration, tracking numbers or live shipping rates. Delivery is the flat fee per region described above.

No refunds that move money. You can mark an order refunded as a bookkeeping record; the money goes back the way it came, by your hand.

No storefront design. Helm runs the catalogue, the stock, the delivery regions and the orders. The product and checkout pages are built into your site's own design. That is a build, not a switch — worth budgeting for.

When this is the right tool

When your buyers pay by Whish, OMT, transfer or cash, and a card-first checkout would lose most of them. When your catalogue is stable enough to maintain and someone is genuinely responsible for packing. And when the messages have become the bottleneck — if they have not, a page and a WhatsApp link is still the better first move, and the arithmetic of whether you need a shop at all has not changed.

The short version

A store here does not fail because the website was bad. It fails because the checkout ends in a card form nobody wanted to use. Shop ends the checkout where the money actually is — a reference you confirm, or cash at the door — and is honest that it has no card payment, no tax engine, no discount codes and no order emails. If those are the things you need, use a card-first platform. If they are not, the reason you did not have a store may have stopped being true.