Merit product showcase, Amman
MERIT · PRODUCT · INTERNAL

B2C Super App

The consumer front door is live and shipping. The constraint is market access, not engineering.

Merit is a loyalty stack.

Merit product showcase, Amman on-site, August 2026 | Brian Arfi Faridhi, Product Director

B2C Super App · What it is · 1 of 6

Merit selling directly, instead of through a client

A phone app that turns loyalty points you cannot use into money you can spend.

Points from many programmes, one balance, three ways to spend Banks card points Airlines miles Retailers loyalty points Employers benefit balances Merit wallet one balance, valued in SAR Digital goods gift cards, delivered in seconds Physical goods marketplace, shipped to the door Mixed payment points and card in one basket Aggregation is the product. No single issuer can offer this, because no issuer owns the other programmes.
React Native client on Merit backend services. Board MBA.
B2C Super App · Why we are doing this · 2 of 6

A moat we control, because B2B sales cycles are long

Every other Merit product reaches the user through someone else's brand.

  • The gap. Merit had no direct consumer touchpoint. Clients controlled the member relationship, so we learned nothing about behaviour and captured none of the loyalty.
  • The bet. Aggregation is the product. A single point balance is worth more to the holder than a dozen locked ones, and an issuer cannot offer that across programmes it does not own.
  • Targets for the first quarter after store launch. 10,000+ downloads, over $100K GMV split evenly between digital and physical goods, D7 retention above 40%. iOS cleared on 13 August, so that quarter starts now.
  • Second-order value. The app is also our fastest test rig and our only source of production behavioural data. Whatever we prove here, tenants buy on the e-commerce stack.
B2C Super App welcome screen: Turn your loyalty points into real purchases
The app says the proposition better than we can
B2C Super App · New or existing · 3 of 6

Existing and live in two markets. The wall is not code

KSA and UAE are open. Everywhere else is blocked on two things we do not control.

Two gates stand between the app and any new market The app built, shipped, live on both stores Gate 1. Registration Firebase Auth hardcodes SMS OTP. Delivery needs per-country telco registration. Gate 2. Payment Moyasar declines non-KSA and non-UAE. This is what held Jordan. Live today Saudi Arabia and the UAE Everywhere else blocked on the two gates, not on build In flight: reverse WhatsApp OTP against gate 1, estimate due Mon 17 Aug. Multi-currency Tier 1 designed, Phase 1 about two and a half weeks.
Storefront will hit the same authentication wall. The OTP fix is not a B2C-only fix.
B2C Super App · Main use cases · 4 of 6

Four jobs, in the order a user meets them

Four B2C app screens: transactions, product detail, cart, payment successful
Transactions, product detail, cart, done
B2C Super App · Main use cases · 5 of 6

Buying with points, the five screens end to end

Entry to ledger, in the order the member meets them.

Five B2C app screens in order: entry, product detail, cart, payment successful, transaction history
Entry, product, cart, paid, ledger
B2C Super App · Who uses it · 6 of 6

Consumers in KSA and UAE, and the six of us who build it

New joiners: this is the smallest surface to learn on, and the fastest to ship into.
MERIT · PRODUCT · INTERNAL

E-Commerce Solution

Merit's main business. Currently rebuilding itself underneath clients who are transacting on the old one.

Merit is a loyalty stack.

Merit product showcase, Amman on-site, August 2026 | Brian Arfi Faridhi, Product Director

E-Commerce Solution · What it is · 1 of 15

The managed commerce layer between points and products

Airlines, banks and telcos hand out points that sit unspent. They want members to burn them. Running commerce to do that is heavy. We are the layer in that gap.

The gap Merit sits in branded store in weeks points become goods Airlines, banks, telcos hold the points, want them burned, do not want to run commerce Merit suppliers, catalogue, orders, logistics, payments, settlement Their members burn points on things they actually want Shopify cannot no idea what a loyalty ledger is Talon.One cannot no catalogue, storefront or fulfilment The wedge end to end, MENA logistics Points sit unspent. That is a balance-sheet liability for them and a dead experience for the member.
E-Commerce Solution · What it is · 2 of 15

What sits inside the E-Commerce Solution

Six components. Each owns exactly one job, and the next eight slides take them one at a time.

Six components, and the one job each of them owns Seller Portal how a supplier lists, prices and fulfils Storefront how a shopper searches, buys and pays Storefront Builder how a tenant creates its own store E-Commerce Core + PIM what a product is, who sells it, at what price OMS what state the order is in Fulfilment Service who fulfils it, and how OTO and MGC the couriers behind the Fulfilment Service Three surfaces on the left, one spine in the middle, and the order path on the right. Every surface talks to the Core and to nothing else, which is the whole reason the Core exists. Read it as: the left asks what can I sell and buy, the middle answers, the right carries the result to a doorstep.
E-Commerce Solution · Why we are doing this · 3 of 15

This is where Merit's revenue comes from

Not a side bet. The commercial engine, and the reason most of us have a job.

  • The target. 16 large tenants and 100 sellers by December 2026, roughly $869,200 per month recurring at OKR close.
  • The ramp. 2 tenants live in September at about $110K a month, 5 in October, 10 in November, 16 in December.
  • Why it only works once. Bespoke builds do not compound. Every new client costs a full engineering team and the margin never improves.
  • The test of success. Tenant two and tenant three are a configuration exercise, not a rebuild. If they are a rebuild, we did not build a platform.
  • What changes for you. You stop shipping features to a client and start shipping capabilities to a product that many clients use. Generalise by default.
Tenants live 20 15 10 5 0 tenants 2 September 5 October 10 November 16 December about $110K a month $869,200 a month
September is the first commercial checkpoint. Only the September and December revenue figures are set, so the two middle months are shown as tenant counts rather than invented numbers.
E-Commerce Solution · New or existing · 4 of 15

Old World and New World

The single most confusing thing about Merit for a newcomer, including most of what is on Confluence, which is written about the Old World and is not marked as such.

Old World pays the bills. New World has no live client yet Old World serves every paying client today Every live client runs here Al Fursan, the biggest and most complex, included Built business-led architecture accumulated rather than being designed The symptoms out-of-stock incidents, order failures, heavy manual ops No Seller Portal at all suppliers cannot self-serve New World modular rebuild, no live client yet Decoupled services Core, PIM, OMS, TMS, Seller Portal, Storefront Builder Product versus offer from day one designed, not accumulated Seller Portal shipped first and wired back into Old World, so value lands early Target Al Fursan by end September, fully migrated by December The structural problem: you cannot freeze the old platform while you rebuild it. It keeps adding features, so the new one has to rebuild everything and catch a moving target. Most of Confluence is written about the Old World and is not marked as such.
E-Commerce Solution · Main use cases · 5 of 15

Seller Portal: the supply-side front door

Built first, on purpose. The Old World had nothing like it, so suppliers could not self-serve at all.

Seller Portal product listing in three screens: category, category attributes, variant selection
Category drives the schema, then the offer
Roadmap targets: manual ops onboarding requests down 80%, time-to-live for a product listing under 24 hours against a 7-day manual average, self-service rate above 90%.
E-Commerce Solution · Main use cases · 6 of 15

Storefront: what the shopper actually touches

The consumer surface. Multi-tenant white-label template on Next.js, currently around 50 to 60% complete.

Al Fursan storefront in three screens: product page with a Cash plus Miles slider, checkout, order success with points earned
Al Fursan Store, product page to order placed
Design: Storefront Builder and Seller Portal both have Figma files. Ask and I will share them.
E-Commerce Solution · Main use cases · 7 of 15

Storefront Builder: the thing that makes tenant two cheap

The control plane a tenant uses to create and configure its own store, with zero engineering per tenant.

Storefront Builder is what makes tenant two cheap STOR-1, September target Today, per tenant engineering builds the store: branding, domain, catalogue scoping, publish. Manual by design through July and August. With the Builder the tenant does it themselves: branding, domain and SSL, catalogue slice, tier and billing, sandbox preview, publish. Cost per launch a project, priced in engineering weeks Cost per launch a form 16 tenants by December is only reachable if onboarding is self-service. At today's cost per launch that number needs a team we are not hiring. The honest status: the Builder is in review, but the multi-tenant layer under it is barely started. 12 of 13 STOR epics are still To Do, including tenant provisioning, branding, domain and SSL, and Arabic and English. That layer is the true critical path to a platform a client can migrate onto.
E-Commerce Solution · What it is · 8 of 15

E-Commerce Core and PIM: the spine under everything

PIM knows what a thing is. The Core knows who is selling it and at what price.

PIM knows what a thing is. The Core knows who is selling it. PIM titles, images, specifications, variants, categories and the attribute schema per category. One record per real-world product, shared by every seller. E-Commerce Core offers against those products: price, stock, ship-from, seller quality. Offer CRUD, inventory per offer, sales-channel isolation. Seller Portal lists and prices Storefront searches and sells B2C Super App the same catalogue OMS and Fulfilment read the offer that won One integration boundary instead of many. A surface never reads PIM directly and never holds its own copy of price or stock, so a change lands once and every surface sees it. PIM is live on MedusaJS at 10,000+ SKU capacity. The Core is building.
E-Commerce Solution · Main use cases · 9 of 15

Fulfilment Service: the router, not the courier

It takes an approved order from OMS and decides who fulfils it. It ships nothing itself.

The router between an approved order and every way of shipping it physical OMS hands over an approved order, and nothing else Fulfilment Service asks two questions, in this order, then routes 1 · Digital or physical? a code can never be shipped Gift card route digital only. Issued, never shipped 2 · Where did the item come from? the source is stamped on the order line at creation OTO Seller Portal items. 200+ GCC carriers behind one API MGC Online Catalogue items. Legacy, dies 31 Oct It ships nothing itself. That is the point: providers are adapters behind one interface, so adding STC, SACO or Salasa costs an adapter rather than a rewrite of the order layer. The OTO path sits behind a per-environment toggle, so rollout reverses with no deploy and no stranded orders. If either answer is unknown it falls back to MGC and is logged. DEC-0137, 12 August.
Recorded as DEC-0137 on 12 August: OMS hands to the fulfilment service, and never calls OTO itself.
E-Commerce Solution · Main use cases · 10 of 15

OMS: seven states, and nothing moves outside them

The enforcement layer. Valid statuses, legal transitions, authorised actors, and nothing else.

Seven states, and nothing moves outside them DRAFT record created, no payment yet PENDING checkout submitted CONFIRMED payment.completed received FULFILLED every line item done. Terminal. FAILED payment.failed. No funds taken. CANCELLED timeout, all items cancelled, or admin REFUNDED payment.refunded, from CONFIRMED or FULFILLED Line items UNFULFILLED, FULFILLED, CANCELLED, tracked separately The enforcement layer: the valid statuses, the only legal transitions between them, and the actors authorised to trigger each one. No code path can put an order anywhere else. Actors: source platform, payment service, downstream service, the SLA engine and cron, and Merit admin through LiveOps. The order only reaches FULFILLED once every line item does, and item status is owned by the downstream service, not by OMS. The SLA engine is the watchdog beside it: it watches how long an order has sat in a non-terminal state and escalates or cancels when the threshold breaks.
Status: in final integration, hardening through Q3.
E-Commerce Solution · What it is · 11 of 15

Product versus Offer, the idea everything else follows from

Amazon works the same way. Get this and the Buy Box, catalogue quality and seller onboarding all explain themselves.

One product, many offers, one winner filtered out Product title, images, specs, variants. One record per real-world thing, shared by every seller. Lives in PIM. Offer · Seller A SAR 1,150 · 37 in stock · live API feed Offer · Seller B SAR 1,090 · stock from a spreadsheet Offer · Seller C SAR 1,180 · 20 in stock · decrement on Buy Box picks one the shopper sees one page and one price Because products are shared, a seller cannot just create a record and price it, or the catalogue fills with duplicate phones and the model collapses. So every upload is matched: exact string match first (live today), then an AI judgement returning approved, not confident, or different product. The not-confident bucket is where ops time goes, and it is the obvious place for a better model to pay for itself.
E-Commerce Solution · What it is · 12 of 15

The Buy Box, locked 28 July

When four suppliers sell the same variant, something has to pick one. Phase 1 is backend only, so the shopper sees no change.

The Buy Box, locked 28 July. Phase 1 is backend only Every offer on the same variant Gate 1. Trusted stock live API feed, or inventory decrement on. A stale spreadsheet cannot win. Gate 2. In stock zero-stock excluded Rank 1 lowest price Rank 2 fewer cancellations, inside a 2% band Winner carried into fulfilment Tiebreak: lowest price, then fastest dispatch SLA, then a stable identifier so the result is deterministic. If nothing clears the gates, the default supplier takes it. Why trusted stock is a gate and not a ranking factor: two suppliers drive most of our out-of-stock incidents, both are API-connected, and both report stock that turns out to be wrong. An offer whose stock cannot be trusted is not a cheaper offer. It is a future cancellation.
E-Commerce Solution · Main use cases · 13 of 15

One order, end to end

The Al Fursan retail flow, which is the hard case: physical goods at scale.

One order, end to end 1. Browse PDP from PIM, winning offer's price, estimated miles 2. Choose how to pay all card, all points, or a split on the slider 3. Revalidate price and stock checked live, Buy Box picks the supplier 4. Payment cash leg to the gateway, points leg burned via Point Exchange 5. OMS created PENDING, CONFIRMED on payment 6. Route direct API, self-shipping partner, or nearest store by coordinates 7. Fulfil seller picks and packs, TMS makes the label via OTO 8. Deliver a carrier from the 200+ GCC network, tracking back onto the order 9. Return window earn sits Pending. A return inside it voids the earn. 10. Points credited earn Released, pushed to the client's loyalty system Stock is reserved when the item enters the cart, released on abandonment, and decremented synchronously and idempotently at placement. The member sees the credited points in the client's own account view, never in a Merit surface. Digital goods skip fulfilment, logistics and delivery entirely, so steps 6 to 8 do not apply. Most clients other than Al Fursan are gift-card only, which is why they are far simpler to run.
Two variants worth knowing. Digital goods skip fulfilment, logistics and delivery entirely, and most clients other than Al Fursan are gift-card only, which is why they are far simpler to run. And in the Entertainer model the merchant sits inside the flow: the customer submits a booking request, the merchant approves, rejects or edits it in a web point-of-sale queue, and only then is payment taken. That ordering exists because the merchant is selling capacity, not stock off a shelf.
E-Commerce Solution · What it is · 14 of 15

Payments and points, the part Shopify cannot replicate

This is the reason clients sign.

  • Points only. The whole basket paid in points, burned through Point Exchange, no cash leg.
  • Mixed payment. Points and card in one transaction, split on a slider. Our proprietary piece. It removes the wall that stops a member redeeming on a high-value item when they are slightly short.
  • Earn on purchase. The member earns back on what they actually paid, held Pending through the return window, then credited. That is what closes the loyalty loop.
  • Rate lock at fulfilment. The earn rate applied is the rate at fulfilment, not at browse time. It protects the value promised on the product page from an admin changing the rate mid-order.
  • Merit validates, because the client often will not. Some client loyalty APIs mint points on request with no double-entry ledger and no verification. If you can call it, it creates. So the guardrails have to live on our side, which is also why clients push fraud control down to the redemption layer where we sit.
  • A fourth pattern with no points at all. Bank offer redemption, the SAIB case. Eligibility comes from holding the card, the discount applies at the merchant, and the control is a cap of one use per customer per month, verified with an outlet code.
The Cash plus Miles slider on the Al Fursan product page
Mixed payment, as the member meets it
E-Commerce Solution · Who uses it · 15 of 15

The names you will hear in every standup

Clients first, suppliers second, and STC sitting on both sides.

  • Al Fursan. Saudia's loyalty programme. The flagship and the most complex. Physical goods and gift cards, Apple Store, earn model. We build and operate their storefront.
  • Entertainer, SAIB, Nielsen and Kantar. An embedded transactional marketplace inside Entertainer's app. Entitlement-based offer redemption for SAIB on the Aseel Marketplace. Gift cards as survey incentives for the research firms, no points programme involved.
  • STC, on both sides. A client for Qitaf points, and a supplier as the official Apple distributor for the Al Fursan Apple Store.
  • Also live or in pipeline. MCM Credit Libanais and Mastercard as Old World marketplace tenants. Bank al-Etihad, the Jordanian bank, in the e-commerce pipeline. Note that is the bank, not the airline.
  • Suppliers. Almania and Just Lounge, both API-connected and both heavy out-of-stock contributors because the data is unreliable. Just Lounge's continued place in the network is under discussion. Aleph, manual with decrement on. Salasa for fulfilment, modelled as a supplier rather than an OTO replacement. OTO for logistics aggregation, not goods. Then a long tail of roughly eight manual suppliers, Tokyo Games, Jasani, SMEG, Toys R Us and Sun and Sand among them.
SAIB offer redemption screen, entitlement based rather than points based
SAIB, entitlement redemption. No points involved

B2C Super App

The consumer front door is live and shipping. The constraint is market access, not engineering.

E-Commerce Solution

Merit's main business. Currently rebuilding itself underneath clients who are transacting on the old one.