Three Tender Types, And One Is A Brand Name
Our point-of-sale table accepts three payment methods and refuses everything else at the database level. One of the three is the brand name of a Kenyan product. It is the only payment column in the entire product that constrains its own values.
Most software written for one market and later sold into another carries its origins in its defaults. A currency that has to be changed on setup, a date format, a tax field labelled with the wrong acronym. Those are annoyances, and they are cheap to fix because they are configuration. Occasionally the assumption goes somewhere harder to reach, and the honest way to describe what we found in our own till is that a Kenyan market assumption is not a default in it. It is a constraint.
The column that records how a customer paid at the point of sale is an enumerated type, fixed to three values: cash, card, and the name of a specific Kenyan mobile-money product. Not "mobile money" as a category — the product name, as a permitted value in a database schema. Anything else is not a configuration gap; it is rejected by the column before any application code has an opinion.
The part that makes this interesting rather than merely embarrassing
Every other payment surface in the product — customer payments, vendor payments, expenses, transactions — stores its method as an ordinary string, with the accepted values listed in a code comment rather than enforced by the column. The till is the only payment table in AWRA that constrains its own values, and it is the one constrained to a single country's payment market.
Why the inconsistency is the finding
If we constrained payment methods everywhere, three values would be a narrow list that needed extending — a small, ordinary piece of work with an obvious shape. What actually happened is stranger and more instructive: a deliberate architectural choice was made four times and the opposite choice once, and the once is the surface most exposed to a new market.
Nobody decided that. There is no design note arguing the till should be stricter than the accounts receivable ledger. It is what a schema looks like when one table was written quickly, in a context where those three values genuinely were the complete answer, and the question never came up again — because in the market it was written for, it never had to.
The same concept, five tables, one of them a wall
What it means at a till outside Kenya
Mobile money is not a Kenyan phenomenon, but mobile money products are national and operator-specific. A retailer in Lagos or Accra takes payment through schemes that have nothing to do with the one named in our column — and a cashier confronted with a till offering "cash, card, or the wrong country's product" does the only thing available, which is to put everything through one of the three and remember the difference.
That workaround is where the real damage is, and it is not at the till. It is a fortnight later, in the reconciliation.
- The daily cash-up stops meaning anything. If mobile-money takings are recorded as cash, the drawer will never agree with the system, and the variance is not a mistake anybody can investigate because it is the system working as configured.
- Settlement cannot be matched. Each scheme settles to the bank on its own timetable with its own fees. Collapsed into one bucket, the deposits arriving from three providers cannot be tied back to the sales that produced them.
- Charges become invisible. Tender types carry different costs. A business that cannot separate them cannot know what accepting each one costs it, which is one of the few genuinely actionable numbers in retail.
- The cashier carries the knowledge. The distinction survives only in somebody's memory and possibly a paper notebook, which is the state of affairs a point-of-sale system is bought to end.
None of those failures announces itself as a payment-method problem. They present as an unreconcilable till, and an unreconcilable till gets blamed on staff long before anybody suspects a database enumeration.
The fix is not "add two more values"
The narrow repair is to widen the enumeration. It is tempting, it is a small migration, and it would be the wrong lesson learned — because the next market brings a scheme nobody on our side has heard of, and a schema change per country is not a strategy.
The right shape is a tender type an organization defines for itself: a name, whether it counts toward the cash drawer at cash-up, whether it settles to a bank account and on what delay, and what it costs. That last set of attributes is the reason this is worth doing properly rather than quickly. A tender type is not a label, it is a set of behaviours at reconciliation — cash counts in the drawer, card settles net of a fee some days later, mobile money settles on a different schedule again. Widening a list of names gives a cashier the right button and leaves the finance team exactly where they were.
The general version, which is not about tills
A database enumeration is a claim that you know the complete set of possibilities forever. That is occasionally true — a boolean, a fixed workflow state you control — and it is almost never true of anything the outside world supplies: payment methods, document types, identity documents, units of measure, address shapes. When the values come from the world rather than from your own code, the world will send you a sixth one.
The question to ask anybody, including us
This one is unusually easy to test and almost never tested, because the demonstration is always given by somebody who taps "cash".
- "Add the tender type I actually use, in front of me." Not a request for a roadmap. If it needs a migration, a release, or a support ticket, that is the answer.
- "Does it count in the drawer at cash-up?" A tender type that is not cash must not make the drawer short. If every new method behaves like cash, the cash-up is decorative.
- "When does it settle, and what does it cost?" These are properties of the tender type. If they live nowhere, reconciliation is going to be manual forever.
- "What happens to last year's sales if I rename a tender type?" Worth asking of any system that stores the label rather than a reference to it.
Our answers today: no, you cannot add one — the column will refuse it; the three that exist behave correctly for the market they were written for; settlement delay and cost are not modelled as properties of a tender type; and there is no rename question because there is nothing to rename. If your retail operation runs on cash and card, our till does its job. If a meaningful share of your takings arrives through a mobile-money scheme that is not the one in that enumeration, this is a blocker rather than an inconvenience, and it is better read here than discovered at a cash-up.
The rest of the point-of-sale module is not implicated in this, and one part of it is what makes the constraint matter so much: shift reconciliation is the screen where a mis-typed tender becomes an unexplainable variance, which is why a naming problem in a column ends up being a trust problem at the end of a cashier's day.
There is a companion finding on the money-in side that has the same origin and a different shape: A Cheque We Only Understand Going Out is about a payment instrument that is missing from the schema entirely, where this one is about a payment instrument the schema actively refuses. Absence can be filled in; a constraint has to be removed first.
We found this while checking whether a point-of-sale post for West Africa could be written honestly. It could not — the post died and the finding underneath it did not, which is generally the better outcome of the two.
