For investors
The thesis, andthe parts thatargue against it.
Mobile money in Ghana is everywhere between people and still awkward between a person and a shop. This page sets out why that gap is worth building into, what has been built and proved so far, and what has not, in the same amount of detail.
There are no transaction volumes on this page, no user counts and no logos, because there is nothing to count yet.
The thesis
Person to personis solved. Personto shop is not.
Neither a typed number nor a printed code can prove who is being paid.
Sending money to a person in Ghana is a solved problem and has been for years. Paying a shop is not. At the counter the customer either types a number read off a wall, which invites a mistyped digit and a transfer that cannot be recalled, or scans a printed code, which invites a code that is not the shop’s.
Both of those failures land on the merchant, in front of a queue, with a customer holding a confirmation SMS for a payment that went somewhere. The missing piece is not cheaper acceptance. Ghana already ran the cheap-acceptance experiment with a national QR standard that costs a merchant nothing and needs no electronics. The missing piece is proof of identity at the moment of payment.
A tag that signs every read is the cheapest credible way to put that proof on a counter: roughly a dollar of passive plastic, no terminal, no power, no app on either side.
The beachhead is pharmacies and filling stations, because both have a fixed counter the tag can live on and a queue that makes speed worth something. The number below is what the pilot is sized against and where it came from.
Provenance for each figure is attached to it in the source, and the first one was corrected upward from an earlier estimate during research rather than left at the number that was easier to defend.
What exists
Built, tested,and checkable.
This is a working system, not a deck. Everything below is code with tests behind it, and each item names what the test actually demonstrates rather than that one exists.
Working cryptography, checked against published vectors
The AES-CMAC implementation passes all four RFC 4493 test vectors, and the tag read verification passes the chip vendor’s own worked example end to end. A silent error in this layer would not break a demo, it would break the anti-cloning guarantee while appearing to work, so it is tested against numbers somebody else published rather than against our own expectations.
Replay defence tested under real concurrency
Eight identical taps racing against a real database open exactly one payment session. Distinct counters racing never let the recorded counter move backwards. These are tests in the suite against a database, not a description of intent, and they exist because the naive read-then-write version passes every single-threaded test and is wrong.
A full payment flow behind a swappable provider interface
Session, charge, webhook verification, status machine and receipt, with everything provider-specific held behind one interface of four methods. Adding a provider that is not wired into the selector is a compile error rather than a runtime surprise. A provider outage is recorded as unknown and never as a failed payment.
Money handled as integers throughout
Amounts are whole pesewas from the moment they are parsed. There is no floating point anywhere in the money path, and the rule is written at the top of the schema rather than held in somebody’s head.
A merchant surface that does not need hardware
Dashboard, transaction list, printable statement over a chosen date range, SMS to both parties, and a per-tag audit trail recording every tap with its outcome and reason. The merchant side of the product asks for a counter and a phone number.
What does not exist
Four gaps, statedwithout hedging.
Each of these is the sort of thing diligence finds. Finding it here first should tell you something about how the rest of the material was written.
No field validation with real merchants or customers
Nobody outside the project has tapped a tag on a counter and paid for anything. Every claim about the customer gesture is a claim about a design, not an observation of behaviour. Closing this needs pilot merchants and a pilot, in that order.
No payout path to merchants in the code
The system can take a payment. It has no implemented route for getting that money to the merchant, and the settlement arrangement that would define one is unresolved. This is recorded as an open finding in the project’s own requirements document rather than left to be discovered.
No Bank of Ghana authorisation
Operating as a payment service provider in Ghana requires authorisation under the Payment Systems and Services Act 2019 (Act 987). Tap2MoMo does not hold one, and the licensing route for the pilot is an open question rather than a settled plan. In 2026 the Bank of Ghana revoked a licence for the category of overreach this project is deliberately avoiding.
The tag hardware has never been touched
Every provisioning run so far has been verified against a software simulator. That simulator was written from the same reading of the datasheet as the code it tests, so a shared misunderstanding would pass the whole suite silently. The first real tag is the first real test of that, and until then every claim about the tag writer is a claim about a simulator.
The fact that argues against us
MTN tried thisin 2017 andstopped.
MTN Ghana ran a product called Tap2pay in 2017. Its primary customer path was a customer with an NFC smartphone tapping at a counter and approving with a PIN, which is Tap2MoMo’s customer gesture almost exactly. It shipped at Accra malls, at Korle Bu, and at filling stations, which is half of the beachhead this project has narrowed to. It was abandoned.
This surfaced late in our own research and it reversed two conclusions we had already written down. It is not a detail we are disclosing because it is safe to disclose. It is the strongest argument against this product and it comes from the incumbent that owns the rails.
What survives it: the customer gesture was tested, but the merchant cost structure MTN tested was a terminal or a merchant app. This design puts roughly a dollar of passive plastic on the counter instead, with nothing to power and nothing to install on the merchant side.
What does not survive it: any claim that the customer side is untested territory. It was tested, in this market, in this beachhead, and it stopped. Why it stopped, whether it was a handset constraint that has since resolved itself or merchant indifference that no amount of cheaper hardware fixes, is the single highest value question this project has open, and it is answerable by asking the vendor who built it.
Still to be written
Team, traction,and the ask.
Three boxes that would normally be filled with something. They are empty because the honest versions are not written yet, and an invented version of any of them is the kind of thing that ends a conversation later rather than earlier.
To supply — Team
To supply — Traction
To supply — Funding ask
Talking to us
Ask the awkwardquestions first.
We will answer them the way this page is written. If you want the mechanism in full detail before you get in touch, the security page is the one worth reading.