Shopify or WooCommerce for an Algerian shop: the delivery-and-payment question

Shopify is the quieter choice when you sell cash on delivery through third-party couriers and want the storefront to be one less system to maintain. WooCommerce bends when the shop must feed stock or accounting you already run, or when catalogue and customer records must sit on a server you control. The decision flips on where the risk lives: in an operation you cannot automate, or in who owns the data and the integrations around it.

Does either platform assume the customer pays before delivery?

No, and that assumption is the one you add yourself. Both treat cash on delivery as an option beside card payment, the reverse of how a shop runs here: the parcel leaves, cash arrives later, and the record of who owes what is written by several hands.

What matters is whether the platform can hold the facts: a status separating "shipped" from "delivered and paid", the amount collected on that parcel, a reason when it returns, and a settlement that references a batch. If it cannot store the collected amount, you reconcile in a spreadsheet beside the shop, and the platform was never the decision.

Who integrates the courier: the platform or you?

Shopify answers with apps. Some cover local couriers, most cover international ones, and where your courier's interface is thin the app does not exist: you need one built. WooCommerce answers with a plugin or code you host; the courier's interface is the same either way.

So the comparison is less about which integrates better than about who owns the breakage. On Shopify you rent the integration and inherit its release cycle. On WooCommerce you own it: it does what you asked, and it fails when you stop maintaining it. Pick the failure you can staff.

What do Arabic and French actually require?

Both support a multilingual storefront; the difference is who does the work. Shopify's themes are built left-to-right first, RTL support depends on the theme and often needs editing or an app, and the checkout strings belong to the platform. WooCommerce lets you choose the theme and the plugin, so RTL quality is a decision you pay for rather than a limitation you discover.

Test what breaks in practice: an Arabic product name beside a Latin model number, a size and colour selector, an address form with wilaya and commune, a cart in Arabic and a checkout in French. On a phone, on a mobile connection — that is where the order is placed.

Who maintains it, and what does that cost in attention?

Shopify is hosted: updates, patches and the server are someone else's problem, and the trade is that you cannot change what the platform does not expose. WooCommerce is software you install: WordPress, the theme, the plugins and the server all need tending, and one abandoned plugin becomes a security question.

Not an argument against it: an argument for knowing, by name, who does that work.

Who owns the shop and its data?

On Shopify you rent the storefront. Catalogue and orders export, but app data stays in the apps, and a shop that grows into unusual logic — customer prices, wholesale tiers, a delivery rule per zone — reaches the edge of what it allows. On WooCommerce the database is yours, which matters the moment stock should come from an ERP rather than being typed twice.

What happens when the shop must talk to the back office?

WooCommerce exposes a REST API over a schema you can read, so an integration is ordinary development: read orders, write stock, push a status back. Shopify's API is good, and the app model means each function arrives as a monthly app rather than a line of code. Simpler with no back office; for a shop that is one channel of a business already on a stock system, it is a subscription per seam.

The comparison, in one table

Dimension	Shopify	WooCommerce
Cash on delivery	From apps; statuses depend on the app	From plugins or your own code
Courier integration	Rented with an app, follows its releases	Owned by you or your developer
Arabic and French	Theme-dependent RTL; checkout fixed by the platform	Theme and plugin of your choosing
Who maintains it	The platform, within its own boundaries	You, every month
Data ownership	Records export; app data stays in the apps	The database is yours
Back-office integration	API plus apps, app-shaped	REST API over a schema you can read
What to verify on the vendor's page	Which payment and delivery options a business registered in Algeria can enable	WordPress and plugin requirements of the version you would run

In what order should you decide?

1. Draw the life of one order: placed, confirmed by phone, shipped, delivered or refused, settled. Note where each state is stored.
2. Ask the courier what its interface exposes — labels, statuses, settlement lines — and get the document, not the promise.
3. Build that flow once on a staging shop, on the platform you lean toward. If it cannot store the collected amount, stop.
4. Test the Arabic storefront on a phone with a real product, address form and cart.
5. Name who updates the site and who is called when checkout fails; cost that attention, not the licence.
6. Only then compare running cost, theme and apps.

Where this goes wrong

• The theme is bought before the delivery flow is defined, and the checkout has no field for the landmark the driver needs.
• Cash-on-delivery orders are marked paid when placed, so revenue looks healthy in the month the parcels shipped and the cash never arrives.
• Wilaya is a free-text field. The courier's zone rule is applied by hand, at the counter, by whoever remembers.
• Plugins stack until nobody knows which one writes the order status, and two of them do.
• The site is fast on the developer's connection and slow on a phone in a shop; the customer leaves at the address step.
• Two catalogues, two stock counts: an Instagram page and a site that disagree, with the shop assistant as the integration.

When neither fits

When the shop is really the front of an order-taking operation — a business working from WhatsApp and a price list, or a wholesaler whose prices depend on the customer — a standard storefront becomes a form that collects orders the back office retypes. The alternative is a smaller custom storefront reading your catalogue and writing into your own order record, with the courier link built once and the reconciliation included. Not always the cheaper start; the shape that ends the double entry.

What this does not cover

Pricing is deliberately omitted: a quoted figure would be wrong within months, and the real comparison is the attention each model demands. Nothing here covers acquiring a payment gateway, a bank question, nor the legal side of selling online here. Nor does it judge either platform on marketing features; a shop that cannot deliver does not need a better funnel.

We build and integrate systems around tools like these — the order record, the courier link, the reconciliation behind the storefront. We resell neither platform and take no commission from either.