8 Weeks to Launch Official School Commerce for The Best Private School in Kuwait

The British School of Kuwait is a private international K-12 school, part of British International for Education.

It teaches 3,500+ students and sells uniforms and branded merchandise to their parents through a closed online store, held open to 2,200+ authorised parent accounts.

Every August, 2,200+ parents buy uniforms for the coming school year within a few weeks. In 2026, they had to do it on a store disconnected from the school's ERP.

The British School of Kuwait sold uniforms through SANA Commerce, which was connected to Dynamics AX 2012. The school replaced AX 2012 with Dynamics 365 F&O. SANA had no connection to the new ERP, and reconnecting it cost more than building a replacement.

Replacing legacy SANA Commerce

Products, prices, and stock live in Microsoft Dynamics 365 Finance & Operations. With SANA disconnected, none of it reached the storefront on its own, and no order reached the ledger.

Any replacement had to keep F&O as the permanent system of record, with data moving continuously in both directions.

The replacement also had to reach F&O through the interfaces the ERP already exposes. Custom modules or middleware installed inside D365 would have pulled the school's ERP team into the build and added an approval chain the eight-week window could not carry.

The catalogue had to filter by child

Uniform rules vary by year group and by gender. A parent with three children across three phases sees a catalogue where most items apply to none of them, and has to know the school's rules to pick correctly. SANA could not filter this way.

The data needed to filter is not in the ERP. Grade, gender, and enrollment status sit in the school's student records, on a separate system with its own schema and its own authentication. Product data comes from F&O. Filtering meant joining the two per logged-in parent, per child, at request time.

The school also wanted one cart for the whole family. A parent with three children adds items for all three, pays once, and collects once.

A closed store with no public registration

Every account belongs to a parent the school has authorised, and 2,200+ of them had to exist at launch. There is no sign-up form. The catalogue and prices are closed as well: an unauthenticated visitor sees a login page and nothing else.

The school provisions every account directly, and password resets run through the same identity system. Resets were the single largest source of support tickets for school staff.

Working within a multi-layer governance structure

Single sign-on and every production deployment require approval from the parent organisation. Each approval adds a fixed buffer to the release it covers.

On an eight-week build, that buffer sits on the critical path of every deployment. Neither the SSO configuration nor a production release could proceed on the school's decision alone.

Fixed go-live date set by the school calendar

Uniform buying compresses into the weeks before the school year opens. A platform arriving after that peak misses a full year of trading, so the date could not move. The build ran eight weeks from kickoff to go-live, with the peak immediately behind it.

That compressed every dependency. ERP sandbox access, the Azure application registration, the student data specification, and the grade-to-product mapping all had to land in week one, because integration work could not start without them.

Mandatory full Arabic RTL support

Full Arabic right-to-left support was a mandatory requirement. Every page has to mirror – navigation, product grids, cart, checkout, the child selector – with Arabic typography and bilingual content that the school maintains itself, on the same product records that sync from the ERP in English.

We designed and built The British School of Kuwait's platform covering design, frontend, backend, and every integration.

Six external systems connect to it, and the features that carry the school's own rules – per-child catalogue filtering, one cart across a family, the seasonal catalogue switch, Arabic right-to-left – were all built custom on top of Medusa's commerce core.

Dynamics 365 F&O bidirectional sync

Dynamics 365 Finance & Operations is Microsoft's ERP, and it owns every product, price, and stock figure.

Nothing is installed inside D365. F&O does not need to know Medusa exists on the other side, which kept the integration inside the school's existing ERP configuration.

Inbound: products, prices, inventory, delivery modes

Products sync from F&O as product masters carrying gender, phase, and season attributes, with sizes as product dimensions. Prices sync alongside them, per size variant, on a configurable schedule.

Inventory syncs closer to real time with a higher frequency during the August peak.

Delivery modes sync on demand. The store runs on in-school pickup, and new modes appear in checkout when the client adds them in the ERP.

Outbound: sales orders

Once payment is confirmed, the order is written into F&O as a sales order – header with customer, date, and delivery mode, then line items with product, variant, quantity, and price.

Payment reconciliation stays where it already worked. The school's existing pipeline carries transaction data from the payment gateway into F&O, and eCommerce payments flow through it unchanged.

Per-child catalogue filtering via Student API

The British School of Kuwait runs its own Student API, the same one behind the school's mobile app – holding student name, grade level, gender, and enrollment status. It is separate from the ERP, and we integrated it directly.

After login, the storefront fetches the logged-in parent's children and shows a child selector. Selecting a child filters the catalogue through the grade-to-product attribute mapping the client defines.

We built the filtering logic against that mapping, keeping the rules the school's to change.

A parent switches to another child and adds to the same cart. One cart holds items for every child in the family, and checkout runs once – one payment, one order, one pickup.

Season-switching catalogue visibility toggle

The catalogue turns over twice a year between summer and winter uniform. On the old platform, that meant switching product sets one at a time.

Now it is a single control in the Medusa admin that flips catalogue visibility on a product attribute.

Okta SSO with governed provisioning

Okta is the identity provider running inside the parent organisation's tenant, and it already holds every parent's credentials.

Parents sign in with the account they already have, through a standard OIDC redirect flow with a login screen we branded for the school.

The Okta token carries a custom claim that identifies the parent. We map it onto the Medusa customer record, which is what ties a login to the right parent and the right children.

Password resets stay with Okta, and we put the reset link prominently on the login page, taking the school's largest support ticket category off staff.

Nothing renders before authentication. Unauthenticated visitors reach the login page only.

Ottu and KNET payment integration

KNET is Kuwait's national debit card scheme and the way parents already paid on the old store. We integrated it through Ottu, a hosted payment gateway, keeping the flow parents already knew. Refunds stay in the school's back office.

Payload CMS inside the storefront application

School staff needed the content control SANA gave them, without a developer in the loop. We used Payload CMS – an open-source headless CMS, with zero extra licensing. Staff compose pages from blocks and manage navigation, reorder menu items, and toggle sections.

Per-product content lives here too – washing instructions, extended descriptions, and size charts – uploaded as tagged images that render in their own section of the product page, away from the product photos.

The storefront runs in Arabic and English. Layouts mirror across every page, Arabic typography is set for the script, and bilingual content also sits on the same records school staff edit in Payload.

Order-ready notifications through a WhatsApp Business API Platform

WhatsApp is how parents expect to hear from the school, and the school uses a WhatsApp Business API platform to communicate. It tells the parent their order is ready for pickup.

The message template is held as a configurable variable, so the school changes its wording without a deployment.

The British School of Kuwait now sells uniforms through a platform that reads from and writes to its live ERP, opens only to authorised parents, and shows each of them the uniforms their own children are allowed to wear.

8 weeks to go-live

The build took eight weeks from kickoff to go-live. The school gained a full selling year on the new store.

Orders reach the ERP with no manual step in between

The store and the ledger stay in step with no one maintaining them by hand: no export, upload, or reconciliation pass. Every paid order writes itself into F&O as a sales order, header and line items, and products, prices, and stock flow the other way on schedule.

Fewer support tickets

Resets were the single largest source of support tickets for the staff. Parents now reset their own password through Okta from a link on the login page, so the tickets no longer reach staff.

Catalogue switchover reduced to a single control

Twice a year, the catalogue flips between summer and winter uniform. That turnover is now a single control in the admin panel, and school staff run it themselves. They publish the pages, size charts, and washing instructions without a developer as well.