One Rail in a Region With Five
There is exactly one mobile-money integration in this product, and the supplier record is shaped around it — four fields for one provider, plus a bank account. Everywhere that provider is not the rail, a supplier payment is something we record rather than something we operate.
Look at a supplier record in our system and count the payment fields. There is a bank code and an account number. And there are four fields for one mobile-money provider — a phone number, a paybill, a paybill account, and a till.
Four fields for one provider tells you where this product grew up. It is not a criticism; it is a fact about the shape of the record, and it is worth reading before you assume the shape fits your market.
What "integration" means here, precisely
Two different things get called integration and the difference is the whole post.
An operated rail is one the system initiates. It builds the instruction, sends it, receives the callback, logs the webhook, and records the result against the order. Nobody types the amount into a second application. There is one of these for mobile money, covering both paying a person and paying a business, and it is a genuine integration with the payment gate in front of it.
A recorded payment is one that happened somewhere else and is entered afterwards. It is a first-class path — manual vendor payment — and, importantly, it calls exactly the same gate. So an order with a discrepancy cannot be marked paid manually any more than it can be paid automatically. The control does not weaken just because the rail is not ours.
The control survives the missing integration. The reconciliation does not.
What you actually lose
Not the audit trail, and not the governance. Three other things, in order of how much they cost.
-
Timing
A recorded payment is entered when somebody gets round to it, which is not when it happened. Between those two moments the order reads unpaid, and an order that reads unpaid for three weeks is an order somebody eventually pays twice.
-
Double entry, in the literal sense
The amount is typed into your provider's application and then typed again here. Two keystrokes of the same number by the same person is the classic transposition, and nothing in either system can catch it because neither has seen the other.
-
Reconciliation
An operated rail logs its webhook, so there is a machine record of what the provider said happened. A recorded payment has a reference somebody copied. Month-end reconciliation is then a comparison between your provider's statement and somebody's typing.
Why this is a specifically West African problem
Because the mobile-money landscape here is genuinely plural in a way it is not everywhere. A Senegalese business paying suppliers is not choosing between one dominant rail and a bank; it is dealing with several providers, and which one applies is a property of the supplier rather than of the buyer.
That plurality means the single-integration design does not degrade gracefully. In a single-provider market, one integration covers most payments and the rest are exceptions. Here, the integration covers none of them, and every supplier payment on a mobile rail is a recorded payment.
The supplier record makes it slightly worse in a small way worth knowing: with four fields named for one provider and no generic mobile-money field, another provider's number lives in a field labelled for something else, or in a note. Neither is wrong, and both are the sort of thing that confuses whoever inherits the data.
A second rail is a well-shaped piece of work
The machinery around a mobile-money payment already exists and is not provider-specific: the payment gate, the vendor payment ledger, the webhook logging, the payments register. What is provider-specific is the instruction and the callback.
A second provider integration
Initiation, callback handling and webhook logging against an existing ledger and an existing gate. The surrounding structure does not need rebuilding for the second one, which is why the second is cheaper than the first.
A generic mobile-money identifier on a supplier
A provider and an identifier, rather than four fields named after one company. Smaller than the integration and useful even without it, because it stops the data going into the wrong field.
A statement import for reconciliation
The pragmatic middle path for any rail we will never operate: import what the provider says happened and match it against recorded payments. Worth considering before a second integration, because it covers every provider at once.
No dates on a public page. Tell us which providers your suppliers actually use and roughly how many payments a month go through each, and we will come back with a written scope, timeline and cost.
Scope a payment railThree questions about payment integrations
Which payment rails does the system initiate, as opposed to record?
A good answer sounds like
Two lists, kept apart.
What it actually means
Almost every vendor answers this question with the combined list. The distinction is the one that decides how much typing your team does.
Is the webhook logged?
A good answer sounds like
Yes, retrievable per payment.
What it actually means
This is what makes an operated rail reconcilable. Without it you have a status field and a hope.
Does a manually recorded payment go through the same controls?
A good answer sounds like
Yes, the same gate.
What it actually means
Ours does, and it is the reason a missing integration is an efficiency problem rather than a governance one.
What AWRA OpsHub does today
- One operated mobile-money integration, covering both person and business payments, with webhook logging.
- A card and bank rail with per-supplier payee records.
- Manual vendor payment as a first-class recorded path, calling the same payment gate as every automated one.
- Bank details and four provider-specific mobile-money fields on every supplier record.
- A cross-module payments register spanning every rail and both underlying ledgers.
What it does not do
- Any second mobile-money integration. There is one, and no other provider is operated.
- A generic mobile-money identifier on a supplier — the fields are named for one provider.
- A statement import or automated reconciliation against a provider's own records.
- A payment run or batch payment approval; payments are recorded individually.
- Any remittance advice sent to a supplier automatically.
Not ours, by choice
- A recorded payment is not a second-class payment for control purposes — it passes the same gate. What it is not is reconciled.
- We name the absent providers because their absence is a fact about our code. Nothing on this page is a claim about how any of their systems work.
- Nothing here is uniquely Senegalese. It is what a single-integration design does in a plural market, and West Africa is the clearest example of one.
Our position
If your suppliers are paid on a rail we do not operate, plan for recorded payments and put the discipline where the risk is: enter the payment the same day it is made, use the provider's reference verbatim, and reconcile against the provider's statement monthly rather than quarterly. The governance is intact; the typing is yours. If the volume is high enough that this is a person's job, that is the conversation to have with us before you buy rather than after.
Tell us which rails your suppliers actually use
The answer decides whether this is a minor inconvenience or a daily cost, and it is worth establishing before a decision rather than during a rollout.
Talk about railsFrequently asked questions
Can I still pay suppliers on another provider?
Yes — you pay them in that provider's own application and record the payment here as a manual vendor payment. It passes the same payment gate, appears in the payments register, and settles the order. What it does not do is initiate the transfer or receive a confirmation.
Where should I put a supplier's number for a provider you do not integrate with?
Pick one place and use it consistently across every supplier — a custom field is the cleanest option because it can be named for what it is. What causes trouble later is putting it in a field named after a different provider, because the next person to read the record will believe it.
Would a statement import be better than a second integration?
Often, and it is worth saying so even though it is the less impressive answer. An integration covers one provider well; an import covers every provider adequately and closes the reconciliation gap, which is the one that actually costs money at month end.
