SwiftCause turns every £1 donated into £1.25 by capturing Gift Aid declarations digitally. The entire platform is built around one idea: a donor taps their card or phone, and we capture enough information — securely, compliantly, with minimal friction — to let the charity reclaim 25% from HMRC.
For donations £30 and under, GASDS lets charities claim the same 25% without donor details — but only if they meet two prerequisites: (1) the 10x matching rule (GASDS cannot exceed 10x standard Gift Aid), and (2) the 2-year Gift Aid history rule — the charity must have made successful Gift Aid claims in at least 2 of the last 4 tax years before GASDS becomes available. So Gift Aid capture is the engine that powers everything, and it takes at least 2 years before GASDS kicks in for charities new to Gift Aid.
The fundamental tension surfaced in the 13 April meeting:
The magic link bridges this gap: donor scans a QR code, opens a page on their own phone, and provides their details. This happens off the collection point — there is no queue impact. The only risk is donor abandonment (closing the tab).
Competitors solve the identity problem differently: Dona, Hibabox, and CollecTin use card token recognition — the physical card is the identity, and same card tapping again auto-applies Gift Aid. Swiftaid operates a separate donor network matched by card token. None of them use email verification or OTP. SwiftCause's magic link flow is architecturally different because the payment device and the donor's phone are separate — the card token and the phone session are disconnected.
Everything else is secondary to these three outcomes:
| # | Objective | Why It Matters | Current Status |
|---|---|---|---|
| 1 | Maximise Gift Aid capture rate on the magic link | Every completed declaration = £0.25 per £1 for the charity + 3% commission for SwiftCause. It also feeds the 10x GASDS multiplier. This is the revenue engine. | Magic link shipped (PR #622). Gift Aid form flow design in progress — Option C (accept all, verify later) recommended. Pilot KPI target: ≥50% completion. |
| 2 | Protect donor data without killing the flow | The 13 Apr meeting identified that the current magic link exposes stored donor data to anyone who enters an email. Must be fixed before launch — but the fix must not add friction that tanks the capture rate. | Solution: don't show stored data to unverified users. New donors always see a blank form (zero risk). Returning verified donors get OTP-gated prefill. Passive verification via thank-you email builds the verified account base over time. |
| 3 | Build the Gift Aid base that unlocks GASDS | GASDS is the "free money" pitch to treasurers — 25% back on anonymous £30-and-under taps with no donor details needed. But it only works if the charity has enough standard Gift Aid (10x rule). The magic link recovery path and the Day 1 recurring subscription strategy both feed this base. | GASDS pool tracking and community building location tagging are post-launch Phase 2. The foundation (Gift Aid capture) must work first. |
If we don't solve Gift Aid capture properly, charities can't claim, GASDS stays locked, and the commercial model collapses. The flow design (Option A/B/C) directly determines the capture rate, which directly determines revenue — for the charity and for SwiftCause.
Donor has time — church service, office collection, community hall. Gift Aid captured before or alongside payment.
Identity solved: Donor provides everything upfront. No gap. Postcode validated. Declaration created BEFORE payment (status: pending), upgraded to "active" by Stripe webhook.
High-traffic: Friday prayers, events, festivals. Speed matters — tap in under 15 seconds, Gift Aid captured later.
Token is valid for 30 days. If the donor never scans the QR, the donation still exists but with isGiftAidCaptured: false — it goes into the GASDS-eligible pool if £30 or under.
Collection point offers the full Gift Aid panel (Flow A). If the donor skips it, they get the QR follow-up path (Flow B+). Best of both worlds — catches willing donors immediately, recovers the rest via magic link.
Raised in today's meeting: can we harvest payer identity (name, email, billing address) from Apple Pay or Google Pay via Stripe's payment data?
billing_details object that may contain name, email, and billing address — but only if the wallet is configured with these details and the Stripe PaymentIntent requests them. This is a genuine shortcut: if the donor's wallet provides a verified billing address, we could pre-fill the Gift Aid form and just ask for confirmation + consent. This needs a feasibility spike — it could eliminate the identity gap for wallet-paying donors entirely.
What: The magic link page currently lets anyone type any email address. If that email matches an existing donor profile, their full name and home address are displayed and editable. This is both a data protection risk and a GDPR violation.
Meeting outcome: Team agreed OTP or email-link verification is required before showing or editing any stored data. Approach not yet finalised (OTP vs email link vs defer email collection).
Impact: Cannot safely launch returning donor recognition. Cannot build trust with charities handling sensitive donor data.
What: Donations over £30 are NOT eligible for GASDS — they need full Gift Aid declarations with name, address, postcode. If the donor taps £50 via Apple Pay, doesn't scan the QR, and never provides email — that £12.50 Gift Aid is gone forever.
Meeting outcome: Action on Qamar to determine how to capture details when amount is over £30 and email is missing. OTP route being assessed.
Impact: Every missed £50+ donation costs the charity £12.50+. At scale this is thousands per year.
What: The Consent Ledger architecture was approved on 30 March. Magic link shipped (PR #622). But the sprint is on Day 16 and the core consent event tasks — token generation, Cloud Function trigger, IP capture, donor reconciliation — remain unassigned.
Impact: Without the consent ledger, Gift Aid declarations lack the audit provenance HMRC requires. The declaration exists but can't prove when, where, and how consent was given.
What: Meeting discussed scenarios where wrong emails get attached to donations, or the same email appears on multiple conflicting records. No admin UI exists to flag, review, or resolve these.
Meeting outcome: Agreement to build a "duplicate email anomaly area" for treasurer/admin review with manual resolution and audit trail. Super-admin correction workflow needed for wrongly attributed records.
GiftAidDetailsPanel.tsx uses JavaScript's getFullYear() instead of the UK tax year boundary (6 April). Any donation between 1 January and 5 April gets assigned to the wrong tax year, which means the HMRC CSV export will have incorrect data.
What: Can we pull billing name, email, and address from wallet payment data via Stripe to pre-fill Gift Aid forms? This could dramatically reduce friction for the majority of tap-to-pay donors.
Status: Feasibility investigation assigned to team. Legal permissions and technical scope to be confirmed. If viable, this changes the entire identity strategy.
These recommendations synthesise today's meeting discussion, HMRC compliance requirements, the SwiftCause architecture, and practical delivery constraints.
The problem it solves: Anyone can enter any email on the magic link page and access stored donor data.
Why OTP over email-link: The donor is already on their phone from scanning the QR. Sending another magic link creates confusion ("which link do I click?"). A 6-digit code they can see in their email notification banner and type in keeps them on the same page — no context switch. Firebase Auth supports this natively.
Fallback for donors who skip OTP: Allow Gift Aid form submission without email verification, but treat the record as "unverified" — it maps to the token/donation only, does NOT create or update a donor profile, and does NOT prefill on future visits. Gift Aid is still claimable (HMRC doesn't require email verification, just the declaration data).
The problem it solves: The identity gap — donors are anonymous at tap time.
payment_intent.charges.data[0].billing_detailsname, email, address.line1, address.postal_codeIf this works: The magic link page becomes a simple confirmation ("Is this your home address? Yes/No") rather than a full form. Gift Aid completion rates could jump from ~50% to 80%+. The email verification problem is also reduced because the wallet email is inherently verified by Apple/Google.
If this doesn't work: We proceed with OTP-gated manual entry (Solution 1). No time wasted — the spike proves/disproves the assumption quickly.
Legal note: Even if Stripe provides the data, we still need explicit opt-in consent to use it for Gift Aid purposes. The wallet consent covers payment, not tax reclaim. Add a clear "I confirm this is my home address and I want to Gift Aid this donation" checkbox.
The problem it solves: Today's meeting identified confusion about what data is required at different donation amounts.
| Scenario | Amount | Data Required | Gift Aid Path | Fallback |
|---|---|---|---|---|
| Small anonymous tap | £30 or under | None — payment only | GASDS pool (no declaration needed) | Charity claims at year-end, subject to 10x rule |
| Small tap + QR scanned | £30 or under | Email + name + address (if donor engages) | Standard Gift Aid (better than GASDS — builds the 10x base) | Falls back to GASDS pool if donor doesn't complete |
| Larger donation, no QR | Over £30 | MUST have name + home address + postcode | Gift Aid only — NOT GASDS eligible | Gift Aid LOST. No reclaim possible. |
| Larger donation + QR scanned | Over £30 | Email (verified) + name + address + postcode | Standard Gift Aid via magic link | 30-day token window to recover |
The problem it solves: Today's meeting asked "what is stored against the token vs. verified email, and when does the record become an identified donor?"
| Stage | State | What's Stored | Permissions |
|---|---|---|---|
| 1. Anonymous | Token created at payment | Stripe payment ID, amount, timestamp, device fingerprint, location | No donor data shown. QR code generated. |
| 2. Claimed | Email entered + OTP verified | Above + verified email, opt-in consent event, IP, user agent | If returning: prefill shown (read-only until confirmed). If new: blank form. |
| 3. Declared | Gift Aid form submitted | Above + full name, home address, postcode, declaration text, taxpayer confirmation | Donor profile created/updated. Declaration linked to donation. HMRC-ready. |
The critical rule: data never moves backwards. Once a declaration is timestamped and archived (as a PDF per today's meeting decision), it becomes immutable. Any correction requires a super-admin audit-trailed amendment — not an edit to the original record.
The problem it solves: Wrong emails, duplicate records, conflicting donor data.
From today's meeting: Once a donor has completed Gift Aid with a verified email and opted in, create a lightweight account. Future donations from this donor (via email match or wallet data match) auto-apply their existing Gift Aid declaration.
The OTP sent for email verification doubles as the account creation trigger. No separate signup flow needed. The donor's "account" is simply their verified email + their most recent declaration with futureConsent: true.
This directly supports the commercial model: once a donor has an account, they're on the path to recurring Gift Aided subscriptions — which builds the 10x GASDS base.
Every campaign in SwiftCause is set to exactly one of two modes at the campaign level. This auto-enforces the Two-Pile Logic without item-level drill-down or inventory.
e.g., "General Maintenance", "Roof Fund", "Sadaqah", "Tithe"
e.g., "Madrasah Fees", "Weekly Subs", "Class Fees", "Event Tickets"
Under HMRC rules, Activity Mode payments are classified as Primary Purpose Trading, NOT charitable donations. The donor receives a direct benefit (a class for their child, an event ticket, a book) — so these payments are strictly ineligible for Gift Aid.
| Activity Type | HMRC View | SwiftCause Treatment |
|---|---|---|
| Weekly subs / membership (Scouts, afterschool clubs) | Trading income | Hard-lock GA OFF |
| Class fees (gymnastics, Arabic) — fixed fee, place tied to payment | Trading income | Hard-lock GA OFF |
| Madrasah — DEPENDS ON STRUCTURE (see below) | Varies | Varies — see carousel logic |
| Event tickets | Trading income | Hard-lock GA OFF |
| Book sales / physical goods | Trading income | Hard-lock GA OFF |
Member Reference field is NOT required at launch. What IS required: the campaign-level lock must SEGREGATE and MARK records by mode so Activity Mode payments are clearly tagged as non-GA / trading income in the data.
R68 is the official HMRC document required to submit Gift Aid claims. Failure on any of these requirements can invalidate the entire claim and expose the charity to HMRC penalties.
| Requirement | Detail | Risk if Wrong |
|---|---|---|
| HMRC April 6 Tax Year Boundary | UK tax year strictly runs 6 April → 5 April, NOT calendar year. A donation in January 2027 belongs to the tax year that began 6 April 2026 — it does NOT start a new tax year. | Entire claim invalidated + penalties |
| Mandatory Donor Details | Full name, home address (with house number + postcode), UK taxpayer tick | Claim rejected |
| Digital Audit Trail (6 years) | Paperless declarations require IP address, timestamp, unique Transaction ID linked to digital signature — kept for 6 years | Audit failure |
| Monthly Auto-Batching | SwiftCause v2 auto-generates R68 forms, batches declarations, submits monthly to HMRC (not annually) | Cash flow + manual work |
This is the strategic sequence that makes SwiftCause's commercial pitch work. Each stage unlocks the next:
Charity starts taking contactless donations. Every tap under £30 goes into the GASDS-eligible pool. But without standard Gift Aid claims, the GASDS pool is capped at £0 (10x matching: 10 × £0 = £0).
Move regular supporters to recurring Gift Aided subscriptions. Even 10 donors at £10/month = £1,200/year in standard Gift Aid donations. This unlocks £12,000/year of GASDS space (10x).
CRITICAL RULE: A charity must have made successful Gift Aid claims in at least 2 of the previous 4 tax years before they can claim GASDS at all. Newly registered charities that have been claiming GA since registration are exempt. This means charities new to Gift Aid cannot claim GASDS for at least 2 years. Factor this into revenue projections — Year 1 GASDS revenue is £0 for charities starting fresh.
Once the 2-year GA history is established, the charity's BBQ taps, event collections, and walk-in donations under £30 can ALL be claimed. SwiftCause auto-calculates: "You have £12,000 of GASDS space and £8,000 in eligible taps. Claim 100%."
Each qualifying community building (church, mosque, temple, village hall) unlocks a SEPARATE £8,000 GASDS allowance on top of the base cap. To qualify under HMRC: charity must host at least 6 events per year at that specific building with 10+ donors per event. SwiftCause auto-tracks via Fleet Management and Green-Lights buildings the moment they qualify — a genuine differentiator no competitor offers.
SwiftCause tracks and tags transactions to specific community buildings via the Fleet Management system to create the precise digital audit trail HMRC requires for the doubled GASDS allowance.
kiosk_id on every donation BUILT
Every individual donation is automatically marked with a unique kiosk_id that identifies the specific tablet or volunteer phone that processed the payment. This is the only piece that exists today.
kiosk_id → Building_ID mapping NOT BUILT
Admin screen where the charity maps each kiosk to a named building (e.g., "Main Hut", "Church Basement", "Madrasah Hall"). There is no Building_ID field in Firestore and no admin UI for this mapping. Growth/Scale tier feature — not a pilot blocker.
System counts unique event-days per building per tax year and unique donors per event-day per building. None of this exists. Growth/Scale tier feature.
Once the system detects that a kiosk has processed donations across 6 events with 10+ donors at the same building, the dashboard automatically "Green Lights" that location. Growth/Scale tier feature.
donation → kiosk_id → Building_ID → 6-Event Counter → Green Light → +£8k GASDS allowance.
The kiosk-to-building tagging mechanic creates five first-class surfaces the Admin Dashboard needs to expose:
| Surface | What it shows | Audience |
|---|---|---|
| Per-Building Progress Counter | Events-to-date out of 6, donors-per-event out of 10. Visual progress bar toward Green Light threshold. | Treasurer / Admin |
| Green Light Status Indicator | Per-building badge: Not Qualified / Approaching / GREEN LIGHT. Date qualified shown. | Treasurer / Admin |
| Treasurer Alerts / Notifications | Notification fires the moment a building qualifies: "£8,000 GASDS allowance unlocked at [Building Name]." | Treasurer |
| GASDS Pool Reporting (per-building breakout) | Total GASDS pool = base £8k + (each qualified Community Building × £8k). Per-building usage and remaining cap. | Treasurer / Finance |
| Audit Trail Export | Export linking each donation → kiosk_id → Building_ID → event date for HMRC scrutiny. 6-year retention. |
HMRC / Auditor |
This is the post-go-live feature that makes multi-site charities love SwiftCause:
| Location Feature | Gift Aid Impact | GASDS Impact | Status |
|---|---|---|---|
| Tag location as "community building" | No direct impact | Doubles GASDS cap to £16,000 for that location | Post-launch |
| Per-location flow configuration | Set default flow (A, B+, Hybrid) per venue | High-traffic locations default to B+ (more GASDS-eligible taps) | Post-launch |
| Location-level Gift Aid conversion dashboard | Shows % of donations with Gift Aid captured per venue, tracked by postcode/campaign | Shows per-location GASDS pool size vs. 10x cap — each venue tracked independently | Post-launch |
| GASDS pool tracker with "Gap Alert" (per-location) | Prompts charity to get more declarations at specific locations where GASDS pool exceeds that venue's 10x allowance | Prevents money being left on the table — pinpoints which venue needs more Gift Aid declarations | Post-launch |
| Donation mode vs Activity mode per campaign | Gift Aid hard-locked OFF for activity mode | Activity mode payments excluded from GASDS pool | In scope |
This is where it all comes together for mosques, churches, and temples — SwiftCause's primary launch vertical:
The two-pile logic (donation mode vs activity mode) means madrasah fees, event tickets, and book sales are cleanly separated and never accidentally claimed for Gift Aid — which protects the charity from HMRC clawbacks.
| Option | Pros | Cons | Recommendation |
|---|---|---|---|
| A. OTP (6-digit code) | Same-page experience, no context switch, Firebase Auth native support | Requires email delivery (1-2 min delay), donor might abandon | Option A for launch. Simple, proven, keeps donor on same page. Fallback: allow unverified Gift Aid (declaration-only, no profile update). |
| B. Email verification link | Standard pattern, very secure | Donor already followed one link (magic link) — asking them to click another creates confusion and drop-off | |
| C. Defer email entirely | Zero friction | No returning donor recognition, no recovery path, no account creation. Defeats the purpose. |
Owner: Team (needs assigning)
Timeframe: 1-2 days
Deliverable: Test with Stripe sandbox — what fields come back from Apple Pay / Google Pay payments? Can we reliably get name + billing address + email?
Decision gate: If yes → redesign magic link page as "confirm these details" rather than "enter your details". If no → proceed with OTP + manual form.
Tasks #609–#612 have been unassigned for 16 days. These are the backbone of HMRC audit compliance. Without them, Gift Aid declarations are technically valid but lack provenance proof. Needs immediate assignment — ideally to the developer who built PR #622 (magic link infrastructure) since they have the most context.
Today's meeting decided on postcode check as the main verification for Gift Aid. Currently it's manual entry only. Royal Mail PAF lookup would reduce errors and speed up form completion. Not a blocker for launch — postcode validation (format check) is sufficient — but a strong fast-follow for data quality.
Meeting mentioned "six years after last payment" as the retention period. This aligns with HMRC's 6-year record retention requirement for Gift Aid. Needs to be formalised: auto-delete trigger, what counts as "last payment" (last donation? last recurring payment? last HMRC claim?), and how this interacts with GDPR data subject requests.
How the UK contactless donation market solves (or doesn't solve) the same problems we're wrestling with. Updated April 2026.
Every competitor faces the same core problem: a contactless tap is anonymous, but Gift Aid needs a name and address. The market has settled on three distinct approaches to bridging that gap:
| Model | How It Works | Who Uses It | Email OTP? |
|---|---|---|---|
| Card Token Recognition | Donor registers once on the device. Card is tokenised. Same card tapping again = same donor = Gift Aid auto-applied. Physical card is the proof of identity. | Dona, Hibabox, CollecTin, GoodBox (via Swiftaid) | No |
| Donor Network | Donor registers once with a third-party network. Any donation to any member charity is auto-matched via card token. Single authorisation covers all charities for the tax year. | Swiftaid (integrated by GoodBox, JustGiving, Give A Little) | No |
| QR → Web Form | Donor scans QR, opens a web page, fills in details. Form submitted = Gift Aid captured. No card token link — relies on the donor completing the form. | DonationPay, PayaCharity QR, GiveTap QR/NFC | No |
SwiftCause advantage: Software-only, any device, two-pile logic (sadaqah vs madrasah fees), GASDS community building tracking.
SwiftCause advantage: Zero hardware cost, magic link recovery, multi-device deployment.
Watch this one: GiveTap's Tap to Pay on smartphone is the closest to SwiftCause's "any device" positioning.
SwiftCause advantage: No hardware cost, lower transaction fees, GASDS tracking, two-pile logic.
| Feature | Dona | Swiftaid | GoodBox | DonationPay | Hibabox | CollecTin | GiveTap | SwiftCause |
|---|---|---|---|---|---|---|---|---|
| Hardware required | Yes | N/A | Yes | No | Yes | Yes | Optional | No |
| Card tap collection | Yes | N/A | Yes | No | Yes | Yes | Yes | Yes |
| QR code collection | No | N/A | No | Yes | No | No | Yes | Yes |
| Gift Aid on-device | Yes | N/A | Via Swiftaid | Web form | Yes | Yes | In-app | Yes + magic link |
| Post-tap Gift Aid recovery | No | N/A | No | No | No | No | No | Yes (30-day) |
| Returning donor recognition | Card token | Card token | Via Swiftaid | No | Card token | Card token | Unknown | Email (needs OTP) |
| Email OTP verification | No | No | No | No | No | No | No | Planned |
| GASDS pool tracking | No | No | No | No | No | No | No | Yes (planned) |
| Community building cap | No | No | No | No | No | No | No | Yes (planned) |
| Two-pile (donation/activity) | No | No | No | No | No | No | No | Yes |
| HMRC CSV export | Yes | Auto-submit | Via Swiftaid | Yes | Unknown | Yes | Yes | Yes |
| Gift Aid commission | 5% | 5% (free <£6k) | 5% | Incl. | Unknown | Via partner | Unknown | 3% |
| Multi-collector deployment | Per device | N/A | Per device | QR only | Per device | Per device | Per phone | Unlimited devices |
An honest pressure-test of SwiftCause's "we show you exactly how much you can claim" differentiator — and the conditions that must be true for it to land.
"We show you exactly how much you can claim from HMRC — per venue, per tax year. Your GASDS pool at each location, tracked by postcode against its own cap. Your 10x allowance calculated per campaign. Your community building bonus tracked separately. One-click HMRC export. No other platform does this."
This is genuinely differentiated. No competitor — Dona, GoodBox, Hibabox, DonationPay — offers multi-location GASDS pool tracking by postcode, per-campaign 10x cap alerting, or community building doubled cap management. Charities with multiple venues get real visibility for the first time.
The GASDS dashboard is only impressive when there's a healthy Gift Aid base underneath it. The pitch has a hidden dependency chain — each link must hold or the whole thing collapses:
Let's take a typical mosque or church using SwiftCause:
Note: The Gift Aid capture rates (15%, 40%, 60%) are illustrative scenarios, not measured data. Dona reports >40% on-device. Actual rates for the magic link flow will be validated during the pilot — see Pilot Metrics section below.
| Scenario | Monthly Donations | Gift Aid Capture Rate | Std Gift Aid Base (Annual) | GASDS Space Unlocked (10x) | Actual GASDS Pool (anonymous taps ≤£30) | Claimable? |
|---|---|---|---|---|---|---|
| Low friction fail | £3,000 | 15% | £5,400 | £54,000 | £18,000 | Yes but barely — 15% capture means few recurring donors, weak pitch |
| Moderate capture | £3,000 | 40% | £14,400 | £144,000 | £18,000 | Yes, fully — £4,500 reclaim. Dashboard looks great. |
| High capture (target) | £3,000 | 60% | £21,600 | £216,000 | £18,000 | Yes, fully + massive headroom. 10x base far exceeds pool. |
| Feature | Defensibility | Why |
|---|---|---|
| GASDS pool dashboard (multi-location) | MEDIUM | Not a simple filter+sum. Each charity location is tracked by postcode and mapped to a campaign. The dashboard must show per-location GASDS pools, aggregate across locations, and let treasurers see which venues are generating eligible donations vs. which are under-performing. Requires a location/campaign model that no competitor has. |
| 10x cap alerting (per-location) | MEDIUM | The 10x rule must be calculated per location (postcode/campaign), not just globally. A charity with 5 venues needs 5 separate Gift Aid vs. GASDS pool comparisons, each checked against its own cap. Requires the same location infrastructure as the dashboard — compounds in complexity. |
| Community building doubled cap | MEDIUM-HIGH | Requires location tagging by postcode + per-location GASDS pool tracking + knowing which locations qualify as community buildings (£16k cap) vs. standard (£8k cap). The charity must register each building with HMRC — SwiftCause tracks this status per campaign. Competitors would need to build the entire location model from scratch. |
| 30-day magic link Gift Aid recovery | HIGH | Unique in the market. Requires the token infrastructure, webhook integration, post-tap flow, and consent ledger. No competitor has any of this. Hard to retro-fit onto hardware-based systems. |
| Two-pile logic (donation vs activity) | HIGH | Campaign-level compliance lock, hard-coded Gift Aid off for activity mode, mandatory member reference. Requires deep domain knowledge of religious sector operations. None of the competitors have even attempted this. |
| Card fingerprint + magic link + GASDS tracking as a system | VERY HIGH | The combination of all three layers is the moat. Any one feature is copiable. All three together, with the religious sector domain expertise, is genuinely hard to replicate. |
The sales story to treasurers is: "GASDS, Location Management & the Gift Aid Progression."
That story only works if Gift Aid declarations actually get captured at volume. The 10x rule means every declaration is worth 10× its value in GASDS unlocking. So the flow design choice directly controls whether the narrative holds up or collapses.
| Option | Impact on Gift Aid Base | Impact on Location Tracking | Does It Break the Narrative? |
|---|---|---|---|
| A: Email + OTP gate | Lowest declaration volume. High friction kills completion rates → smallest 10x base per location. | Location tracking unaffected — postcode/campaign tagging happens at payment, not on the form. | YES — breaks the narrative. GASDS dashboards show treasurers how much they can't claim. The pitch becomes "look at all this money you're missing" instead of "look at all this money you're earning." That's the opposite of what we're selling. |
| B: Form first, email separate | Good declaration volume. Gift Aid data captured before email ask → healthy 10x base per venue. | Location tracking unaffected. | Narrative holds. But without email, returning donor recognition is weaker → each visit is a fresh form. Repeat donors at the same venue (the exact pattern that builds location-level Gift Aid base fastest) face unnecessary friction on every return. |
| C: Accept all, verify later | Highest declaration volume. Lowest friction → biggest 10x base per location. Returning verified donors get prefill → base compounds over time. | Location tracking unaffected. Postcode captured on form also validates the Gift Aid declaration — dual purpose. | Strengthens the narrative. More declarations per venue → bigger 10x allowance per venue → more GASDS claimable per venue → dashboard shows green, not red → treasurer pitch lands. The passive email verification builds the returning-donor loop that accelerates the base over time. |
An important clarification that changes how we think about friction on the magic link page:
This reframes the entire email/OTP debate. We don't need to gate anything before the Gift Aid form. We can accept everything first and verify afterwards.
Today's meeting debated where email sits in the magic link flow. This directly determines Gift Aid capture rates and whether the GASDS pitch works.
Risk: Two friction points before the donor even sees the Gift Aid form. Donor is standing in a car park after church — waiting for an OTP email, checking spam, typing a code. Many will abandon.
Estimated completion rate: ~30-40%
When this makes sense: If we absolutely must protect stored data before showing anything. But we don't — we can show a blank form.
Advantage: Zero friction before Gift Aid form. Email positioned as a benefit, not a gate.
Downside: Email is a separate step that many donors will skip. Lower account creation rate. OTP is still a friction point for those who do engage.
Estimated Gift Aid completion rate: ~50-65%
Estimated email capture rate: ~20-30% (separate optional step)
Collect all details including email on one form. No OTP at point of capture. Verify passively afterwards via a "thank you" email.
| Gift Aid capture | Same as Option B — zero friction before the form. But email is collected on the same form (not a separate step), so we get higher email capture too. |
| Email capture | Email is just another field on the form, not a separate screen. Donors are already filling in name and address — adding email feels natural, not like an extra ask. |
| No OTP at point of capture | Zero waiting. Zero context switch. Zero checking spam. The donor fills in the form and hits submit. Done in 30 seconds. |
| Verification happens passively | The "thank you" email arrives in the donor's inbox. They click the link when they're home, sitting down, on wifi. No time pressure. No standing in a car park. |
| Data exposure solved | Stored data (prefill) is ONLY shown to donors whose email was previously verified via the confirmation link. Unverified emails always see a blank form. |
| Market-aligned | This is exactly how Dona works — collect everything on one form, no verification at point of capture. The industry norm. |
| Scenario | What Happens | Data Shown |
|---|---|---|
| New donor (no matching email) | Blank form. Fill in everything. Submit. | Nothing prefilled. Zero risk. |
| Returning donor, email NOT verified | Blank form. Fill in everything again. Submit. | Nothing prefilled — treated as new. System flags potential duplicate for admin review. |
| Returning donor, email previously verified | Email recognised → "We have your details. Check your email for a code to continue." OTP sent. Verified → prefill shown. |
Prefill only AFTER OTP. Data protected. |
OTP only ever fires in the third scenario — a returning donor with a previously verified email. This is the minority of cases. Most donors most of the time see zero friction.
Estimated Gift Aid completion rate: ~55-65%
Estimated email capture rate: ~50-60% (same form, not separate step)
Estimated email verification rate: ~30-40% of those who gave email (passive, in own time)
A charity processing 200 donations/month where 40% scan the QR (80 magic link opens):
| Metric | Option A Email + OTP first | Option B Form first, email separate | Option C Accept all, verify later |
|---|---|---|---|
| Gift Aid declarations / month | 80 × ~35% = 28 | 80 × ~57% = 46 | 80 × ~60% = 48 |
| Emails captured / month | 28 (all have email — it was the gate) | 46 × ~25% = 12 (separate step) | 48 × ~55% = 26 (same form) |
| Verified accounts / month | 28 (OTP was already done) | 12 × ~80% = 10 (OTP after) | 26 × ~35% = 9 (passive link click) |
| Gift Aid value / year (at £25 avg) | ~£2,100 | ~£3,450 | ~£3,600 |
| SwiftCause commission / year (3%) | ~£63 | ~£104 | ~£108 |
All percentages are estimates. "~" denotes approximate figures. The one external benchmark: Dona reports >40% Gift Aid rate on their on-device (not magic link) capture.
The estimates above must be validated with real data from the first pilot charities. Instrument these five metrics from Day 1:
| # | Metric | What It Tells Us | Target (from KPIs) | How to Measure |
|---|---|---|---|---|
| M1 | QR scan rate | What % of donors who see the thank-you screen actually scan the QR | No target set yet — baseline needed | Magic link opens ÷ total donations at that collection point |
| M2 | Gift Aid form start rate | What % of magic link opens result in the donor starting to fill in the form | ≥80% (low bar — if they opened the link they're interested) | First field interaction event ÷ magic link page loads |
| M3 | Gift Aid form completion rate | What % of donors who start the form actually submit it | ≥50% (existing pilot KPI: Gift Aid completion 50%) | Successful form submissions ÷ first field interactions |
| M4 | Form drop-off rate | Where in the form do donors abandon? Which field is the killer? | ≤20% (existing pilot KPI: form drop-off ≤20%) | Track last field interacted with before page close, per field |
| M5 | Email capture rate | What % of completed Gift Aid forms include an email address | No target set — baseline needed | Submissions with non-empty email ÷ total submissions |
| M6 | Email verification rate | What % of captured emails are verified via the thank-you email link | No target set — baseline needed | Verification link clicks ÷ thank-you emails sent |
| M7 | Over-£30 Gift Aid recovery | What % of donations >£30 end up with a Gift Aid declaration (via any path) | Higher is better — each missed £50 donation = £12.50 lost | Gift Aid declarations on >£30 donations ÷ total >£30 donations |
Every competitor that recognises returning donors does it via the physical card token, not email. SwiftCause's magic link breaks this pattern because the payment device and the donor's phone are separate. But Stripe does return a card fingerprint on every payment.
| Visit | What Happens | Identity Method | Gift Aid |
|---|---|---|---|
| Tap 1 | Anonymous donation. Stripe records card fingerprint. | None — donor is anonymous | QR shown. If scanned: Gift Aid form (Option B). If not: GASDS pool. |
| Tap 1 + Magic Link | Donor completes Gift Aid form on phone. Card fingerprint from Stripe is linked to declaration. | Form data + card fingerprint linked | Full Gift Aid captured. Declaration stored with futureConsent: true. |
| Tap 2 (same card) | Same card fingerprint recognised. Existing declaration with future consent found. | Card fingerprint match | Gift Aid auto-applied. No QR needed. No form. No email. |
| Tap N (different card) | New card fingerprint, no match. Falls back to QR/magic link flow. | Magic link → form (or email + OTP if returning verified donor) | Gift Aid via form. New card fingerprint linked to existing declaration. |
The GASDS dashboard alone is copiable. The full chain is not. Here's how to pitch it:
The pitch works because each point depends on the one before it. The magic link feeds the Gift Aid base, the Gift Aid base feeds the GASDS multiplier, and the community building tracking maximises the cap. A competitor would need to build all three layers to match the claim — and none of them are even working on the first one.
| # | Decision | Options | Recommendation | Owner |
|---|---|---|---|---|
| 1 | Magic link flow order | Email+OTP first (A) / Form first, email separate (B) / Accept all, verify later (C) | Option C: Single form with email, passive verification via thank-you email. Highest Gift Aid capture + good email capture. | Qamar |
| 2 | When does OTP trigger? | Always / Only when verified email matches / Never | Only on verified match: New donors & unverified donors see blank form (zero friction). OTP only fires when email matches a previously-verified account. | Qamar |
| 3 | Card fingerprint matching | Go-live scope / Phase 2 fast-follow / Not planned | Phase 2 fast-follow: High value, not on critical path | Qamar + Dev |
| 4 | Apple/Google Pay data spike | This week / Next sprint / Defer | This week: 1-2 day spike. Result changes the entire flow design. | Dev team |
| 5 | GASDS dashboard — when to build | Pre-launch / Post-launch Phase 2 / Post-launch Phase 3 | Post-launch Phase 2: Needs Gift Aid data flowing first to be meaningful. Ship after first charities are live and generating data. | Qamar |
| 6 | Community building location tagging | Pre-launch / Post-launch | Post-launch Phase 2: Ship with GASDS dashboard as a bundle. Tag-and-track as a feature. | Qamar + Dev |
What the system does today, with all the gaps and risks surfaced in this week's standup.
homeAddressConfirmed checkbox, no declarationType selector, tax year bug (GA-01) assigns wrong year for Jan–5 Apr donations.
| Area | Current State | Risk |
|---|---|---|
| Consent Ledger | Architecture approved, magic link shipped (PR #622), but core tasks #609–#612 unassigned | No audit provenance for HMRC |
| HMRC CSV Export | Shipped & hardened (PR #626, formula injection fix) | Low — functional |
| Admin Anomaly Queue | Does not exist | No way to flag/resolve duplicate emails or wrong attributions |
| Super-Admin Corrections | Does not exist | No audit-trailed path to fix misattributed records |
| Tax Year Calculation | getFullYear() used instead of UK tax year boundary | Wrong tax year on Jan–5 Apr donations |
| Apple/Google Pay Data | Not investigated | Potential shortcut to identity sitting uninvestigated |
| GASDS Pool Tracking | Donations flagged but no dashboard or 10x cap alerting | Charities can't see what they can claim |
| Location Tagging | Not built | Community building doubled cap (£16k) can't be tracked |
The secure, compliant, friction-optimised flows we're building towards.
| Area | As-Is | To-Be | Priority |
|---|---|---|---|
| Email Verification | None — anyone can enter any email | OTP (6-digit) before data shown/editable | P0 — Go-Live |
| Consent Capture | No opt-in checkbox | Explicit opt-in + retention policy + consent event in ledger | P0 — Go-Live |
| Consent Ledger | Architecture approved, tasks unassigned | ConsentEvents subcollection with Cloud Function trigger, IP capture, provenance ref | P0 — Go-Live |
| Tax Year | getFullYear() — wrong for Jan–5 Apr |
UK tax year boundary (6 Apr) in all date logic | P0 — Go-Live |
| Apple/Google Pay Data | Not investigated | Spike complete; billing_details captured and used for pre-fill + proactive email follow-up | P1 — Spike this week |
| Admin Anomaly Queue | Does not exist | Dashboard queue: flagged duplicates, side-by-side comparison, resolve/escalate workflow | P1 — Pre-launch |
| Super-Admin Corrections | Does not exist | Re-link, merge, void with full audit trail (timestamp, admin ID, reason, before/after) | P1 — Pre-launch |
| Postcode Lookup (PAF) | Manual entry only | Royal Mail PAF: type postcode → select address from dropdown | P2 — Fast-follow |
| GASDS Pool Dashboard | Donations flagged, no visibility | Per-location GASDS pool tracked by postcode/campaign, with per-venue 10x cap alerting, community building status (£8k/£16k), and one-click HMRC export | P2 — Post-launch |
| Location Tagging | Not built | Community building flag per location; doubled cap auto-tracked; per-location flow config | P2 — Post-launch |
| Declaration PDF Archive | Not implemented | Timestamped immutable PDF per declaration; amendments via super-admin only | P1 — Pre-launch |