Skip to main content
Who this is for: Developers building for churches, mosques, ministries and faith-based non-profits — including multi-branch organisations that need one view of money across every assembly. Giving is not buying. There is no invoice, no delivery and often no expectation of a receipt — but there are stricter rules about which pot the money lands in than almost any other sector. Zakat cannot be mixed with a mosque’s operating funds. A building fund is not general income. A branch’s offering is not head office’s to spend. So the first design decision is not how you collect. It is how you keep money apart.

Keeping funds separate

A wallet and account number per fund, so money arrives already segregated.

Funding and overseeing branches

Move money to assemblies, let them spend, see everything from head office.

Collecting giving

In the service, online, recurring, and against a pledge.

Giving from the diaspora

Members abroad giving in their own currency.

​
Keeping funds separate

What you’re building: Designated giving that lands in its own account from the moment it is given — not pooled and unpicked afterwards. A Pocket is a wallet holding a balance. Create a sub-pocket per fund, and each one comes with its own bank account number. Publish that number as the way to give to that fund, and segregation stops being a reconciliation exercise.

​
The flow

1

Create a pocket per fund

Add a sub-pocket for each designated fund — zakat, building fund, missions, welfare, tithes. The response carries a bankAccountNumber and bankAccountName for that pocket.
2

Publish the right number for the right fund

Show each fund’s account number where people give to it — on the giving page, on a QR code, in the bulletin. A gift to the building fund never touches the operating account.
3

Report per fund, not per organisation

Get the balance of any single fund, or the consolidated total across all of them.

​
Decisions specific to faith institutions

  • Zakat must have its own pocket. It cannot be commingled with operating funds, and the obligation is on the institution to demonstrate that. A dedicated account with its own balance and transaction history is the cleanest evidence there is.
  • Name pockets after the fund, not the person. Treasurers change; the building fund does not. BUILDING-FUND-2026 survives a handover in a way Bro. Tunde's account does not.
  • Restricted funds are a promise, not a preference. If a member gave to missions, that money is not available for salaries. Segregating at the account level makes the promise structurally true rather than a matter of discipline.
  • One pocket per fund, not per campaign. A Ramadan appeal and an Eid appeal are both sadaqah — separate them with references inside one pocket rather than proliferating accounts you must reconcile forever.

​
What to watch

Payments arrive unannounced. Anyone can transfer to a published account at any time. Rely on webhooks rather than polling, and make your handler idempotent. Pockets are approval-gated. Payout features require approval on your merchant dashboard before they can be used through the API.

​
Funding and overseeing branches

What you’re building: Head office funding each assembly, branches collecting and spending locally, and one consolidated view of all of it — without branches sharing a bank login or head office chasing statements. The shape a multi-branch organisation needs is local autonomy at each assembly and consolidated oversight at the centre. Pockets give you both without anyone sharing a bank login.

​
The flow

1

Give every branch its own pocket

Add a sub-pocket per branch. Each gets its own balance and its own account number.
2

Fund the branch from head office

Move money down with a pocket-to-pocket transfer — an internal movement, not a bank payout, so it settles immediately.
3

Let the branch collect locally

Offerings given at that branch land in that branch’s account, attributed to that branch automatically.
4

Let the branch pay its own expenses

The branch settles local costs with payouts from its own pocket — signed, OTP-confirmed, and recorded.
5

See everything from head office

Balances summation gives the consolidated position; fetch transactions gives the detail for any branch.

​
Why this shape works

​
Decisions specific to faith institutions

  • Model the hierarchy you actually have. Region, zone, assembly — sub-pockets let you mirror the structure rather than flatten it.
  • Decide who may pay out, and enforce it in your software. Payouts are OTP-confirmed, but who may initiate one is your rule. This is where financial control in a volunteer-run organisation succeeds or fails.
  • Transfers down are not the same as giving. A head-office grant to a branch is an internal movement; an offering is income. Keep them distinguishable in your reporting or your branch accounts will overstate income.
  • batchReference is your idempotency key on bulk payouts — useful when funding many branches on the same day.

​
What to watch

A leaked payout key moves real money out. Treat the secret key used for payout signing more carefully than a collection key — see authentication. Approval is required. Both pockets and payouts are enabled per merchant. Confirm approval before building a launch around them.

​
Collecting giving

What you’re building: Taking offerings, tithes, sadaqah and donations through whichever channel a member actually uses.

​
Decisions specific to faith institutions

  • A pledge is an instalment plan without a schedule. Someone pledging over a year pays what they can, when they can. A dedicated virtual account per pledger handles that; a subscription with a fixed amount does not.
  • Let the amount be open. Set amount as a customer-entered field on a giving link — you are not selling a priced item.
  • Do not require an account to give. A sign-in wall between a member and their offering costs more than the data is worth.
  • Recurring giving is card-only. Transfer, USSD and mobile money cannot auto-renew, so offer a card for standing giving even where most one-off giving arrives by transfer.
  • Anonymous giving is legitimate. Some traditions treat it as a virtue. Design so an unattributed gift is a valid outcome, not an error state.

​
Seasonal peaks

Giving is spiky and the spikes are predictable — Ramadan, Christmas, Easter, harvest, conventions, appeals.
  • Use webhooks rather than polling, so load does not scale with your polling frequency.
  • A reused paymentReference is rejected, which is exactly what you want when someone refreshes a slow giving page.
  • Offer non-card methods — they hold up when card rails are congested.

​
Giving from the diaspora

What you’re building: Members abroad giving in their own currency, without an international card being the only option.
  • SeerBit supports NGN, GHS, KES, TZS, USD and XOF. Price the giving page in the currency the giver holds, not the one you report in.
  • USD settlement needs a domiciliary account. International payments settle on a longer schedule than local — see receiving settlements before you promise a project team a date.
  • Enable the payment methods that are normal in each market rather than assuming a card.

​
Before you go live

Test collection and payout

Test cards, and how test and live modes differ.

Go live

KYC, swapping keys, and re-pointing webhooks.
Pockets, payouts and virtual accounts are per-mode. Anything created with test keys works only in test mode — you will create your branch and fund pockets again against live keys, so script it rather than doing it by hand.