The perfect journey already exists, and SAIB already has it
Today a SAIB cardholder walks into a partner restaurant, eats, and pays with their SAIB card. The discount lands by itself. The customer does nothing. The cashier does nothing. There is no app, no code, no scan and no waiting, and the proof is perfect because the payment itself is the evidence.
That is called card-linked auto-apply, and it took the bank roughly a year to get approved. It scores zero seconds at the counter, and nobody has to verify anything.
Every option on the table is worse than that. This is the honest frame for the whole exercise, and it explains why the bank has made the entire migration conditional on this one journey. They are being asked to accept a downgrade.
Card-linked auto-apply, which is what SAIB runs today. Nobody acts, nobody verifies, and the bank still has a perfect record, because the settled card transaction is the record.
Not "which of these options is nicest." It is: how close to zero can we push counter time and merchant effort, while still producing evidence Merit can stand behind? Everything below is measured against zero, not against each other.
Two different problems have been wearing one hat
Every option designed so far has tried to solve two unrelated problems with a single object: a code. That is why all of them come out mediocre.
Problem 1. Was the customer actually there?
Did this person really walk into this restaurant, or are they claiming a discount from their sofa?
problem
Problem 2. Did they buy anything, and for how much?
Was there a real bill, and what was the total? This is the question the commercial model needs answered.
A printed code is weak evidence of the first and no evidence at all of the second. A code displayed at a till is public, so anyone can photograph it, and no code has ever told anyone the size of a bill.
Separate the two and each gets a proper instrument. That split is what produces the four journeys further down: two of them attack presence, one attacks value, and one gets both for free by going back to the payment rail.
Indonesia solved the presence half at national scale, and the answer is a sticker
QRIS is Indonesia's single national QR payment standard, set by the central bank. The version that matters here is called merchant presented mode, static, and it is disarmingly simple.
The merchant prints one QR code and puts it on the counter. That is the entire merchant setup. No card terminal, no software, no integration, no training beyond "the sticker lives here." The customer does all the work: open whichever payment app they already have, point the camera at the sticker, type the amount, confirm. The merchant is passive. The customer is active.
QRIS merchant presented mode, static. One printed code, unlimited uses, no equipment on the merchant side at all.
42 million merchants
On QRIS by the end of 2025, against a target of 40 million. Around 90 percent are micro and small businesses with no equipment.
59 million users
Also ahead of the 58 million target. This is ordinary behaviour in Indonesia, not an enthusiast feature.
10.33 billion transactions
To September 2025, up roughly 139 percent year on year. The gesture works at a scale nobody can argue with.
Option D in the BRD is exactly this shape, minus the money. The merchant shows a printed code, the customer scans it with their own phone, and nothing is installed anywhere. The only difference is that our scan claims a discount instead of moving a payment. When someone in the room asks whether customers will really scan a code at a till, this is the answer: a country of 280 million people does it 10 billion times a year.
The code is public by design. That is fine for QRIS, because the code only identifies who to pay and the customer still has to authorise money leaving their own account. It is not fine as proof of presence, because a photograph of the code works from anywhere. This is the weakness Option D carries and cannot fix.
Not everyone likes scanning in restaurants. A 2023 survey found 47 percent of respondents uncomfortable using QR codes in restaurants, up from 43 percent, and several operators brought paper menus back over it. The BRD discloses this rather than omitting it, and judges that it transfers weakly, because that backlash is about QR menus, a multi minute browsing task with real accessibility complaints, not one scan to claim a discount. The risks that do transfer are technical: a refused camera permission, poor lighting, a damaged printed code, bad connectivity. That is why manual entry sits under the scanner in every version of this, which is the same fallback McDonald's runs behind its own QR deals.
Indonesia solved the value half too, and the answer is the bill
Grab Dine Out is a restaurant deals feature inside the Grab app, running across tens of thousands of restaurants in 50 Indonesian cities. Careem runs the same pattern in the GCC under the name Dine Out.
The customer claims a deal in the app, eats, and then at the end enters the bill total from the receipt. The app calculates the discounted amount and the customer settles through the app. Because the bill total goes into the system, Grab knows exactly what was spent and exactly what the discount cost.
- Claim the deal in the appBefore or during the meal. Nothing has been spent yet.Customer
- Type the bill total from the receiptThis is the step that changes everything. The value of the transaction enters the system.Customer
- The app calculates the discounted amountPercentage, cap and conditions are all applied by software rather than negotiated at the counter.Platform
- Pay through the appGrab is a payment provider, so it can settle. This is the part Merit cannot copy.Customer & platform
It answers the commercial question that no code can answer: who pays for the discount, and how much did it actually cost. While nothing captures the bill, a percentage discount or a capped discount cannot be reconciled at all. That is not a design preference, it is an accounting requirement, and it is currently an open hole in the SAIB commercial model. Option F below is this shape.
Merit cannot be the one holding the money. Taking payment for a restaurant's sale and passing it on means payout rails to every outlet, chargeback liability on a meal Merit did not serve, and merchant registration with the identity checks attached. The regulator draws its line exactly there: technical linkage and support needs no licence, but contracting with merchants, registering them and running the identity and anti money laundering checks does.
So in options D, E, F and F-lite below, the customer pays the restaurant exactly as they do today, by card, cash or wallet, and what we build sits beside the payment rather than inside it.
But there is a way to have the payment leg, and it is the last option below. The trick is that Merit does not need to move the money, because SAIB already can. It is the customer's own bank, holding the customer's own account, already connected to the national instant payment rail. Provided SAIB is the one initiating the transfer, this stops being a Merit licensing question. If instead Merit had to initiate it, that is a licence application, and which of the two applies is still an open question rather than a settled one.
That is also the answer to the obvious objection. SAIB rejected a six step journey in July that involved scanning a QR code. The objection was never the scan. It was that the customer had to leave the app to pay and then come back. Nothing below touches payment, so that detour does not exist.
Six journeys, ordered by how much they ask of the counter
Two are candidates for the first release. Two are second phase, and one of those needs no merchant build at all. The last two are destinations rather than builds, and both of them are unlocked by the bank rather than by us.
Scan the outlet code
In the BRD today shape: QRISThe customer opens the offer, taps activate, and the camera opens. They scan the QR on the card the cashier holds up. Merit checks the outlet and the entitlement, then records the redemption. The cashier touches nothing and the phone never leaves the customer's hand.
- Open the offer and tap ActivateNothing is spent yet.Customer
- Read the terms screenIt says plainly that the scan spends the offer, not the tap. This one screen is what removes the accidental burn.Customer
- The camera opens and a five minute timer startsThe timer means a screenshot of this screen is worthless later.App
- Scan the code on the outlet cardThe cashier holds up a printed card or points at the one on the till. That is the whole cashier job. Typing the code by hand sits underneath for a dead camera or a damaged card.Cashier presents · customer scans
- Merit checks the outlet and the entitlementRight outlet, right offer, allowance remaining. A failure returns the customer to the start with the offer untouched.Merit
- Confirmed, with outlet, time and a referenceThis is the record the bank needs for reporting and disputes, and it is the thing a simple confirmation screen can never produce.Merit
The printed code is public. Anyone can photograph it once and use it from anywhere. The one offer per customer per month cap limits the damage, it does not close the hole. Rotating the code is the fix, and rotating means reprinting and redistributing a card to every outlet.
There is also an ongoing cost nobody has priced: every outlet must receive its card, keep it, know what it is for, and get a new one when a code changes. That is a rollout programme, a staff turnover risk, and a day one support problem that currently has no owner at SAIB.
Just be there
Recommended for the first release shape: closest to zeroThe customer opens the offer at the restaurant and taps once. The phone confirms it is inside the outlet's boundary, and that is the whole verification. Nothing is printed, nothing is displayed, nothing is handed over, nothing is typed by anybody.
- Open the offer at the restaurantThe app can already show which outlet you are standing in.Customer
- Tap onceThat is the entire customer journey at the counter.Customer
- The phone confirms it is inside the outlet boundaryPresence is measured by the only device at the counter that knows where it is.App
- Confirmed, with outlet, time, location and a referenceA richer record than Option D produces, because it carries location too.Merit
- If location fails, drop to Option D underneathScan the outlet code, then manual entry. Option D is not thrown away, it becomes the second rung. That turns the outlet card programme from a launch prerequisite into optional coverage for hard sites.App
A printed code is defeated by one casual photograph, taken by anyone, needing no skill. A location check is defeated by deliberately faking your phone's location on a modified device. That is a materially higher bar, and it is detectable through the integrity checks a bank app of this type will very likely already carry.
This is also the answer to the request for a one time password. The OTP was proposed to get control. The location check delivers more control, at a fraction of the counter time, with nothing spoken aloud between two people.
Indoor accuracy. Mall restaurants are the hard case. Mitigations to size: a generous radius tuned per outlet, wifi network name as a secondary signal, and a coarse to fine fallback.
Permission refusal. Some customers will not grant location. That needs a graceful path, which is what the fallback ladder above provides.
Sequencing. Getting location permission granted in the first place is a first run problem for the bank's whole app, not just this journey. That belongs to SAIB's app team, and it is a dependency we do not control.
The bill goes in
Phase two, priced separately shape: Grab Dine OutThe customer taps activate and gets a short reference. The cashier, inside the point of sale they are already standing at, opens the Merit tab, reads the reference, types the bill total and confirms. This is the only option that captures what was actually spent.
- Customer taps Activate and gets a reference plus a codeA short number they can read aloud, and a code the cashier can scan.Customer
- Cashier opens the Merit tab inside their own point of saleNot a separate website. This distinction is the whole ballgame, see below.Cashier
- Cashier types the bill total and confirmsThe value of the transaction enters the system. Percentage discounts and caps become computable rather than guessed.Cashier
- Merit records the redemption with the valueOutlet, time, reference, and for the first time the amount. The customer's phone updates.Merit
The bill. Which matters because of a question nobody has answered yet: who funds the discount on offline offers, the merchant, Merit, or a split. Without the bill total, a percentage or capped discount cannot be reconciled at all. This is why F is a commercial decision wearing a user experience costume, and it should not be argued as a journey preference.
This has to be embedded inside the merchant's own point of sale, not a separate website the cashier logs into. Merit already ships an embedded web point of sale with a merchant network in the UAE, so the hard version is not speculative, it is done.
But a standalone portal is the version that fails, and we have that from the merchant network we cite as our own benchmark. On a call in August their head of product said merchants "are on their POS most of the time" and have to "log into, let's say, Merit web POS to accept or reject order," and that "there are too many portals that we are providing to the merchant." Their payments lead added that walking away from the point of sale to open a laptop is a friction point. That is exactly the objection that killed an earlier option, voiced by the people we quote as evidence. Present F as embedded, never as "log into our portal."
The same thing, over WhatsApp
Coverage layer and pilot vehicle shape: F, without the integrationOption F is parked for one reason only: the merchant surface needs building into each point of sale platform. But the merchant surface does not have to be a point of sale at all. Every restaurant already has a phone number and an email address, and Merit already runs the infrastructure to message both.
- Customer enters the bill totalFrom the printed receipt. On its own this would be self reported, which is why the next step exists.Customer
- The outlet gets a WhatsApp or an emailBill, discount, what the customer should pay, and a one tap link. No app, no login, no installation, nothing bought.Merit
- Cashier taps confirmOne tap ratifies the amount the customer declared. That is what turns a claim into a record.Cashier
- Merit records the redemption with the valueOutlet, time, reference, and the bill. Same record Option F produces.Merit
- Customer pays the restaurant as normalCard, cash or wallet, straight to the merchant. Merit never touches the money, which is what keeps this out of licensed territory.Customer
It is not a replacement for Option F, it is the coverage layer underneath it, the same way Option D sits underneath Option E. Embedded is better wherever the integration exists, because a tab the cashier is already looking at beats a message they have to notice. F-lite is how you reach the outlets that integration will never cover, and how you pilot value capture before committing to a point of sale build at all.
Merit is not starting from zero here. The Communication Hub is a working pub and sub transmitter already sending email through SendGrid, with WhatsApp and SMS being added as channels on the same architecture, shared across tenants. It was written up for a different client, but it is platform infrastructure rather than one client's feature.
It is probably the slowest option here apart from The Entertainer. Removing the integration cost does not remove the wait. It may increase it, because the cashier has to notice an incoming message rather than glance at a screen already in front of them. The 30 to 60 seconds above is a guess and needs measuring before anyone repeats it.
Whose phone is it. A shared restaurant number, a handset in the back office, a shift that changes. This lands straight on the weak point already named in the journey work: the merchant staff, not the app and not the interface.
A notification is not a confirmation. The one tap link is a small web page, so this is a lightweight merchant surface delivered over WhatsApp rather than no merchant surface at all. That is fine, but it should be costed as a build and not as a message.
Collusion is the open fraud question. A cashier confirming an inflated bill is the failure mode, and it is a commercial and audit problem rather than a technical one. Worth naming rather than discovering.
Pay in the app, straight from the SAIB account
Strongest design, bank side build shape: QRIS with the bank behind itThe customer settles the bill inside the app. The money moves directly from their SAIB account to the restaurant's account, instantly, and the discount is taken off before it moves. The restaurant gets a payment confirmation on WhatsApp, by email, or in their point of sale. Merit never touches the money.
Every other option on this page adds seconds to a payment that still has to happen afterwards. Scan the code, then pay. Tap activate, then pay. Confirm on WhatsApp, then pay.
This one is the payment. There is no second step, because the redemption and the settlement are the same act. Measured honestly, its cost at the counter is not the twenty seconds below, it is the difference between doing this and waiting for a card machine. That number can be zero, and it can be negative.
- Customer opens the app to payInstead of reaching for a card. The outlet is identified by a code on the table, or by where the phone already is.Customer
- The app shows the bill with the discount already offBill, offer, and what is actually owed. The customer sees the saving at the moment it happens rather than on a statement weeks later.Merit
- Customer confirms, and SAIB moves the moneyFrom the customer's own SAIB account, straight to the restaurant's account. This is a bank moving its own customer's money, which is the whole reason it works.SAIB
- The restaurant gets a payment confirmationWhatsApp, email or their point of sale, carrying the amount, the discount, and a reference they can match to the table.Merit
- Everything is captured, with no extra step anywhereOutlet, time, bill value, discount and a settled transfer. Nothing is self reported and nothing needs verifying afterwards.Merit
This is not new infrastructure. Saudi Arabia's national instant payment system runs 24 hours a day, settles between local banks in seconds, and lets a payment be addressed by a mobile number, national ID or email rather than a full account number. SAIB offers it today and says so on its own site, with alias based transfers up to SAR 2,500 and the national per transaction ceiling at SAR 20,000. A restaurant bill sits comfortably inside both.
Separately, the regulator issued the payment initiation release of its open banking framework in September 2024, which is the formal route for a third party to start a payment from someone's bank account with their consent. Whether that route is operationally open to a new provider today is a separate question we have not checked. Either way the easier path by far is that SAIB simply exposes this to its own app, because it is their customer and their account.
One useful detail: the rail can address a payee by the unified number for a commercial establishment, not just a full account number. That takes some of the sting out of onboarding, because it may mean no bank details have to be collected per outlet at all.
Card acceptance costs a restaurant a percentage of every bill and pays out in a day or two. This pays instantly and costs a flat fee measured in halalas. For merchant recruitment that is a stronger opening line than any discount programme: take this and you stop paying card fees on it, and you get the money now.
Can a payment be triggered from our side at all. This is the whole option. Either SAIB opens payment initiation to the marketplace, which is a bank side build, or Merit becomes an authorised payment initiation provider, which is a licence application. The first is far cheaper and SAIB is the client. Nobody has asked them yet.
Single sign on is still not done. SAIB's own integration has been outstanding since July 2025. If the app cannot yet pass a customer through cleanly, asking it to initiate payments is a much larger conversation than asking it to show an offer.
A transfer cannot be charged back. Cards have a dispute rail and this does not. That is a selling point for the merchant and a real exposure for the customer, on a wrong amount, a wrong outlet or a disputed meal. Refunds become something the restaurant sends back by hand, and that needs designing rather than assuming.
Every outlet needs an account on file. Someone has to collect and verify it. That should be SAIB, not Merit, both because SAIB owns these relationships already and because registering merchants and running the identity checks is the side of the line that needs a licence.
It asks the customer to change a habit. Paying a restaurant from a banking app instead of tapping a card is a behaviour change, and it is the one thing here that no amount of engineering fixes. Indonesia is the evidence it can shift, and it took a national standard and several years.
Not in the four to five week window. This is a roadmap item alongside G, and the two are alternative destinations rather than a sequence: G gives up immediacy to get zero counter time, P gives up a few seconds to put the saving in front of the customer at the moment they pay and to take the card fee off the merchant. G needs SAIB's card processor. P needs SAIB's payment initiation. Both are bank side asks, so both belong in the same conversation with the bank rather than in the build plan.
It just appears on the statement
The destination, not this build shape: Amex Offers, Visa OffersThe customer pays with their SAIB card and nothing happens at the counter at all. The bank matches the transaction afterwards and the benefit lands as a credit on the statement. This is nearly what SAIB has today, rebuilt properly rather than thrown away.
- Pay the restaurant with the SAIB cardExactly as today. No app is opened.Customer
- Nothing happens at the counterNo customer action, no cashier action, no merchant enablement, no location permission, no codes, no portal.Nobody
- The bank matches the transaction afterwardsSAIB is the issuer, so the transaction data is already theirs. Merchant identifiers are how Amex Offers and Visa Offers work, and both are already in our benchmark table.SAIB
- The benefit lands as a statement creditVerification is perfect, and it captures the bill value too, because the settled transaction is the evidence. It solves the presence problem and the value problem at the same time.SAIB
SAIB is accepting a downgrade. A proposal that ends at Option D tells the bank their experience gets worse permanently. A proposal that shows E now and G as the destination tells them it gets worse temporarily. That is a completely different conversation, and it is the one being asked for.
The tradeoff to state honestly: the customer does not see the discount on the bill, they see a credit afterwards. That is delayed gratification and it needs clear messaging. Amex has run it at scale for years, and for a high end restaurant it is strictly better, because nothing at all happens at the table.
The dependency is real. This is a bank side build needing SAIB's card processor, not a Merit build. That is why it goes on a roadmap slide and not into a four to five week release.
Everything comes down to seconds at the counter
The business goal is keeping counter time low enough that high end restaurants carry on accepting the offer. So here are seven of them, running in real time.
Time at the counter
† Option P is the odd one out and its bar is hatched to say so. Every other row is time added to a payment that still has to happen afterwards. P is the payment, so the twenty seconds is not added to anything. Against tapping a card and waiting for the terminal, its true cost can be zero or less. Do not read it as slower than Option D.
The 60 to 90 seconds for The Entertainer comes from published benchmark research on a live pattern running across roughly 2,000 restaurants in the region. Every other number on this chart is an estimate, Option D's included. None of them should be quoted to SAIB until we have run a timed walkthrough of a real build. The BRD already carries exactly this caveat for Option D's own figure, calling it a projection from the benchmark rather than a measurement of anything we have built, and that holds for all of them here.
The Entertainer is worth naming, because "just do what The Entertainer does" is the natural instinct in the room. Their pattern is the server typing a four digit merchant PIN on the customer's phone. It is the slowest verified pattern in the benchmark, and it puts the customer's phone in a stranger's hand, which is the exact thing removed from Option D in August. One correction is still outstanding on how their mechanic actually works, and it is question 6 below.
Delete the code and nine problems delete themselves
This is the part that makes Option E better rather than merely cheaper. Removing the code removes the entire apparatus built around it. Everything below is currently live work in the BRD.
- ×The one page outlet card, issued at onboarding and reissued every time a code rotatesGone
- ×Requirement R02, every outlet carries a code its staff must knowGone
- ×Requirement R13, Operations can rotate an outlet codeGone
- ×Requirement R14, the support path when an outlet cannot produce its code. Currently undesigned, and it has no owner at SAIB Gone
- ×Decision 3, will partners agree to hold a code and brief their staffGone
- ×Decision 5, how long the code should be and how long the timer should runGone
- ×Decision 8, is a photographable static code acceptable to the bankGone
- ×The placement problem, staff training, and shift rotation eroding itGone
- ×Three unhappy path screens and the five minute timer, reduced to one case: location unavailableReduced
They close by deletion. Requirement 14 is the one to point at in the room, because it is currently a day one support problem that the bank has not staffed and nobody has designed. Under Option E there is no code to fail to produce, so there is nothing to support.
The seven journeys on one page
| Today card-linked |
E just be there |
D scan the code |
F the bill goes in |
F-lite over WhatsApp |
P pay in the app |
G statement credit |
|
|---|---|---|---|---|---|---|---|
| Customer actions at the counter | 0 | 1 tap | tap + scan | tap + show | tap + type | pays in app | 0 |
| Cashier actions | 0 | 0 | present a card | scan, type, confirm | one tap | 0 | 0 |
| Estimated counter time | 0 sec | ~3 sec | 10 to 15 sec | 20 to 30 sec | 30 to 60 sec | replaces the card | 0 sec |
| Merchant device needed | their POS | none | none | their own POS | any phone | none at all | their POS |
| Outlet enablement programme | none | none | a card per outlet | one build per POS platform | a phone number on file | a bank account on file | none |
| Proof the customer was there | absolute | strong | weak, the code is public | strong | strong | strong | absolute |
| Proof they actually bought something | absolute | none | none | strong | merchant confirmed | absolute | absolute |
| Captures the bill value | yes | no | no | yes | yes | exactly | yes |
| Enforces one per month | yes | yes | yes | yes | yes | yes | yes |
| Audit trail for disputes | yes | yes | yes | yes | yes | yes | yes |
| Fits high end restaurants | yes | yes | yes | weak | weak | yes | yes |
| Fits the four to five week window | no | yes, if the sizing lands | yes | no | unsized | no | no |
| Blocked on SAIB | card processor | app location permission | no | no | no | payment initiation | card processor |
Every counter time in this table is an estimate, Option D's included, and all of them need a timed walkthrough before any goes to the client.
Nothing here is presentable until these come back
The first two decide whether Option E is real at all. The third is the highest leverage unknown in the design as it stands. And the tenth is the one nobody has put to the bank yet, which is the only thing standing between this proposal and its best version.
The recommendation in one line
Ship E with D underneath it as the fallback, inside the first release window. Price F as a second phase, triggered by the funding decision and not by the journey, with F-lite as its coverage layer. And put P and G to the bank as the two destinations, because both are things only SAIB can unlock.
That shape answers everyone in the room at once, which is the reason to prefer it over any single option on its own.
If the sizing answer kills E, the fallback is D now with the location check added after launch, and the proposal reverts to what the BRD says today. That is a fine outcome, but it should be a decision rather than a default.
Adopting E means version 0.5 is not a cleanup, it is a new recommendation. Section 9 would recommend E with D demoted to a fallback rung inside it. Requirement 15 moves from "could have, priced separately" to "must have." Requirements 2, 13 and 14 are struck or rewritten, and the outlet card programme becomes optional coverage for hard sites rather than a launch prerequisite. Decisions 3, 5 and 8 close by removal. A dependencies and risks section is needed for the location accuracy risk, the permission risk and the outstanding single sign on integration, none of which are in the document today.
That is realistically two days of work on the document, and it is worth saying so rather than promising it sooner and slipping again.