Zetu

Payments

Bring every payment into one view.

Mobile money, bank transfer, card, payment gateway, direct debit, cash. Zetu does not care how the money arrived — or which market it arrived in — it cares what the money was for.

Mobile money.Bank.Card.Cash.

  • Mobile money wallets, on whichever rail your market uses
  • Bank transfers and bank feeds where available
  • Standing orders and scheduled bank instructions
  • Cards and payment gateways
  • Cash and check, recorded manually with attribution
  • Account credits and existing balances

Part of one system

Members & accountsObligationsBillingPaymentsReconciliationCollectionsCommunicationsMember portalStandingEntitlementsReporting. See how they fit

What each rail tells you about the payerIngestion settings · before any matching happens
Payment rails compared by what they reveal about the payer and whether a reference is carried.
RailWho paidReferenceMatching
Card / gatewayThe account that was chargedCarried automaticallySelf-identifying
Standing orderFixed, set up onceUsually consistentSelf-identifying
Direct debit / mandateThe mandate holderCarried by the mandateSelf-identifying
Bank transferThe sending account nameWhatever the payer typedNeeds interpretation
Mobile money walletA phone number and the line's registered nameOptional, and often absentNeeds interpretation
Cash / manualWhatever was written downWhatever was written downNeeds a human
Systems built for the top three rails treat the bottom three as edge cases. For most organizations, the bottom three are the business.

A card tells you who paid. A mobile money payment tells you a phone number. Those are not the same problem.

A stored card is a self-identifying instrument: it belongs to an account and the transaction already knows what it was for. Where all revenue arrives that way, reconciliation is close to free — which is why systems built for that world treat it as an afterthought.

Most of the world does not work like that. A bank transfer carries whatever the payer typed into a narration field. A mobile money payment carries a number and an amount. Cash carries whatever somebody wrote on a receipt book. In these environments, identifying the payer is the job, not a field that happens to be populated.

Zetu is built for that reality first. It works perfectly well when the money is tidy — it simply does not assume it.

Rail independence

Every rail ends in the same financial model.

Add a provider, change banks, or start accepting a new instrument, and nothing downstream changes. The obligations, allocations, balances and standing are the same objects regardless of how the money travelled.

Mobile money

M-PESA, MTN MoMo, Airtel Money, GCash and comparable wallets, including payments that arrive with no reference and from numbers that are not on the account.

Bank transfer and standing order

Including transfers whose narration is empty, wrong, or contains somebody else's account number.

Card and gateway

Self-identifying instruments where the payer and the purpose are already known.

Cash and manual entry

Recorded with an entering user, because the audit trail matters most where the external evidence is weakest.

Account credits

Money you already hold for a payer, allocated to a new obligation without any new payment.

Which specific providers are connected today is stated on the integrations page, at the category level. We do not list connectors we cannot stand behind.

Where the money came in$79,100 received · August 2026
Money received in August 2026 by payment rail, with each rail's share of the total.
RailShareReceived
Mobile money55%$43,510
Bank transfer27%$21,360
Card11%$8,690
Standing order5%$3,960
Cash & manual2%$1,580
Rail mix is the reconciliation problem. The rails carrying the most money carry the least reference data.

Payer identity

The record Zetu keeps of who paid.

Payment matching is only as good as what you know about payers — so payer identity is a maintained record, not a string on a transaction.

Registered paying numbers

The numbers and accounts a payer has actually used before, learned from history and confirmable by a person.

Names as the rail reports them

The name on a mobile line or bank account is frequently not the member's name. Both are kept.

Payment references

Your own reference scheme, matched exactly where it is present and inferred where it is not.

Third-party payers

A company, parent, spouse or sponsor recorded as a payer in their own right, linked to the accounts they settle.

Payment history

How this payer has paid before: which rail, which amounts, which dates, which obligations.

Provider records

The raw transaction from the rail, retained alongside the interpretation, so a disagreement can be settled.

Capabilities

What is in payments

  • Mobile money wallets, on whichever rail your market uses
  • Bank transfers and bank feeds where available
  • Standing orders and scheduled bank instructions
  • Cards and payment gateways
  • Cash and check, recorded manually with attribution
  • Account credits and existing balances
  • Payments received against no invoice
  • Payer identity as a maintained record
  • Registered paying numbers and accounts
  • Payment references, exact and inferred
  • Third-party and corporate payers
  • Raw provider records retained alongside the interpretation
  • Refunds and reversals as recorded events
  • Complete payment history per payer and per account

Questions

Payments, in practice

Is Zetu a payment gateway?

No, and it is not trying to become one. Zetu does not move money — it understands what the money meant. Keep the providers and bank relationships you already have; Zetu sits behind them and turns their transactions into settled obligations, changed balances and updated standing.

Which providers does Zetu connect to?

That depends on your setup, and we would rather point you at the integrations page than list logos here. It is written at the category level and marks availability honestly, because claiming a connector that does not exist is the fastest way to lose a finance team's trust in everything else on the site.

What happens when a payment callback never arrives?

It is a known failure mode rather than a surprise. Where a second source is available — a provider record, a bank feed, a statement import — Zetu compares against it and surfaces transactions that exist there and not in your system. A payer holding a confirmation message you have no record of is a finding with a value attached, not an argument.

Can we record cash and checks?

Yes, as manual payments with a recorded receiver, and they behave like any other settlement: they allocate to obligations, move balances and change standing. What they do not do is bypass the audit trail — a manual payment carries who entered it and when, precisely because it is the entry point with the least external evidence behind it.

Bring us one messy month.

Bring one month of obligations and one month of payments. We will show you what reconciles, what does not, and what that is costing you.