Merit product showcase, Amman on-site, August 2026
Brian Arfi Faridhi, Product Director. Review copy, one card per slide, speaker note underneath.
B2C Super App
The consumer front door is live and shipping. The constraint is market access, not engineering.
6 slides ยท Merit is a loyalty stack.
B2C Super App · 1 of 6 · What it is
Merit selling directly, instead of through a client
A phone app that turns loyalty points you cannot use into money you can spend.
One balance. Points from banks, airlines and retailers land in a single wallet with a SAR value next to them.
One checkout. Pay with points, with a card, or with both. Digital goods arrive instantly, physical goods ship.
Merit's only direct consumer relationship. Everywhere else a client owns the member and the branding. Here we own both.
Same engine underneath. Same supplier network and the same commerce core as the E-Commerce Solution. The app is a different surface, not a different stack.
Live on both stores. Android on Google Play. iOS cleared App Store review on 13 August and is eligible for distribution.
React Native client on Merit backend services. Board MBA.
Say it like this: Open by holding up your phone. This is the only Merit product a member of the public can download.
B2C Super App · 2 of 6 · Why we are doing this
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.
The app says the proposition better than we can
Say it like this: The number to say out loud is 10,000 downloads and $100K GMV in the first quarter after launch. Small on purpose. This is a proving quarter, and it starts this month.
B2C Super App · 3 of 6 · New or existing
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.
Registration. Sign-up needs an SMS one-time password. Firebase Auth hardcodes SMS, and delivery outside KSA and UAE needs per-country telco registration and sender formatting Merit has not done.
Payment. Moyasar, our gateway, declines non-KSA and non-UAE. This is what has held the Jordan market, not the app build.
In flight against both. Reverse WhatsApp OTP, on Firebase Cloud Functions plus Firestore, estimate due Monday 17 August. Multi-currency Tier 1, digital-only and tax-exempt, designed, Phase 1 sized at roughly two to two and a half weeks.
Shipped this week. Guest browsing, 13 tickets, cleared Apple's 5.1.1(v) rejection. Guest checkout phase 2, MBA-336, waits on the guest order-create path in the new OMS.
Storefront will hit the same authentication wall. The OTP fix is not a B2C-only fix.
Say it like this: This is the honest slide. Do not let anyone leave thinking expansion is an engineering backlog item.
B2C Super App · 4 of 6 · Main use cases
Four jobs, in the order a user meets them
Transactions, product detail, cart, done
See what I have. Every linked programme in one dashboard, each balance converted to SAR so the user finally knows what the points are worth.
Spend it on something instant. Gift cards and digital goods, delivered to the app in seconds. This is the habit-forming loop.
Spend it on something real. Physical goods marketplace, live inventory from PIM, seller ratings, delivery to the door.
Pay however I want. Points, card, or a split of both on the mixed payment slider, confirmed with biometric Merit Verification.
Next. QR scan to pay in store, and person-to-person point transfers. Both are Q3 and both are large.
Say it like this: The line that lands: points buy a washing machine, not just a voucher. And if you demo one thing, demo the mixed payment slider.
B2C Super App · 5 of 6 · Main use cases
Buying with points, the five screens end to end
Entry to ledger, in the order the member meets them.
Entry, product, cart, paid, ledger
Entry states the proposition. Points into real purchases. Nothing has to be explained before the first screen.
Price in two units. Points and riyals on the same line, with the member's balance beside them. The member never converts anything in their head.
Balance is checked before checkout opens. A member does not reach payment on an order they cannot pay for.
The ledger closes the loop. Earn and burn in one history. That is what makes the balance believable to a member who earned the points somewhere else.
Say it like this: Walk the five screens rather than talking about them. The one to slow down on is the product page, because the price in points and in riyals at the same time is the whole product in one line.
B2C Super App · 6 of 6 · Who uses it
Consumers in KSA and UAE, and the six of us who build it
Outside. Consumers in Saudi Arabia and the UAE. Anyone holding bank, airline or retailer points and no good way to burn them.
Inside. Merit staff, on the internal points pilot. Colleagues outside KSA and UAE cannot register, which is the OTP problem meeting us in our own building.
The team. Mudassar Raza on the React Native client. Zarar Tahir on payment and B2C backend. Hassan Ahmad on backend. Kinza Hanif on QA. Osaid Tahir and Bilal Khalid on design. Khawar Rasheed co-ordinating delivery.
Where the work lives. Jira board MBA. Product owner Brian Arfi Faridhi.
New joiners: this is the smallest surface to learn on, and the fastest to ship into.
Say it like this: Name every person. Half the room has not met them.
E-Commerce Solution
Merit's main business. Currently rebuilding itself underneath clients who are transacting on the old one.
15 slides ยท Merit is a loyalty stack.
E-Commerce Solution · 1 of 15 · What it is
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.
What the client gets. A branded marketplace launched on our stack in weeks. Supplier network, catalogue, orders, logistics, payments and settlement, none of which they build.
What happens. The member burns points, Merit fulfils the order, and Merit and the client split the profit on the goods sold.
Why Shopify cannot do this. It has no idea what a loyalty ledger is.
Why Talon.One and Open Loyalty cannot do it either. They have no catalogue, no storefront and no fulfilment.
The wedge. The end-to-end combination, anchored in MENA logistics.
Say it like this: If a new joiner remembers one slide, make it this one. Say the Shopify line, it lands every time.
E-Commerce Solution · 2 of 15 · What it is
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.
Seller Portal. How a supplier lists, prices and fulfils. The supply side.
Storefront. How a shopper searches, buys and pays. The demand side, in the tenant's brand.
Storefront Builder. How a tenant creates and configures its own store, with no engineering per tenant.
E-Commerce Core and PIM. What a product is, who is selling it, and at what price. The spine every surface talks to.
Fulfilment Service. Who fulfils an approved order, and through which courier network.
OMS. What state the order is in, and which transitions are legal.
Say it like this: Give the room the map before the parts. The sentence to land is that every surface on the left talks to the Core and to nothing else. That single rule is what makes tenant number two cheap.
E-Commerce Solution · 3 of 15 · Why we are doing this
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.
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.
Say it like this: This is the number for the whole showcase. Everything after it exists to make this arithmetic possible.
E-Commerce Solution · 4 of 15 · New or existing
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. Serves every paying client today. Runs all live clients including Al Fursan, the biggest and the most complex. Built business-led with no product team steering it, so the architecture accumulated rather than being designed.
What that costs. Out-of-stock incidents, order failures and heavy manual ops. No Seller Portal at all, so suppliers cannot self-serve.
New World. No live client yet. Modular services: E-Commerce Core, PIM, OMS, TMS, Seller Portal, Storefront Builder. Designed around product versus offer from the start.
The structural problem. You cannot freeze the old platform while you rebuild. Clients are transacting on it, so it keeps adding features. The new platform has to rebuild everything and catch up to a target that is still moving. This is the constraint behind every date on this roadmap.
Say it like this: Say the structural problem in your own words and do not soften it. Engineers already feel it, and naming it buys credibility for everything after.
E-Commerce Solution · 5 of 15 · Main use cases
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.
Category drives the schema, then the offer
List. Web form for one product, bulk CSV for many, SFTP and API for enterprise. Everything matched into PIM on the way in.
Price and stock. Inline editing against guardrails, low-stock alerts, differential updates for the big sellers.
Fulfil. Order arrives, seller accepts, prints a pick list and packing slip, TMS generates the label through OTO. Customer identity is masked unless the seller is a trusted self-shipper.
Get paid. Payout after delivery net of commission, escrow hold, settlement ledger, seller statements. Q3.
Why it delivers before the migration finishes. It connects back into the Old World, so sellers get self-service now rather than in December.
What is still manual. Self-onboarding is proposed but gated on two-way online-catalogue sync. Without that a newly onboarded seller still creates products by hand on the catalogue side, which makes the improvement pointless.
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%.
Say it like this: Big suppliers come through the same door. STC, the official Apple distributor in Saudi, integrates here rather than into the old catalogue. That is the proof the abstraction holds.
E-Commerce Solution · 6 of 15 · Main use cases
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 Store, product page to order placed
What it is. Search, listing pages, product pages, cart and mixed-payment checkout, rendered in the client's brand on the client's domain, Arabic or English.
Why it is a component and not a product. It is one surface onto the same catalogue, core and OMS that the B2C app and Seller Portal talk to. Treating it as its own product is how you end up building the stack twice.
Search is launch-critical. Typo-tolerant query understanding on ElasticSearch plus AI, Arabic first, faceted filtering. Fred ruled it not optional. In progress.
Strict channel isolation. A channel is a distinct storefront or sales environment, and data does not cross between them. This is a hard requirement, not a configuration nicety.
It is live, not a mockup. The Al Fursan Store runs in production at alfursanstore.saudia.com. The UAT copy needs the VPN and the whitelist tool.
Same authentication wall as B2C. Storefront sign-up will hit the SMS one-time password problem the moment we go outside KSA and UAE. The fix is shared, not per surface.
Design: Storefront Builder and Seller Portal both have Figma files. Ask and I will share them.
Say it like this: Say the component line explicitly. It is the point I corrected in the PMO on 13 August and it should not need correcting again.
E-Commerce Solution · 7 of 15 · Main use cases
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.
What a tenant does in it. Create the store, set branding and domain, scope which slice of the catalogue they sell, configure tiers and billing, preview in a sandbox, publish.
Why it is the highest-leverage thing on the map. Every hour of engineering time a new tenant costs is an hour that does not scale. The Builder is what converts a launch from a project into a form.
The arithmetic it unlocks. 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.
Status, and the honest version. The Builder is in review, but the multi-tenant layer underneath it is barely started: 12 of 13 STOR epics are still To Do, including tenant provisioning, branding, domain and SSL, and Arabic and English. This is the true critical path to a platform a client can migrate onto.
Interim. Tenant provisioning is manual by design through July and August. Self-serve, STOR-1, is the September target and runs through Superplatform.
Say it like this: If someone asks what one thing would most change our 2027, this is the honest answer.
E-Commerce Solution · 8 of 15 · What it is
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 holds the product. Titles, images, specifications, variants, categories, and the attribute schema per category. One record per real-world product.
The Core holds the offer. Price, stock, ship-from, seller quality. Offer CRUD, inventory per offer, and strict sales-channel isolation.
Why they are one component here. Neither is useful alone. A product with no offer cannot be bought, and an offer with no product has nothing to describe.
One integration boundary, not many. A surface never reads PIM directly and never keeps its own copy of price or stock. A change lands once and every surface sees it.
Status. PIM is live, on MedusaJS, 10,000+ SKU capacity. The Core is building.
Say it like this: If somebody asks why the Core exists at all, the answer is the arrow count. Without it, every surface integrates with every service, and adding the seventh surface means touching all of them.
E-Commerce Solution · 9 of 15 · Main use cases
Fulfilment Service: the router, not the courier
It takes an approved order from OMS and decides who fulfils it. It ships nothing itself.
Question one, digital or physical. A gift card, voucher or code always takes the gift card route. OTO is a shipping aggregator and cannot fulfil a code.
Question two, where the item came from. Sourced from Seller Portal it goes to OTO. Sourced from the Online Catalogue it stays on MGC. The source is stamped on the order line at creation.
Why a router and not a direct call. Providers are adapters behind one interface. STC, SACO and Salasa each cost an adapter rather than a rewrite of the order layer.
Rollout reverses without a deploy. The OTO path sits behind a per-environment toggle. Turn it off and everything falls back to MGC, with no stranded orders.
The real clock. MGC's Aurora database reaches end of life on 31 October. That date, not the roadmap, is what makes this urgent.
Recorded as DEC-0137 on 12 August: OMS hands to the fulfilment service, and never calls OTO itself.
Say it like this: The line to say out loud is that this is an extraction, not a green field. Phase 1 lifts vendor-selection logic that already sits inside OMS out into its own service.
E-Commerce Solution · 10 of 15 · Main use cases
OMS: seven states, and nothing moves outside them
The enforcement layer. Valid statuses, legal transitions, authorised actors, and nothing else.
The states. DRAFT, PENDING, CONFIRMED, FULFILLED, CANCELLED, FAILED, REFUNDED.
How an order moves. Created at PENDING. Moves to CONFIRMED on the payment.completed event, not on anyone's say-so.
Line items are tracked separately. Each item carries UNFULFILLED, FULFILLED or CANCELLED, and the order only reaches FULFILLED once every item does.
Who is allowed to trigger what. Source platform, payment service, downstream service, the system's own SLA engine and cron, and Merit admin through LiveOps. The actor list is part of the spec.
What hangs off it. SLA engine, refunds, settlement hooks, and the fraud screening call that will sit before fulfilment.
Status: in final integration, hardening through Q3.
Say it like this: Engineers will want the state diagram. The PRD is PRD_OMS_Order_State_Machine_v2, offer to walk it with anyone who asks. Do not quote a live sprint number from the board, it will have moved by the time you present.
E-Commerce Solution · 11 of 15 · What it is
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.
Product. What the thing is. Title, images, description, specs, variants. One record per real-world product, shared by every seller who sells it. Lives in PIM.
Offer. What one seller will do. Price, stock, ship-from location, seller identity, seller quality. Many offers can attach to one product. Lives in E-Commerce Core.
What a shopper sees. One iPhone page. Behind it, four suppliers with four prices and four shipping costs. The content is identical, the commercial terms are not.
Why this makes onboarding hard. A supplier cannot just create a product record and price it. The catalogue would fill with duplicate phones and the model collapses. Every upload has to be matched against what already exists.
How matching works. Exact match first, regex and string, live today. AI match second, judging same-thing or not, returning approved, not confident, or different product. In development and deliberately kept light. The not-confident bucket is where ops time goes.
Say it like this: Draw two boxes on the whiteboard. Product on the left, three offers hanging off it on the right. Thirty seconds, and it sticks for good.
E-Commerce Solution · 12 of 15 · What it is
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.
Gate 1. Trusted stock. Only offers from suppliers whose stock updates automatically are eligible. An API-connected live feed, or inventory decrement switched on. A stale spreadsheet cannot win.
Gate 2. Availability. Zero-stock offers are excluded.
Rank 1. Price. Lowest first.
Rank 2. Cancellation rate. Inside a 2% price band, the supplier who cancels less wins. Cheapest is worth little if the order dies later.
Tiebreak and fallback. Lowest price, then fastest dispatch SLA, then a stable identifier so the result is deterministic. If nothing clears the gates, the configured 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 have API integrations, and both report stock that turns out to be wrong, which puts ops on daily spreadsheet reconciliation. An offer whose stock cannot be trusted is not a cheaper offer, it is a future cancellation.
Say it like this: The last bullet is the one to land: it is a product decision that reads as a technical one. State it, do not open it for debate here, the workshop is the room for that.
E-Commerce Solution · 13 of 15 · Main use cases
One order, end to end
The Al Fursan retail flow, which is the hard case: physical goods at scale.
Browse and choose how to pay. Product page from PIM with the winning offer's price, and estimated miles where an earn model is live. All card, all points, or a split on the slider.
Checkout validation. Price and inventory revalidated against the supplier in real time. Buy Box picks the winning offer per variant and carries the supplier forward so fulfilment knows who owes the goods.
Payment. Cash leg through a gateway such as Moyasar. Points leg through the payment service to Point Exchange, which burns them. Stock reserved at cart, released on abandonment, decremented synchronously and idempotently at placement.
Order and routing. OMS creates at PENDING, confirms on payment. The order routes to the winning supplier: a direct API call, a self-shipping partner, or a coordinate-gated model that picks the nearest store by geolocation.
Fulfilment and delivery. Seller picks and packs from Seller Portal, TMS generates the label through OTO, a carrier from the 200+ GCC network delivers, tracking flows back onto the order.
The return window, and only then the points. Earn sits Pending for the window. A cancellation or return inside it voids the earn entirely. Window closes, earn moves to Released, points push to the client's loyalty system through its API, and the member sees them in the client's account view, not ours.
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.
Say it like this: Walk this left to right on the whiteboard. It is the single most useful thing a new joiner can hold in their head.
E-Commerce Solution · 14 of 15 · What it is
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.
Mixed payment, as the member meets it
Say it like this: The minting line always gets a reaction. It is the clearest example of why this business needs guardrails we own.
E-Commerce Solution · 15 of 15 · Who uses it
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, entitlement redemption. No points involved
Say it like this: Being frank about Almania and Just Lounge is the point. It is why the Buy Box has a trusted-stock gate.
