Merit · Product · Internal Explainer
Merit turns loyalty points that people cannot spend into things people actually want to buy. The E-Commerce Solution is the machine that does it. This page starts at the one-paragraph version and ends at the order state machine.
If you only read one section, read this one.
Airlines, banks and telcos hand out loyalty points. Those points sit in member accounts unspent, which is a liability on the balance sheet and a dead experience for the member. These companies want to let members redeem points for real products, but running commerce is heavy: sourcing goods, warehousing, shipping, handling returns, and reconciling a payment that is half points and half card.
Merit is the managed commerce layer that sits in that gap. We bring a network of suppliers and a full commerce stack, and a client can launch a branded marketplace on top of it in weeks. Members burn points, Merit fulfils the order, and Merit and the client split the profit on the goods sold.
Off-the-shelf platforms like Shopify cannot do this, because they have no idea what a loyalty ledger is. Loyalty engines like Talon.One or Open Loyalty cannot do it either, because they have no catalog, no storefront and no fulfilment. Merit's wedge is the end-to-end combination, anchored in MENA logistics.
Most of Merit's revenue comes from the E-Commerce Solution. It is the commercial engine, not a side bet.
Subscription plus a commission on GMV, plus a goods margin where Merit is Merchant of Record.
16 large tenants and 100 sellers, roughly $869.2K per month recurring at OKR close.
Three roles, and the vocabulary is genuinely confusing on day one because internal teams use the same word differently. Here is the version to hold in your head.
The end customer is the client's member. They never see Merit branding. They see the Al Fursan store, or the Entertainer app, and they think they are shopping with that brand.
Platform engineering calls everyone on the system a "tenant", including sellers, because everyone holds a licence. Product uses "client" or "tenant" for the points owner and "supplier" or "seller" for the goods owner. When someone says tenant, check which side they mean.
Merit selling directly to consumers instead of through a client. Same supplier network, same commerce core underneath. It exists so Merit builds a moat it controls, because B2B sales cycles are long and the client owns the relationship.
Burns and converts points across programs. It is a capability other products call, reached through the payment service at checkout. It is not something a client buys on its own.
One login with biometric auth that follows a user across the ecosystem. SSO into a tenant storefront is one of the launch gates.
Five earning layers. Two of them behave like software and three behave like retail, and they must never be blended in a P&L.
| Layer | What it is | Margin character |
|---|---|---|
| SaaS platform fee | Recurring subscription per tenant, indicative $500 to $20,000+ per month by tier | Software, target ~80% GM |
| GMV commission | Take rate on transaction value, roughly 1% to 3% descending by tier | Software, target ~80% GM |
| Goods margin | Wholesale versus retail spread where Merit is Merchant of Record | Retail, indicative 8% to 20% |
| Interchange and FX | Thin margin on the cash leg of a mixed payment and on cross-currency settlement | Thin but high margin |
| Ad placements | Suppliers pay for featured slots. Dynamic slot auction planned 2027 | Future state |
On the client side, the profit on goods sold is shared with the client. The member burns points, Merit earns on the product, and the client takes its share. This is why point burn and GMV are the two numbers everyone watches.
Revenue attribution is not settled. Do we book full GMV as Merit revenue under a Merchant of Record model, or only the commission we keep? This changes the headline number, and it has to be resolved before pricing goes public.
The platform is a set of decoupled services behind a white-label storefront. Status is as of July 2026.
| Component | What it does | Status |
|---|---|---|
| PIM Product Information Management | Multi-tenant catalog. Categories, variants, product data and enrichment. Built on MedusaJS, 10,000+ SKU capacity. The single source of truth for what a product is. | Live |
| E-Commerce Core | The orchestration layer between PIM and every consumer or seller surface. Owns the product versus offer separation, offer CRUD, inventory per offer, and sales-channel isolation. One integration boundary instead of many. | Building |
| Pricing & Commission Engine | Commission configs, settlement maths, pricing ledger with audit, preview API. Recalculates commission when a supplier switches at runtime. | Done |
| OMS Order Management System | The state machine of every order from Placed to Delivered. SLA engine, refunds, payment-service integration, settlement hooks. | Final integration |
| Seller Portal | The supply-side front door. Sellers upload products, manage price and stock, process orders, and see payouts. This did not exist in the old platform at all, which is why it was built first. | Live, expanding |
| Storefront | The consumer surface. Search, listing pages, product pages, cart, mixed-payment checkout. Multi-tenant white-label template, Next.js. | ~50-60% |
| Storefront Builder | The control plane a tenant uses to create and configure its own store. Branding, catalog scoping, sandbox, zero engineering per tenant. This is what turns tenant #2 into a configuration exercise. | In review |
| TMS Transportation Management | Delivery orchestration through the OTO aggregator, 200+ GCC carriers behind one API. Auto-shipment, tracking, labels, failed-delivery handling. Replaces the MGC legacy path. | Build starts Q3 |
| Seller Payout & Settlement | Payout after delivery net of commission, escrow hold, settlement ledger, seller statements. | Q3 2026 |
| Search | Typo-tolerant query understanding on ElasticSearch plus AI, Arabic first, faceted filtering. Fred has ruled this launch-critical, not optional. | In progress |
| Notification Hub | Buyer and seller transactional events over push, email, SMS and WhatsApp. Shared platform service. SendGrid is the live connector, SMS is still being wired. | Partial |
| Order Fraud Screening | Real-time allow, review or block before fulfilment. Calls Marthino's risk engine. | To do |
PIM knows what a product is. E-Commerce Core knows who is selling it and at what price. OMS knows what happened to the order. TMS knows where the box is. Seller Portal is how a supplier talks to all of that. Storefront is how a shopper talks to all of that.
The single most confusing thing about Merit for a newcomer, including anything you read on Confluence. Much of that space is written about the Old World and is not marked as such.
You cannot freeze the old platform while you rebuild. Clients are transacting on it, so it keeps moving forward and keeps adding features. The new platform therefore has to rebuild everything and catch up to a target that is still advancing. This is the central constraint on every roadmap date in the E-Commerce Solution.
The core data-model idea. Everything about the Buy Box, catalog quality and supplier onboarding follows from it. Amazon works the same way.
Title, images, description, specifications, variants. One record per real-world product, shared by every seller who sells it. Lives in PIM.
Price, stock, ship-from location, seller identity and seller quality. Many offers can attach to a single product. Lives in E-Commerce Core.
A shopper looking at an iPhone sees one product page. Behind it there may be four suppliers each with their own price and their own shipping cost. The page content is identical, the commercial terms are not.
Because products are shared, a supplier cannot simply create a new product record and set a price. If they did, the catalog would fill with duplicates of the same phone and the model would collapse. So every upload has to be matched against what already exists.
approved, not confident, different product. Currently in development and deliberately kept light.When several suppliers offer the same variant, something has to pick one. That selection is the Buy Box, and the rule was locked on 28 July 2026.
Phase 1 is backend only. The storefront does not change, so a shopper sees no difference. What changes is which supplier's offer the system commits the order to.
Two suppliers drive most out-of-stock incidents. Both have API integrations, and both report stock data that turns out to be wrong, which forces ops into daily manual spreadsheet reconciliation. An offer whose stock number cannot be trusted is not a cheaper offer, it is a future cancellation. So it is filtered out before price is even considered.
The full path from browsing to points landing back in a member account, using the Al Fursan retail flow as the reference case.
DRAFT, PENDING, CONFIRMED, FULFILLED, CANCELLED, FAILED, REFUNDED. The order is created at PENDING and moves to CONFIRMED on the payment.completed event. Each line item separately carries UNFULFILLED, FULFILLED or CANCELLED, and the order only reaches FULFILLED once every item does. Where earn applies, an earn transaction is created in Pending.Pending for its duration. A cancellation or return inside the window voids the earn entirely.Released, and the points are pushed to the client's loyalty system through its API. The member sees them in the client's own account view, not in a Merit surface.Gift cards and e-vouchers skip fulfilment, logistics and delivery entirely. Most Merit clients other than Al Fursan are gift-card only, which is why they are far less complex to run. Al Fursan is the hard case because it is physical goods at scale.
In the Entertainer model the merchant sits in the middle of the flow. The customer submits a booking request, the merchant sees it in a web point-of-sale queue and approves, rejects or edits it, and only then is payment taken. That ordering exists because the merchant is selling capacity, not stock off a shelf.
The part of the stack Shopify cannot replicate, and the reason clients sign.
The whole basket is paid in points. Points are burned through Point Exchange and the order proceeds with no cash leg.
Points and card in a single transaction, split on a slider. This is Merit's proprietary piece. It removes the wall that stops members redeeming on high-value items when they do not have quite enough points.
The member earns points back on what they spend, closing the loop. Earn is calculated from what was actually paid, held pending through the return window, then credited.
There is a fourth pattern that involves no points at all. Bank offer redemption, as in the SAIB case, is entitlement-based: eligibility comes from holding the card, the discount is applied at the merchant, and the control is a one-use-per-customer-per-month cap verified with an outlet code.
Names you will hear in every standup, and what each one actually is.
| Name | Who they are | What they run with us |
|---|---|---|
| Al Fursan | Saudia Airlines loyalty program | The flagship and the most complex client. Physical goods and gift cards, Apple Store, earn model. Merit builds and operates their storefront. |
| Entertainer | UAE membership and voucher business | Embedded transactional marketplace inside their app. Adds a booking and payment layer on top of a paper-voucher model. |
| SAIB | Saudi bank | Offer redemption migrating onto the Aseel Marketplace. Entitlement-based, not points-based. |
| STC | Saudi telco | Appears on both sides. As a client for Qitaf points, and as an Apple distributor supplying the Al Fursan Apple Store. |
| Nielsen and Kantar | Market research firms | Gift cards as survey incentives. No points program involved, they simply need reward supply. |
| Bank al-Etihad | Jordanian bank | E-commerce pipeline. Note this is the bank, not the airline. |
| MCM Credit Libanais, Mastercard | Bank and network | Live marketplace tenants on the Old World. |
| Name | Supplies | Integration |
|---|---|---|
| Almania | General merchandise | API with live stock feed. High out-of-stock contributor despite the integration, because the data is unreliable. |
| Just Lounge | General merchandise | API connected, and the same reliability problem. Its continued place in the network is under discussion. |
| Aleph | General merchandise | Manual, with inventory decrement enabled. |
| STC | Apple products, KSA | Full API. Stock disclosed per city, orders routed by customer coordinates to the nearest store. |
| Salasa | Fulfilment | Modelled as a supplier, not as an OTO replacement. Self-shipping, so Salasa arranges last mile. |
| OTO | Logistics aggregation | Not a goods supplier. 200+ GCC carriers behind one API, replacing the MGC legacy path. |
| Long tail | Toys, electronics, appliances, gifting | Roughly eight manual suppliers including Tokyo Games, Jasani, SMEG, Toys R Us and Sun and Sand, with stock decrement status still being confirmed. |
Concrete openings in this product line, ordered by how ready they are to be worked on.
Deciding whether an uploaded item is an existing product or a new one. Exact match is live, the model layer is deliberately unfinished. Semantic search over the catalog is an obvious extension. Clear ops cost attached, and a clean evaluation target.
An Old World model with reported precision, recall and accuracy all close to 100%, which reads as overfitting. The test set composition is not documented. Worth noting the intent was to reassure clients about redemption risk more than to run a real fraud engine.
Typo-tolerant query understanding on ElasticSearch plus AI, Arabic first. Launch-critical, not an add-on.
Collaborative and content-based recommendation, frequently-bought-together bundling, a personalised feed ranked by purchase history and loyalty tier. Blocked on behavioural data volume, so build starts 2027.
Behavioural tracking is thin today. B2C has not launched so there is no production data, Seller Portal and the dashboards have light tracking only, and Mixpanel is still on a free account. Any metric quoted off a current dashboard should be confirmed with Marthino before it is used. This directly limits what can be trained or evaluated right now.
The terms that will come at you in week one with no explanation attached.