How to Build an Online Donation & Fundraising Platform: A Practical Guide for NPOs, Temples & Associations (Real Costs + 90-Day Roadmap)

Your annual campaign is ending — and your receipts are still typed by hand in Excel

A mid-sized welfare association targets NT$3 million a year. In peak season roughly 800 gifts arrive in a single month, about 30% of them small monthly recurring donations. The problem: receipts are issued by volunteers by hand, tax data is reconciled in Excel, and recurring credit-card charges have to be re-run manually each month. Month-end reconciliation alone eats 2 working days. Worse, last year 47 recurring cards failed to charge because they had expired, no one followed up, and nearly NT$80,000 in recurring gifts simply walked away. None of this is a "the website isn't pretty enough" problem — it's a workflow that was never wired into a system.

When it fits × when it doesn't

Not every organization should build its own platform right now. Figure out which cell you fall into first — it can save you six figures.

Good fit for a custom platform	Not needed yet (off-the-shelf is fine)
> 1,000 gifts a year and reconciliation is a burden	< 200 gifts a year, one-off single-campaign fundraising
You need recurring donations with auto-retry on failure	One-time gifts only; manual receipts are acceptable
You must issue tax-deductible e-receipts and connect e-invoicing	Donors don't care about electronic receipts
You need member systems, segmented email and gift history	No IT ops staff and no plan to outsource
Brand and data sovereignty matter (no platform lock-in)	Budget < NT$100k and you need launch in two weeks

Alternatives matrix: build vs payment donation modules vs dedicated SaaS

Option	Pros	Cons	Cost tier
Custom build (Laravel + ECPay/TapPay)	Full data ownership, custom flows, no platform cut, deep member integration	High upfront cost, needs maintenance, longer to launch	Build NT$120k–400k + NT$30k–80k/yr maintenance
ECPay / NEWEBPAY donation module	Native payments, fast launch, transparent fees	Limited templates; e-receipts and members handled separately	Near-zero build fee, ~2.75% processing fee
Dedicated SaaS (DonorFlow/Neon/Donorbox)	Feature-complete, built-in recurring and reporting	Monthly fee + cut, data on someone else's servers, limited customization	From US$50/mo + 2–5% cut

The full process, step by step: from interview to launch

A platform that auto-handles recurring gifts and tax-deductible receipts usually splits into four stages over about 8–12 weeks.

Stage 1 · Requirements & workflow (1–2 weeks): Clarify gift types, receipt/tax rules and reconciliation windows. Deliverables: requirements spec and payment-option recommendation. Tools: interviews + flow diagrams.
Stage 2 · Design (2 weeks): UI for the donation page, recurring-donation setup and receipt-download page. Deliverables: high-fidelity Figma prototype and responsive layouts.
Stage 3 · Development & payment integration (3–5 weeks): Build the backend in Laravel, integrate ECPay or TapPay for recurring charges and auto-retry, and connect the Ministry of Finance e-invoice system to issue tax-deductible e-receipts. Deliverable: a testable environment.
Stage 4 · Testing & launch (1–2 weeks): Small live charges, reconciliation checks, SSL certificate, and launch training. Deliverables: live site and admin operations manual.

The real cost, fully broken down (including hidden fees)

The build fee on the quote is just the tip of the iceberg. What matters is what gets deducted every month.

Processing fees: credit card ~2.75% via ECPay; via Stripe international cards ~2.9% + NT$10. On every NT$1M raised, that's roughly NT$27,500–30,000.
SSL certificate: near-free with Cloudflare or Let's Encrypt; a commercial EV cert runs ~NT$3,000–8,000/yr.
E-invoice / receipt integration: one-time integration labor ~NT$20k–50k; some value-added centers add NT$500–1,500/mo.
Hosting & ops: VPS ~NT$800–2,500/mo; annual maintenance contract ~NT$30k–80k.
Development labor: recurring charges + failure retry + tax receipts are the biggest hidden-labor chunk, roughly 30% of the dev budget.

Implementation reality vs client imagination

Client imagines	Implementation reality
"Recurring donations just auto-charge each month — easy"	The hard part is the retry-and-notify flow for expired cards and insufficient funds; that's what retains recurring donors
"E-receipts are one click"	They must meet Ministry of Finance rules and bind donor data to the tax year; integration and testing take the most time
"Once it launches, we're done"	Reconciliation, refunds, donor support and annual fundraising-permit renewal are the long-term work

Common pitfalls × how to avoid them

One-time only, no failure retry: the biggest leak in recurring gifts is failed charges no one chases. Fix: built-in auto-retry + email/SMS asking the donor to update their card.
Receipts not bound to the tax year: donors can't reconcile at tax time. Fix: clearly label the donation year and produce annual proofs per Ministry of Finance donation-deduction rules.
Payment account under a personal name: later the funds can't be tied to the organization and audits break. Fix: apply for the merchant account under the registered organization from day one.
No reconciliation mechanism: incoming funds don't match system records. Fix: store the payment gateway's transaction ID per gift and offer an exportable reconciliation report.
No plan for privacy and refunds: chaos when a donor asks to delete data or get a refund. Fix: define a data-retention policy and refund SOP before launch.

Success metrics + a 90-day post-launch roadmap

Recommended metrics: recurring-charge success rate (target > 95%), automatic receipt issuance rate (target 100%), and month-end reconciliation hours (target: from 2 days down to 2 hours).

Days 0–30: Go live, run the first 50 real gifts to verify charging and receipts; monitor failed transactions daily.
Days 31–60: Turn on recurring donations, configure retry and notifications; migrate legacy Excel donors in batches.
Days 61–90: Connect member/segmented email, run your first recurring-donation recruitment push; produce the first full monthly report and annual tax-receipt summary.

Decision checklist

☐ What is our annual gift volume and share of recurring donations?
☐ How many hours does reconciliation eat each month today?
☐ Do we need to issue tax-deductible e-receipts?
☐ Is the payment merchant account already under the organization's name?
☐ How will failed recurring charges be notified and retried?
☐ Should donation data connect to a member system?
☐ Are refund and data-deletion SOPs defined?
☐ Who owns the annual fundraising-permit renewal?
☐ What's the total budget including build and first-year ops?
☐ Do we have in-house staff to maintain it, or need outsourced ops?
☐ How important is data sovereignty (can we accept SaaS cuts)?
☐ What launch timeline do we expect, in weeks?

ScriptWalker's take: most NPOs underestimate not the build fee but the long-term value of "recurring-charge retry." Lifting the success rate from 85% to 95% can retain, over a year, recurring gifts equal to a part-time salary. That's the module we recommend investing in first.

FAQ

What's the technical difference between recurring and one-time gifts?

A one-time gift is a single authorized charge. Recurring donations require storing the authorization, auto-charging monthly, and handling retries and notifications for expired cards or insufficient funds. The hidden labor of the latter is often several times the former — and it's key to retaining recurring donors.

Are e-receipts tax-deductible? What do they connect to?

Per Ministry of Finance rules, gifts to legally registered organizations with fundraising qualifications can be itemized. The system must correctly record the donation year and donor data, and can connect to the Ministry of Finance e-invoice system or a value-added center to issue e-receipts.

Is building always cheaper than SaaS?

Not necessarily. With low gift volume and no recurring needs, SaaS or a payment donation module is faster and cheaper. Building pays off when cumulative cuts and monthly fees exceed the amortized build cost, or when you need data sovereignty and deep customization.

Roughly how much are processing fees?

Domestic credit cards via ECPay run ~2.75%; Stripe international cards ~2.9% + NT$10. Raising NT$3M a year means roughly NT$80k–90k in fees — budget for it.

Next step: let reconciliation and receipts run themselves

ScriptWalker offers a Donation Platform Build service starting at NT$120,000, covering the donation page, recurring charges, failure retry, tax-deductible e-receipts and reconciliation reports, plus integration with ECPay or TapPay. Want to first assess whether your organization should build or use off-the-shelf? Send us your annual gift volume and pain points for a free consultation.