What a plugin can change

A theme changes how a store looks. A plugin changes what it can do — a new way to pay, a new way to deliver, a new integration, a new screen in the merchant’s dashboard. This page is the map of the seams; the code-level tutorial lives in the repository, alongside the worked example it walks through.

The commerce seams

SeamWhat it addsShipping today
Payment methodA new way for a shopper to pay, with its own settings form in the merchant’s dashboard.Cash on delivery, Sham Cash, Syriatel Cash, MTN Cash, manual bank transfer, and a card gateway.
Delivery calculatorA new way to price shipping — by governorate, by weight, free above a threshold, or collection in person.Per-governorate rates and store pickup.
Courier adapterA delivery company: creating a shipment, pushing a label, pulling tracking updates.Manual courier handling plus two tracking aggregators.
Supplier adapterA dropshipping source: importing a catalogue, placing an order, reading stock.The supplier registry that the dropshipping feature is built on.
Notification transportAnother way to reach a customer, tried in order until one succeeds.WhatsApp, then local SMS, then email.
Registering into a list is always additive — you append your handler to what is already configured. Replacing the list instead of adding to it silently removes every method the platform configured before yours, which is the single most common way a new plugin breaks checkout for every store.

The platform seams

  • Entities and custom fields — your own tables, or extra fields on existing records. Anything persistent needs a migration; there is no schema-on-the-fly.
  • API operations — new queries and mutations on the merchant-facing API, guarded by their own permissions.
  • Scheduled jobs — recurring work such as refreshing an exchange rate or trimming a log.
  • Dashboard pages — new screens in the merchant’s dashboard, with their own navigation entry and bilingual labels.
  • Event reactions — respond in-process when an order is placed, a product changes, a shipment moves. This is also where outbound webhooks are raised from.

Rules that apply to all of them

Everything is per store

One deployment serves every merchant, so nothing may be global by accident. Every query your plugin runs, every record it writes and every job it schedules has to carry the store it belongs to. A plugin that forgets this does not fail loudly — it shows one merchant another merchant’s data.

Permissions and plan limits are different things

A permission answers "is this person allowed to". A plan limit answers "does this store pay for it". They are enforced in different places and a feature usually needs both: a staff member with the right permission on a plan without the feature must still be refused, and the refusal should say which of the two it was.

Bilingual, always

Every label a merchant or shopper can see exists in Arabic and English. That includes dashboard screens, settings fields, validation messages and any email or message your plugin sends.

Testable without a database

The convention is to factor decisions into pure functions and unit-test those, rather than standing up an integration environment. A calculator that takes a governorate and a weight and returns a price is testable in milliseconds; the same logic buried in a service is not.

How a plugin reaches a store

Plugins are part of the platform codebase and deploy with it. There is no upload, no marketplace, and no per-store installation of third-party code. Building one means working with the platform team on the repository itself, where the full tutorial and a deliberately minimal worked example live.

Building for one specific merchant, and not trying to change the platform for everyone? You almost certainly want the API and webhooks instead. That is what they are for, you can ship today, and you do not need anyone’s review.