If you are building a consumer product in Ghana, take mobile money first and add bank transfer second. Mobile money is where the accounts are; GhIPSS Instant Pay is where the banks are. Build one payment abstraction over both, and design reconciliation before you design the integration — that is the part that costs money later.
That is the short answer. The longer one: Ghana has four distinct rails, they are not interchangeable, and choosing between them is a product decision with fee, settlement and customer-identity consequences, not a checkbox on an integration ticket.
Who runs the rails
GhIPSS — Ghana Interbank Payment and Settlement Systems Limited — is a subsidiary of the Bank of Ghana. That ownership matters. The switch underneath is not a private processor competing for your business; it is central-bank infrastructure that banks and mobile money operators connect to. Your commercial relationship is usually with a bank or an aggregator on top of it, but the clearing behaviour underneath is GhIPSS's.
Real-time payments in Ghana are locally called Instant Pay — processed and settled immediately, around the clock. Keep that phrase in mind when you read local documentation, because "instant" is a product name there, not an adjective.
The four rails, and what each is for
GhIPSS Instant Pay (GIP) is bank-to-bank real-time transfer. It is the rail for payouts to a bank account, for higher-value collections, and for anything where the counterparty is an organisation rather than a phone number. If your product pays contractors, settles merchants or refunds to a bank account, this is the one.
Mobile Money Interoperability (MMI) allows direct transfer of funds from one mobile money wallet to another across networks. Before it existed, cross-network transfer was a manual workaround the user had to perform — cash out on one network, cash in on another, pay twice. MMI removed that, and in doing so removed a design constraint that used to shape Ghanaian consumer products: you no longer have to ask which network someone is on before you can move value to them.
e-zwich is the biometric smartcard rail — card and fingerprint rather than phone. That makes it relevant where identity verification at the point of payment is the requirement: disbursements to people who may not hold a smartphone, programmes that need proof the right person collected the money. A poor fit for ordinary checkout, a good fit for controlled disbursement.
Gh-link is the national card switch GhIPSS launched in 2012. It connects banks and financial institutions to a central system, clears interbank card transactions and settles them in the Bank of Ghana RTGS, and carries a domestic EMV card scheme accepted across the local ATM and POS network without routing through an international scheme. It also provides payment gateway services for local online merchants.
Most products need two of these. Almost none need all four.
The market shape decides your default
Ghana is West Africa's clearest telco-led mobile money market. The wallets are MTN MoMo, Telecel Cash and AirtelTigo Money.
MTN MoMo is the dominant wallet by a wide margin, with Telecel Cash and AirtelTigo Money sharing most of the rest. We are deliberately not quoting a share percentage: the figures in circulation trace back to reports that still name the second network “Vodafone Cash”, and Vodafone Ghana’s consumer business became Telecel Ghana. Treat the ranking as reliable and any specific percentage as stale until you check it against a current source.
The practical consequence: MTN MoMo failing is not a degraded experience for most of your users, it is an outage. Plan for it explicitly.
Onboarding runs through the Ghana Card
Wallet registration in Ghana is identity-anchored. The Ghana Card is issued by the National Identification Authority (NIA). To register a MoMo wallet, a user visits a certified agent with their Ghana Card and SIM; the agent verifies identity, sets a PIN and activates the wallet.
So the wallet a customer pays from has already been through an identity check you did not run. You do not inherit that check — you cannot see the verification — but the account-to-person mapping behind the rail is stronger than an anonymous card. Design your KYC tiers knowing that, and knowing a user without a Ghana Card is a user without a wallet: an accessibility question, not only a compliance one.
One abstraction over several networks
The engineering shape that survives contact with these rails is a single internal payment interface with per-provider adapters underneath. Three things belong in that layer and nowhere else.
Reference generation. Your system mints the reference, before the payment is initiated, and it is unique per payment attempt — not per order, because a retried payment is a second attempt against the same order and you need to tell them apart. Never accept a provider's reference as your primary key.
Retry policy. Retries must be idempotent at the provider boundary, which means the same attempt reference on every retry, and a hard rule that a timeout is not a failure. A request that times out may have succeeded. Treating it as failed and retrying with a fresh reference is how a product double-charges people.
Status normalisation. Providers disagree about what their statuses mean. Collapse them into a small internal set — pending, succeeded, failed, unknown — and make unknown a first-class state with a resolution job behind it, rather than a bug you handle by guessing. Route logic sits above this layer: if MTN is timing out, fall back to prompting for a different wallet or a GIP bank transfer. The outage should cost you conversion, not availability.
This is the same discipline that makes a Nigerian integration survivable — the details differ but the shape does not, as in our Paystack and Flutterwave integration guide for Nigeria. The rails change; the abstraction does not.
Reconciliation is where products quietly leak money
Every inbound payment needs a reference that ties it to an order at the moment it arrives. If it does not have one, someone matches it by hand later — and "later" becomes a monthly spreadsheet, and the spreadsheet becomes the system of record.
Concretely, build these four things on day one:
1. A ledger separate from your orders table. One row per money movement, append-only, with the provider, the attempt reference, the amount, the currency and the provider's own identifier. Orders reference ledger entries, not the other way round.
2. Webhooks and polling, both. Webhooks are the fast path and they are lossy. The gap is closed by a scheduled job that queries provider status for anything left pending or unknown beyond a few minutes.
3. A daily settlement match. Pull the provider's settlement report and match it against your ledger for that day. Alert on three classes: in your ledger but not theirs, in theirs but not yours, and matched-but-different-amount. The third is the one that gets missed.
4. An unmatched-payments queue with an owner. Unmatched payments are not an exception; they are a steady trickle. Give them a screen and a person, not an inbox.
The eCedi is a Bank of Ghana pilot, not generally available. The response is architectural: if your payment layer already treats providers as adapters behind one interface, a future rail is just another adapter. Do not build for it now — only avoid building something it could never fit into.
What this changes
If you are scoping a Ghanaian product this quarter:
- Default to mobile money for consumer collection, GIP for payouts and higher-value inbound. Add e-zwich only if identity-at-payment is an actual requirement.
- Integrate at least two wallets before launch, not after. With one network holding most active accounts, single-provider integration means your uptime is theirs.
- Write the reference scheme down before the first API call. Unique per attempt, carried through every provider field that survives the round trip, stored in a ledger you control.
- Assume cross-network is solved. MMI means you should not be building network-selection UX or asking users to manage the hop themselves.
- Decide the rail with your finance lead, not only your engineers. Fee structure, settlement timing and who can actually pay you are product questions.
We build payment abstraction and reconciliation layers for West African products; Ghana is a market we design for with those same patterns rather than one where we can point to a local client yet. If you are working through the market and team side of this, our notes on app development in Ghana and on the Ghanaian software and fintech landscape for 2026 cover the ground around this piece.