Merit · Al Fursan · Apple Store · Supplier integration
The Apple Store launches on 2 September with STC as the supplier. STC holds stock per city, our marketplace sells as if stock were national. This page walks the order flow, then lets you set the conditions and see exactly what the buyer gets.
Neither side is wrong. They were built for different things, and the Apple Store is the first place the difference costs us money.
2 Sep
Launch date. Fixed. Apple and Al Fursan are both watching it.
5 to 10%
Expected order cancellations on the manual fallback path. Working estimate, not measured yet.
4
Questions STC has not answered. One of them decides the whole design.
Where the two models split
| Question | Merit marketplace today | STC as supplier |
|---|---|---|
| Is this product available? | Yes, if any city has stock | Only if the buyer's own city has stock |
| When is stock checked? | At checkout, after the buyer has already chosen and committed | Expected before the order is placed, as a separate availability call |
| Who fulfils? | Decided once, at listing time | Varies by city and warehouse |
| What if it is gone? | Order fails late, money is already taken, refund follows | The order should never have been accepted |
A Riyadh buyer can browse, add to cart, pay, and only then be told the item is not available to them. That is a refund, a support ticket, and a bad first impression on the store Apple is watching.
We asked STC for cross-city fulfilment, meaning they ship from another city when the buyer's city is dry. That single answer removes most of this page. STC has not confirmed it is supported, and until they do we have to design as if the answer is no.
Same journey the buyer already takes. The only new thing we are proposing is one call, at one point.
Buyer journey, with the stock checkpoints marked
The proposed change costs a loading spinner on the checkout button and one API call. It does not move the checkout, does not change the cart, and does not touch the product page. Whether it can be done without a marketplace platform change is the question for Aditya.
Set the four conditions on the left. The right side is what the buyer sees, what ops has to do, and what it costs us. Every combination below is a real state we can be in on 2 September.
Condition 1
Does STC have the item in the buyer's city?
Condition 2 · unanswered by STC
Has STC confirmed cross-city fulfilment?
Condition 3
Does Aleph have the item?
Condition 4 · our decision
Did we build the checkout stock validation?
Condition 2 is the one worth staring at. Set it to "Confirmed" and every red outcome on this page disappears, which is why the unanswered question matters more than anything we can build.
Blocking the order at checkout saves the refund. It does not save the experience. The moment the buyer is turned away, three things are true at once, and the third one is the real damage.
What the buyer is holding, one second after being refused
The item is not out of stock. It is out of stock for them, which is a different sentence with a different set of exits. Saying the true thing costs a copy change and turns a dead end into a choice.
Out of stock
This item is currently unavailable.
Untrue, unactionable, and contradicted by the page they came from. Their only move is to try again.
We cannot deliver this to Riyadh right now
The item is in stock, but not in a warehouse that serves your city. Here is what we can do.
True, specific, and it gives the intent somewhere to go. The "notify me" list also becomes the demand signal we take back to STC.
Ordered by what it costs us, not by how good it is. The good ones are at the bottom and none of them land by 2 September.
The same validation call, fired the moment the buyer enters or picks a delivery city, rather than when they submit the order. Nobody types card details for an order that was never going to complete.
Trigger point, not new code. The call is already in the proposal. This only moves when it runs.
The message above. Notify me when it reaches my city, deliver to another city, or see alternatives. The notify list doubles as a demand signal for the STC conversation.
Copy plus one small UI block. "Notify me" needs somewhere to store the request, which is the only real work here.
Once we refuse an item for a city, we know something the catalogue does not. Hold it on the session and grey that item out on the list and product pages from then on. It never contradicts itself twice.
A session-level exclusion list. No catalogue change, no platform change, no stock feed. It is a patch, and it is honest about being one.
The product page checks the buyer's city on load and says "available in Riyadh" or "not available in Riyadh" before they ever reach the cart. The rejection stops happening rather than being handled.
Needs stock per city, so it needs R7 and a working STC API. Whether it can be scoped to one store or forces a platform change is the question for Marketplace.
Availability stops meaning "somewhere in the country" and starts meaning "where you are". The item never appears in the list, so there is nothing to contradict. This is the correct answer.
A marketplace platform change, which is the one thing Akshay says breaks the date. It also inherits a cache question: a list page served from cache lags the truth however correct the model underneath is.
Ship A, B and C together for 2 September. They are one trigger change, one copy change and one session flag, none of them touch the catalogue, and together they turn the worst case from "the store is broken" into "the store told me the truth and gave me an option". Then D in September, once STC answers R7 and fixes the API. Then E as the proper fix, scoped as its own piece of work rather than smuggled into a launch.
Be clear on what this buys: A, B and C do not fix the first encounter. A buyer can still reach checkout for something they cannot have. They fix the contradiction, the repeat, and the silence. Only D and E stop it happening at all.
All of the above assumes we launch the full catalogue. We could instead launch with only the items Aleph can back nationally, so the rejection path is rare on day one, and widen the catalogue as STC coverage becomes known. A smaller Apple Store that always works beats a complete one that cancels one order in ten. This is Rahul's call, and it is not currently on the table.
Whatever we ship, log every rejection with the city, the item, and whether Aleph could have covered it. The 5 to 10 percent is a guess, and two weeks after launch it should be a measurement. That log is also the evidence we take to STC when we ask again for cross-city.
Their API returns an HTML error on every call except authentication, so our engineers cannot test and cannot answer these themselves. That is the reason this list is still open.
Cross-city fulfilment
Blocking · decides the design
If STC ships from another city when the buyer's city is dry, we need no Aleph fallback, no manual redirect, and no cancellation risk. We accept a longer delivery SLA and we are done. If not, everything in section 3 applies.
The broken API
Blocking · stops us testing
Authentication succeeds, so the server does see us. Every other call returns HTML instead of JSON, from cURL and from Python alike. Until this is fixed we cannot verify anything below, so every other answer stays theoretical.
R7, the product identifier
Blocks catalogue mapping
We cannot map STC items to our catalogue without knowing what this field is and what it keys to. No mapping means no stock lookup, whatever the flow.
Which price the buyer pays
Blocks pricing
STC returns net price, net price with flat and gross price. We do not know which one is customer facing. Guessing wrong prices the Apple Store wrong on day one.
Order statuses
Blocks order handling
We need the definition of "partially completed" for multi-item orders, and confirmation that "aborted" is terminal. Without it we cannot tell a stuck order from a dead one.
Tracking for cross-city shipments
Blocks buyer visibility
The STC API gives status updates but no tracking URL. If a cross-city order ships via a third party, we need to know whether a tracking link comes back that we can pass to the buyer.
Phone number format is confirmed: 966 followed by the number, with no plus sign.
Four people, four calls, one hour. If we cannot close these, the 2 September date is at risk and it gets escalated the same day.
R7, and the price fields go back in a single message with a deadline attached, rather than four people chasing separately.The 5 to 10 percent cancellation estimate is a working figure from the 19 August session, not a measurement. Nothing here assumes STC has confirmed cross-city fulfilment, because they have not. The proposed checkout validation has not been sized by Marketplace yet, which is the point of the meeting.
Merit · Al Fursan · Apple Store supplier integration · 20 August 2026
Sources: Merit x STC Channels, technical, 19 Aug · Internal fallback strategy session, 19 Aug