TipJar.nz is a simple digital payments platform for schools, clubs and community groups across Aotearoa — think Eftpos without the terminal. You create a "Jar", generate QR codes and payment links, share them around an event, and see donations arrive on a live dashboard. We shipped a production MVP in six weeks to prove the concept, and the project was later picked by Venture Taranaki and presented at a public Showcase in May 2026.
What we set out to prove
For an MVP we had three clear goals:
- Remove barriers to entry: no hardware, no long contracts, no complex setup.
- Enable multiple payment points from one fundraiser (one Jar, many QR codes).
- Keep compliance and risk small so we could launch quickly and safely.
Six-week plan (high level)
We organised the MVP into weekly deliverables so we could show working software fast and iterate with real users.
- Week 1 — Product & design: Define core flows (create Jar, generate QR, pay, dashboard). Wireframes and simple UI components.
- Week 2 — Payments integration: Integrate a card processor via API and decide how to keep PCI scope limited (hosted payment pages / tokenisation).
- Week 3 — Core backend: API, data model for Jars, QR records, donors, payouts and webhooks for payment events.
- Week 4 — Frontend & QR generation: Public payment pages, QR code generation (SVG/PNG), printable assets and share links.
- Week 5 — Dashboard & live updates: Donor list, payment status, basic accounting export and live updates for events.
- Week 6 — Testing & launch: Staging testing, onboarding a handful of local groups, fix feedback, deploy and public launch.
Technical architecture (practical choices)
We made pragmatic choices to reduce build time, keep costs low and leave room to scale later.
- Frontend: Modern server‑rendered React for fast load times and SEO. This also made it simple to produce public payment pages and admin views.
- Backend: Node.js serverless functions for API endpoints (create Jar, list payments, webhook handlers). Serverless reduced ops overhead and made CI/CD straightforward.
- Database: Relational store (Postgres) for Jars, transactions, donors and verification data. The schema keeps payment records immutable and easy to export.
- Payments: We used a PCI‑aware payment processor with a full API and hosted payment options. Using hosted/checkout pages and tokenised cards kept us largely out of PCI‑DSS scope and let us rely on the processor for secure card handling and payouts.
- QR codes & links: Each Jar has a unique public URL. We generate QR codes (SVG for printing, PNG for easy sharing) for the jar URL and optionally append location or point‑of‑sale parameters so organisers can track which QR code was used.
- Webhooks & live updates: Payment events come in via webhooks. We push live updates to dashboards with Server‑Sent Events or lightweight WebSockets so organisers can see who’s paid in real time.
- Hosting & deployment: Frontend on a static/edge host and serverless functions for APIs. Database hosted on a managed provider for reliability and backups.
Payments, fees and compliance
Key product constraints were transparency and quick settlement for community groups:
- Platform fee: we kept the platform simple — a flat percentage on successful transactions and no monthly fees (this is the model used on TipJar.nz).
- Payouts: organiser bank payouts are handled by the payment processor. We configured automatic transfers so money typically reaches organiser accounts quickly (timing depends on bank and processor).
- KYC & AML: onboarding requires organisers to provide identity and bank details. For the MVP we limited eligibility (community groups, schools, clubs) and performed minimal verification so we could launch responsibly while managing risk.
- PCI & security: by using the processor’s hosted payment flows and tokenisation we avoided handling raw card data. All site traffic is TLS encrypted, we signed and verified webhooks, and we put rate limits on key endpoints.
UX and product choices that mattered
- One Jar, many QR codes: A Jar represents a fundraiser. You can print a QR for each table, booth or activity but all payments map back to the same Jar. We added an optional "location" tag on each QR to track where payments came from.
- Fast setup: Create a Jar in under a minute, no credit card for signup. Reducing friction was essential for adoption by volunteer organisers.
- Transparency: Live donor list and the ability to export transactions made it easier for treasurers to reconcile and for organisers to follow up.
- Share options: QR for print, short links for SMS/email, and copyable payment links for social channels.
Testing, launch and early validation
We tested on three fronts:
- Technical tests: unit tests for critical logic, integration tests for payment flows using sandbox credentials, and end‑to‑end tests for signup, Jar creation and payment completion.
- Usability: we ran quick sessions with volunteers from local clubs and a school to observe the flow of generating, printing and scanning QR codes.
- Real events: we onboarded a few community partners for soft launches to verify that payouts, refunds and reporting worked as expected.
The project was selected by Venture Taranaki as a promising local initiative, and we presented TipJar.nz at a public Showcase in May 2026 — that public demo was useful for getting feedback from other community organisations and potential partners.
What we learned (practical takeaways)
- Start narrow: Solve one problem very well. For us that meant focusing on fast QR payments and reconciliation for fundraisers before adding subscriptions, fundraising tiers or donor profiles.
- Keep PCI out of scope early: Use hosted payment pages or tokenisation to avoid the heavy lift of full PCI compliance during the MVP.
- Instrument everything: Recording where payments come from (which QR) and why (payment metadata) powers follow‑up and improves collection rates.
- Design for volunteers: Simple language, minimal setup and printable assets matter. Many organisers are time‑poor and tech‑light.
- Iterate with real users: Run a few real events before a big public launch to find edge cases in reconciling fees, refunds and disputed charges.
Next steps
For TipJar.nz the next phases are improving onboarding, adding better reporting for treasurers, and adding integrations with common accounting tools. We’ll keep iterating based on feedback from clubs and schools across Aotearoa.
If you want to try it, visit tipjar.nz or get in touch for a 15‑minute walkthrough. If you’re a developer or organisation planning a similar MVP and want the technical notes or schema we used, get in touch — we’re happy to share more detailed examples.