Three Tenders, and the One That Was Never Real
This till takes cash, one mobile-money rail and a card. It briefly took a fourth on refunds — store credit — which reversed the sale, returned the stock, and recorded the debt to the customer nowhere at all.
A tender is not a payment method. It is a claim about where money went or came from, and every claim a till makes has to end up somewhere that can be counted. The ones that do not are the interesting ones.
The three
A sale here accepts cash, one mobile-money rail, or a card. Three values, validated identically on the sale screen and on the API, with no configuration and no fourth option.
A refund accepts the same three. That symmetry is deliberate and it is the correct default: money can only go back the way money can come in.
And the fourth
For a period, refunds accepted a fourth: store credit. It was offered in the interface, accepted by validation on both the web and the API paths, and it did nothing.
No payment record. No movement on the customer's balance. No obligation of any kind written anywhere. The sale was reversed, the revenue came off the books and the stock went back on the shelf — and the amount now owed to that customer existed only in their memory and possibly on a slip of paper.
The shop had given away the goods, reversed the income, and kept no record of the debt. Every part of that transaction was recorded except the part that was a liability.
There was a second problem underneath the first, and it is the one that makes this instructive: there was no store-credit tender on a sale. So even if the credit had been recorded perfectly, there was no way to spend it. The feature could not have worked in any circumstance, for anybody, ever.
Offered in the interface
A visible option on the refund screen, presented to cashiers as a normal choice.
Accepted by validation
On both the web path and the API path, so it passed every check the system had.
Reversal of the sale
Revenue reversed, stock restored — all correct, and all of it the half that costs the shop money.
A record of the credit issued
None. No payment row, no customer balance movement, no obligation record.
A way to redeem it
None. Store credit was never an accepted tender on a sale, so the credit was unspendable by construction.
What was done about it
The option was removed rather than implemented, and both controllers now carry a comment recording that its absence is deliberate. That is a deliberately unglamorous fix and it was the right one: a validated option that produces nothing is a live defect, and a half-built one shipped in a hurry would have been a worse one.
The comment matters more than the removal. Without it, the next person to look at a three-item list of tenders adds the obvious fourth, and the cycle repeats.
Reading a tender list, in any system
What to check for every tender a till offers
Weight is how much of a tender's trustworthiness rests on each.
It creates a payment record
Make them prove it: The sale total reconciles to the sum of its payments
It reaches the ledger
Make them prove it: Cash, bank or a liability account moves
It can be reversed the same way
Make them prove it: Refunds accept it too
It appears in the drawer reconciliation
Make them prove it: Or is explicitly excluded, on purpose
It has an owner when it is a promise
Make them prove it: A customer, not a slip of paper
One rail, and what it means outside East Africa
The mobile-money tender integrates exactly one provider, and there is no other wallet integration anywhere in this product. In a market where local wallets carry a large share of retail payment, that tender is either unused or used as a label for a payment the system did not actually operate. Reconciling those is manual, and it is better to decide that consciously than to discover it.
Four questions about tenders
List every tender this till accepts.
A good answer sounds like
A short, finite list.
What it actually means
Ours is three. A long configurable list needs the next question asked of each one separately.
For each one, what record does it write?
A good answer sounds like
A payment row, and a ledger entry.
What it actually means
The question that found ours. "It records the sale" is not an answer about the tender.
Which tenders can be refunded?
A good answer sounds like
The same list, or a stated subset.
What it actually means
An asymmetry here is usually where an unbacked promise lives, as ours was.
If store credit is offered, where is the liability?
A good answer sounds like
A named account or balance.
What it actually means
Store credit is a liability. A till that issues it without recording one is giving away goods and remembering nothing.
What AWRA OpsHub does today
- Three tenders on a sale — cash, one mobile-money rail, and card — validated identically on the web and the API.
- The same three on a refund, so money can only return the way it can arrive.
- Payment records per sale, which is what the drawer reconciliation counts.
- Revenue and cost of sales both reversed on a return, with the cost leg conditional on whether the goods came back to stock.
- A comment in both controllers recording that store credit is deliberately absent, so it is not re-added by accident.
What it does not do
- Store credit, gift cards, vouchers or any customer credit balance spendable at the till.
- Split tender — one sale settled by more than one method.
- Any mobile-money rail beyond the single integrated provider.
- Configurable tenders. The list is three, in code.
- On-account sales at the till against a customer credit limit.
Not ours, by choice
- Store credit was a live defect, not a missing feature, and we describe it that way. It was offered, accepted, and produced nothing.
- Removing it rather than building it was a deliberate choice. A half-built liability is worse than a refusal at the counter.
- Nothing here is Omani. Muscat is here because it is a card-and-wallet retail market where the one mobile-money rail this product integrates is not present, which makes the tender list a practical question rather than an academic one.
What is not built for Oman today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Oman. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If inbound Fawtara documents landing on your purchase records, an Arabic interface, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
The receiving end of Fawtara
A link to your accredited service provider that works in both directions: our sale handed over in the shape their access point expects, and — the part nobody quotes for — an inbound supplier document arriving as data and landing against the purchase order and goods receipt it belongs to, so the three-way match happens before anyone approves payment rather than after. We will not become your access point or hold the accreditation; that belongs with a provider registered on the network, and we would rather say so than sell you the pipe.
Arabic interface, banks and acquirers
Arabic interface text with right-to-left layout and bilingual document templates, plus bank statement feeds and card acquirer settlements wired into the Payments Register so collections match invoices without anyone re-keying a statement.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
An Omani payroll engine with Social Protection Fund contributions calculated on live employee records, wage files in the layout the Ministry of Labour and Central Bank system expects, and the Omanisation position visible before a deadline rather than after one.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedAsk what each tender writes
Not what the till accepts — what each acceptance records. It is one extra question per tender and it is the one that finds the promise nobody is keeping.
Talk about till paymentsFrequently asked questions
Can a customer pay half in cash and half by card?
Not as one sale. Split tender is not built, and the honest workaround — two sales — breaks the basket and any line discount on it. If split tender is normal in your trade, raise it early.
What should we do about store credit today?
Handle it outside the till and record the obligation as a customer balance in the sales module, where a balance exists and means something. It is manual, and it is at least a record.
Can another mobile-money provider be added?
It is an integration build rather than a configuration change, because only one rail is implemented and the tender list is fixed in code. It is a well-understood piece of work and it is the kind of thing most often commissioned.
