GGenerous.nz

Current version

v0.9.312

Showing versions 313–320 of 324

Changelog

All notable changes to Generous.nz are recorded here, grouped by version. Every deployed build has a version number, a git tag, and an entry below.

Versioning scheme

Versions follow MAJOR.MINOR.PATCH:

  • 0.x — pre-launch. Minor bumps mark a completed build phase or major feature set; patches are bug fixes on the current build.
  • 1.0.0 — first public launch.
  • 1.x+ — post-launch: minor = new features, patch = fixes, major = breaking changes or significant re-architecture.

Each version is tagged in git (v0.2.0) and the current version is kept in package.json. See docs/version-control.md for how to cut a release.

[0.9.1] — 2026-08-24

Goal-gradient improvements (XXXXX-style).

Changed

  • "Raised" now counts product sales too — donations + paid orders (including wholesale sales) drive the progress bar, the dashboard totals, and the organisation storefront, so the number tells the truth on every campaign type.
  • "X left to go" under the bar — the goal-gradient trigger shows how much is needed, not just a percentage.
  • "Goal reached 🎉" state — when raised crosses the goal the bar celebrates instead of capping silently.

Added

  • Goal celebration (lib/milestones.ts): when a payment crosses the goal, the platform posts a campaign update from the owner and emails every supporter (donors + buyers). Fires once per goal; if a refund drops the total below the goal the flag clears so it can fire again.
  • Extend goal: fundraisers can raise their target from the dashboard once reached (resets goalReachedAt so urgency and celebration restart).
  • New Fundraiser.goalReachedAt field (migration 0020_goal_milestones).

Documentation

  • Help centre "How goals and progress work" article updated.

[0.9.0] — 2026-08-24

Option A — direct charges. The payment architecture is rebuilt so the platform never touches sale or commission money.

Changed (payment architecture)

  • Every payment is now a direct charge to the seller's own Stripe account (the business for wholesale items, the fundraiser for their own items, donations and subscriptions). No more destination charges, transfers, on_behalf_of or application fees.
  • Wholesale: the business is the merchant of record. The buyer pays the business directly; the business pays the fundraiser's commission (minimum 10%) via automatically generated invoices, charged to a card the business saves once (Stripe's official cross-account card-cloning pattern).
  • Platform fee: 5% + GST is now invoiced to the fundraiser on a weekly cycle (PLATFORM_FEE_BILLING_CADENCE_DAYS, default 7) and auto-charged to a card the fundraiser saves once. It is no longer taken from payments.
  • Refunds and chargebacks are debited from the seller's Stripe balance; commission on refunded/disputed orders is cancelled or credited against the next invoice. The platform no longer backstops sale/commission chargebacks.
  • Receipts show the real seller (business for wholesale, fundraiser otherwise). Commission invoices include GST only when the fundraiser is GST-registered (Fundraiser.gstRegistered).

Added

  • New schema (migration 0019_option_a_direct_charges): CommissionInvoice, PlatformFeeInvoice, WholesalerConnectedCustomer, settlement INVOICED/CREDITED statuses, billing-card fields.
  • Commission engine (lib/commission.ts) and platform-fee billing (lib/platform-fee-billing.ts) with automatic retries and reminders.
  • Card setup flows: businesses add a commission card in Billing; fundraisers add a fee card in the dashboard (hosted Stripe setup, no card data stored by the platform).
  • Commission invoice history on the wholesaler billing page; updated settlement statuses in the admin area.
  • New email templates: commission invoice issued/paid, card reminders, platform-fee invoice + reminder.
  • Webhook events updated for direct charges and invoices (invoice.paid, invoice.payment_failed, invoice.finalized); webhook endpoint must listen to events on connected accounts.
  • Legal sign-off pack for your accountant/lawyer: docs/legal-signoff-option-a.md.

Documentation

  • Fundraiser, Wholesaler, Seller agreements + Terms, Privacy, Refund, Dispute and AML-CFT policies updated to the direct-charge model.
  • Help centre updated (how payments work, platform fees, commission invoicing for businesses, Stripe setup with the fee card step).
  • docs/stripe-architecture.md, docs/wholesale-marketplace.md, docs/stripe-setup.md, docs/go-live.md rewritten for Option A.

Deployment notes

  • Apply migration 0019 on the server (prisma migrate deploy runs automatically on deploy).
  • Re-point the Stripe webhook to listen to your account AND connected accounts and enable the new invoice events (see docs/stripe-setup.md).
  • Fundraisers and businesses must add their payment cards; run the test-mode drills in docs/stripe-setup.md before live.

[0.8.2] — 2026-08-24

Help centre — Stripe setup guides.

Added

  • New Stripe setup category in the help centre with three articles:
    • Full Stripe account setup (step by step) — what information is needed (legal name, DOB, address, ID, bank account, sometimes IRD), the exact steps from the dashboard through hosted onboarding, and troubleshooting.
    • Why do I need to verify my identity and give my bank details? — the KYC/AML reasons in plain language.
    • Understanding the admin Payments setup page — what the page checks (keys, webhook events, connected accounts) and how to use it.
  • The admin Payments setup page now links to the help article explaining it.

Corrected (review of an external AI answer)

  • This platform uses Stripe Connect Standard accounts with Stripe-hosted onboarding — not Express or Custom. The help article reflects that: Stripe collects identity and bank details directly, the platform never sees them, and no business fields or MCC codes are pre-filled by the platform (a Custom-account pattern that does not apply here).
  • The required-information list and the “moderate friction” assessment from the reviewed answer were accurate and are now documented in the help centre, written for a casual fundraiser (school PTA, muffin stall, etc.).

[0.8.1] — 2026-08-24

Tax-position hardening (seller of record + fee-only income).

Fixed

  • Seller of record on every payment: on_behalf_of is now set on non-wholesale product orders, one-off donations and recurring donation subscriptions (it already applied to wholesale orders). The fundraiser's Stripe account is the settlement merchant for every transaction, so card statements and charge details show the fundraiser — never the platform.
  • Receipts and tax invoices name the seller correctly: buyer-facing documents now show the organisation name when a campaign runs under one (otherwise the owner's name) instead of only the personal name — order receipts, donation receipts, voucher emails and the printable voucher all use the same seller identity. The platform is never shown as the seller.
  • Agreements now match the actual money flow: the Fundraiser Agreement and Seller Agreement no longer describe a transfer "from the fundraiser's balance" (which Stripe does not support). They now state that the buyer's payment settles directly to the fundraiser's connected account, the platform only facilitates payment, and the wholesaler's share is paid from funds held on settlement.

Verified (no change needed)

  • Money never sits in the platform balance: destination charges route the fundraiser's proceeds straight to their account at capture; the platform balance only ever holds the application fee (plus the wholesaler share in transit on wholesale orders).
  • Refunds use reverse_transfer, pulling money back from the fundraiser's account rather than the platform balance.
  • The GST export reports only platform fees + GST (the platform's own supply), never the gross sale amounts.

[0.8.0] — 2026-08-24

Blog with AI publishing.

Added

  • Public blog at /blog and /blog/{slug} with a list page, SEO metadata, cover images, excerpts and styled Markdown rendering (migration 0018).
  • Publishing API (/api/blog) that lets an external AI create, publish, update and delete posts using a bearer token (BLOG_API_TOKEN) — no login or password needed. Draft-first workflow, auto slug generation, and a verification list endpoint.
  • Admin blog area (Admin → Blog posts): write in Markdown, set author/cover/excerpt/status, publish/unpublish/archive/delete, and a status banner for the publishing API.
  • Guide for the writing AI: docs/blog-publishing.md with endpoints, JSON schema, curl examples, markdown rules, a suggested workflow, and a ready-to-paste instruction block.
  • Blog link in the site header and footer.

Changed

  • Go-live checklist includes the BLOG_API_TOKEN configuration step.

[0.7.0] — 2026-08-24

Voucher fulfilment build-out.

Added

  • Voucher conditions: wholesalers can set voucher terms (availability, times, validity, restrictions) on voucher products, shown on the public catalogue, explore, and fundraiser product pages alongside the voucher count (migration 0017).
  • Sold-voucher tracking: the business receives an email on every voucher sale with the customer's name, email and the exact codes issued.
  • Printable voucher: buyers get a signed link to a print-ready voucher page (branded, with codes, terms and fulfilment details) — print it or save as PDF. The voucher email now includes the terms and the link.
  • Voucher sales area: wholesalers see every sold code and its customer in a new dashboard page, with a CSV export of the full history.
  • Bulk voucher import CSV template now supports the voucher_terms column.

Changed

  • Voucher delivery email includes conditions and the printable-voucher link.

[0.6.0] — 2026-08-24

AI order fraud screening.

Added

  • DeepSeek order screen: when ORDER_FRAUD_ENABLED=true, every order is screened at checkout with the configured provider (DeepSeek Flash by default) using buyer, velocity, account-age and order signals.
    • Block (score ≥ 0.8 default): the order is refused before any payment.
    • Review (score ≥ 0.5 default): the customer can pay, but the order is held for human review — wholesaler payout and fulfilment pause until a moderator approves it.
    • Approve: processed normally.
    • If the provider is down, orders fail open for the sale but are queued for review rather than paid out.
  • Stripe Radar gate: the payment webhook checks Stripe's own risk level and holds any order flagged "elevated" or "highest" for the same human review, regardless of the AI verdict at checkout.
  • Order review in the moderation queue: flagged orders appear with product, amount, buyer and status. Approve releases the payout hold; reject cancels the order, refunds the buyer and cancels the settlement (migration 0016: ORDER resource type + orderId on flags).

Changed

  • Fraud runbook and go-live docs updated with the order-screen configuration and review workflow.

[0.5.0] — 2026-08-24

Business opportunities landing page.

Added

  • New public /business page ("For businesses") with the full supplier offer: free listings that don't expire, the business chooses the fundraiser's share (min 10%), 5% platform fee (+ GST) only on sales, 100% claimable as a business advertising expense (with accountant guidance), and no sales = no charge.
  • Inline one-step sign-up: name, business name, email and password creates the account and submits the wholesale application automatically, so a business lands on the wholesale dashboard ready to list products.
  • Example sale split (wholesale price / fundraiser share / platform fee) and a three-step "how it works" section.
  • Header nav link ("For businesses") and a cross-link from the public wholesale catalogue.