A Nigerian NGO does not need custom donation software simply to put a Donate button on its website. Start with a trustworthy hosted payment or fundraising product if it already accepts the donations you need and gives your finance team usable records. Commission a custom portal when donor history, recurring commitments, restricted campaigns, reporting or existing systems create work that a standard product cannot reliably handle.
For 2026 planning, these are my illustrative professional implementation allowances, not surveyed market averages, official software prices or fixed quotations:
| What the organisation needs | One-time implementation allowance | Sensible starting point |
|---|---|---|
| Hosted donation page connected to an existing site | ₦100,000–₦350,000 | Configure, test and hand over a supported product; a simple setup may cost less |
| Hosted donor tool with CRM import and staff workflows | ₦350,000–₦900,000 | Configure records, acknowledgements, reports and migration |
| Focused custom donation and donor portal | ₦1.2m–₦3.5m | Donor history, campaign allocation, verified payments, recurring status, admin and reconciliation |
| Multi-programme or multi-country donor operations | ₦3.5m–₦8m+ | Complex permissions, accounting integrations, migration, currency rules and audit trails |
Payment-processing charges, software subscriptions, messaging, hosting, legal advice and ongoing maintenance are additional. The lower-cost setups are not automatically large development projects; the ₦450,000+ opportunity starts when an organisation has substantial integration or operational requirements.
A donation page and a donor system solve different problems
A donation page answers: Can somebody contribute money securely? A donor system answers harder questions: Who gave, which campaign received it, what was actually collected, what is recurring, what failed, and what can staff report accurately?
Suppose 100 supporters each pledge ₦10,000 monthly. That is ₦1 million in expected monthly giving, not ₦1 million collected. If eight payments fail in a hypothetical month and the other 92 succeed, actual collection is ₦920,000 before fees. A dashboard that shows the pledge total as cash received would mislead the treasurer.
A useful record distinguishes the donor, campaign designation, payment reference, payment status, currency, amount, receipt and settlement or reconciliation status. A recurring pledge has its own lifecycle, separate from each actual payment.
This is a different purchase from a general NGO website design budget, which covers public programme pages, governance, reports and communication. Here the buying decision is the donation and donor-management workflow.
Buy a hosted product when your giving rules are ordinary
Use existing software if you need a branded giving page, one-time donations, a few fixed monthly amounts, receipts, basic exports and a small staff team. Ask the provider to demonstrate these with test records before signing up:
- A donor gives once without creating an account.
- A supporter starts a monthly gift and later cancels it.
- A failed payment appears as failed, not received.
- Staff can export donations with stable payment references.
- The NGO can identify and correct a campaign allocation without erasing history.
- The organisation can leave the platform with its permitted donor data and records.
Compare the three-year total cost of the subscription, transaction fees, integrations and staff effort with a custom build—not the monthly price against a one-time developer quote. A ready-made product can be the better long-term purchase even when custom development is affordable.
For an organisation that mainly struggles to convert website visitors into supporters, fix the nonprofit donation and volunteer journey before commissioning a new financial system.
What changes when recurring donations are involved?
A recurring donation is not a permanent standing instruction that works across every payment method. Paystack’s Subscriptions documentation currently supports cards and direct debit in Nigeria for its Subscriptions API. Do not assume an ordinary bank transfer, every foreign card or every donor country supports automatic renewal. Confirm the actual merchant and donor eligibility before promising a feature.
Paystack documents subscription creation, invoices, successful charges, payment failures and cancellation events. It also states that failed subscription charges are not automatically retried. Your organisation needs a recovery policy: notify the supporter, offer an approved way to update their payment method, and avoid treating a failed gift as received.
The software should preserve a donor’s right to stop future contributions. A cancellation must not delete the donor’s earlier receipts or financial history. If a supporter changes their monthly amount or programme designation, define whether the change applies immediately or from the next collection.
If the requirement is simply adding recurring billing to an existing application, my Paystack subscription integration cost guide covers the generic engineering scope. A donor portal adds campaign restrictions, acknowledgement and nonprofit reporting on top.
The part developers should quote separately: reconciliation
The payment provider knows whether a charge succeeded. Your donor ledger must know which donation it represents and which programme may use it.
For online payments, Paystack’s verification API lets the server check a transaction reference and its status. Its webhook documentation describes signed event delivery. Build for delayed and repeated events: one successful payment must never create two donations or two receipts.
A practical donation record should include a stable internal ID, external transaction reference, donor ID where applicable, amount, currency, campaign designation, payment channel, status and timestamps. Finance also needs a controlled way to record offline bank transfers without pretending they were gateway transactions.
Keep these distinctions explicit:
| Record | What it means |
|---|---|
| Pledge | A supporter’s intention to give |
| Pending payment | A charge not yet confirmed as successful |
| Verified donation | A confirmed successful payment matched to a donation |
| Settlement | Money received through the provider’s settlement process |
| Refund or reversal | A later change that must remain visible in the history |
A beautiful dashboard that collapses these into a single “total raised” number is not sufficient for responsible reporting.
Privacy and ownership are part of the build
Donor records may contain names, contact details, giving history and programme interests. Collect only what the organisation needs, explain the purpose, restrict staff access and agree how long records are kept. Nigeria’s Data Protection Commission provides the relevant regulatory starting point. Get appropriate professional advice on legal obligations; a developer should not invent a donor-consent policy.
Do not publish identifiable donor names or gift amounts on a public transparency page without a suitable lawful basis. Public impact reporting can use aggregate figures and documented programme outcomes instead.
The NGO—not an individual developer—should control its domain, payment account, donor database, hosting and analytics. Ask for role-based staff access, export procedures, backups, a documented deployment process and a clear maintenance owner. Donor data should not become trapped in a developer’s personal account.
For international supporters, verify supported currencies, merchant eligibility, settlement terms and any applicable compliance requirements with the payment provider before commissioning a multi-currency checkout.
Eight acceptance tests before final payment
Ask the developer or software vendor to demonstrate all eight with fictional donor accounts and test-mode payments:
- A one-time gift succeeds and creates exactly one verified donation and receipt.
- A failed or abandoned payment never increases collected totals.
- The same successful webhook delivered twice does not duplicate a donation.
- A monthly donor cancels and no further collection is represented as due under the old instruction.
- A failed recurring charge appears in staff reporting with a safe donor recovery path.
- A donation designated to Programme A is not silently credited to Programme B.
- A refund or manual correction preserves an auditable history and updates reports.
- A staff member without finance permission cannot view or export restricted donor records.
Also require a reconciliation export, delivery logs for important notifications, a real mobile test, an incident contact and a short post-launch support period. The organisation should be able to answer a donor’s payment question without asking the original developer to inspect the database.
What to send a developer for a useful quote
Share the current website, number of active donors (a range is enough), payment methods, recurring-giving requirements, campaigns, donor CRM or spreadsheets in use, staff roles, reporting needs and any international giving plans. Do not send donor records or payment credentials in an initial enquiry.
Ask for two options: configure an existing platform and build only the missing custom workflow. The quote should separate initial configuration, data migration, payment integration, admin reporting, testing, ownership, ongoing software costs and maintenance.
For a broader checkout-only project, see my payment gateway integration guide. If you need a donor portal connected to an existing website or a more substantial internal system, see my MVP development service or send me the current process and what finance cannot reliably do today.
The goal is not to own a custom Donate button. It is to collect, explain and account for contributions reliably—without creating unnecessary software for a small nonprofit.
