Surfaces the Decoupling Touches — Mockups

Companion to the proposal Decouple Accounts from Verification. Five surfaces, each shown as it works today and as it works under the proposed model. Field lists mirror the proposal's record-detail tables (v2.0, 2026-08-07).
Illustrative wireframes, not visual design. Layouts approximate the live product; the point is which fields live where, what locks, and what feeds what.

1 · Signup — account type fork (new)

Today signup collects one shape for everyone, including an Organization Name field that maps to nothing visible in the product UI (backend consumer to be confirmed in the spec). Proposed: choose Individual or Organization / Group at signup. The choice sets the name shape only — it never adds verification overhead, and it gives the no-DBA business case a sane public name from day one.

Today
GiveSendGo Sign up
Sarah
Mitchell
sarah@example.com
+1 (555) 010-2288
A
—
Collected, stored, displayed in settings — maps to nothing visible in the product UI (backend consumer to be confirmed in the spec).
US · VA · Virginia Beach · 23450
Create account
Proposed
GiveSendGo Sign up
1
Individual
First + last name
Organization / Group
Org or group name, with a manager's name on file
Sarah
Mitchell
sarah@example.com
+1 (555) 010-2288
Account security and sign-in codes only. Never used for payment verification.
2
The name you choose is displayed publicly as the creator and funds-recipient name on fundraisers tied to this account. You can change it anytime in settings.
Create account
ADead field retired. Organization Name is dropped; existing values can seed migration for org-type accounts. The account-level location block (Country/State/City/ZIP) is gone too — location belongs to the fundraiser (see surface 4).
1Account type fork. Sets name shape only. Org accounts enter the org/group name as the account name plus a never-public owner/manager first + last.
2Plain-language disclosure that the chosen name is the public creator / received-by name — required by the proposal so nobody is surprised later.

2 · Account settings — the display name becomes self-serve

Today the account's first/last is simultaneously sign-in identity, the public name on every fundraiser, and the seed for payment verification — so users cannot edit their own name at all; every typo, privacy request, and legal name change is a support ticket, and pre-verification not even support can change it safely. Proposed: the display name is the user's to change, every change is logged, and nothing in settings can touch verification.

Today
Account Settings Profile
A
Sarah 🔒 not editable
Public name + verification seed in one field. Changing it = support ticket; pre-verification, even support can't touch it safely.
Mitchell 🔒 not editable
sarah@example.com
B
+66 81 234 5678
Security phone — but auto-fills into recipient banking forms (TS-482: a Thailand number silently failed US validation).
—
Maps to nothing visible in the product UI (backend consumer to be confirmed in the spec).
Thailand · — · Bangkok · 10110
C
x.com/sarahm
"For quicker verification times enter a social media profile link" — an account field recruited for verification duty.
Proposed
Account Settings Profile
1
Sarah Mitchell ✎ Edit
Shown publicly on your fundraisers. Change it anytime — changes are logged.
sarah@example.com
Sign-in, receipts, and the one link to any verification record.
2
+66 81 234 5678
Account security and sign-in codes only. Never copied into banking or verification forms.
retired
Retired — replaced by the account-type name shape.
retired
Retired — location lives on the fundraiser (withdrawal country + postal).
3
moved
Relocated to the verification flow, where its own copy says it belongs.
AThe core defect today: one field is public identity and legal-verification seed, so it has to be locked against its own user.
BPhone triple duty is what shipped the TS-482 failure: an account security value auto-filled into a US-validated banking context.
1Self-serve display name with a full rename audit trail (visible in admin — surface 5). Editing it never triggers re-verification and never takes a fundraiser offline.
2Phone demoted to security-only. No auto-population into recipient/banking forms, in either direction.
3Verification-flavored fields leave the account. Social link moves to the verification context; dead fields retire.

3 · Recipient verification — a fresh, standalone record

The flow's step order is already right today: choose who receives (Become a Recipient vs Invite a Recipient), then bank account type (Personal vs Business), then the Recipient Information form. The defects are inside the form and between the steps: the "Legal" name fields are pre-seeded from account data, the phone auto-fills the account security number (TS-482; the same phone component separately blocked T&T recipients on validation, TS-485, resolved Jul 27), the email field's still-live defects are TS-436's self-rejecting autofill and the DEV-1667 helper-text band-aid — the visual lock itself was DOM-bypassable and failed silently, a confusing-UX and defense-in-depth gap, though the server always persisted the canonical account email (fixed June 2026, DEV-1602), the most sensitive PII is stored in GSG's database, and once you're on the business form you can't go back to bank-account-type selection. Proposed keeps the step order and fixes the record boundary.

Today — step order (correct) with the traps marked
1 · Who receives the funds?
Become a RecipientInvite a Recipient
creator receives · someone else receives
→
2 · Bank account type
Personal accountBusiness account
⇥
E3 · Recipient Informationdetails + banking, below
no way back to step 2; abandoned form sticks on Transfers revisit
Proposed — same steps, unlocked state
1 · Who receives the funds?
Become a RecipientInvite a Recipient
⇄
2 · Bank account type
Personal accountBusiness account
⇄
3 · Recipient Verificationfresh standalone record, below
both selections re-selectable until submit; abandoned form re-presents the options

Personal account variant

Today
My Fundraisers › Fundraiser › Recipient
Recipient Information
Personal Information
A
ben
"Must match your government-issued ID" — yet seeded from the account name. A rename before bank connect breaks the legal-name match — the revert/re-revert trap behind the standing "finish connecting your bank first" instruction.
frank
Must match your government-issued ID
C
benfrankster@gmail.com
Account email, locked — the right policy. The visual lock was historically DOM-bypassable and failed silently (fixed June 2026, DEV-1602; the server always kept the canonical email); TS-436 auto-filled this locked field and the same form's validator rejected it.
Month ▾ · Day ▾ · Year ▾
D
Enter your Social Security Number
Stored in GSG's database, with DOB and street address.
B
🇺🇸 +1 (720) 755-1845
Auto-filled account security phone (DEV-1661). Account country ≠ fundraiser country → silent validation failure (TS-482); T&T variant blocked every recipient (TS-485).
https://facebook.com/yourprofile
Optional - Link to your social media profile
G
✓Sign up for SMS updates
Fails silently in production today (observed Aug 7) — the opt-in doesn't take effect and no error surfaces. Unticketed.
Address Information
Enter your street address
Enter your city
Enter your state/province
Enter postal code
United States
Banking Information
Enter your Routing number
Enter 9 digits only (no spaces or dashes)
Enter your Account number
Confirm Account number
Complete Setup
Proposed
My Fundraisers › Fundraiser › Recipient
Recipient Verification
Personal Information
1
Enter your legal first name
Entered fresh — exactly what your ID and bank show. Never copied from your profile; renaming your account never touches this.
Enter your legal last name
Must match your government-issued ID
3
sarah@example.com 🔒 matches your account
The one shared field — displayed from your account, locked to match, enforced server-side.
5
Month ▾ · Day ▾ · Year ▾
Pass-through to the payment processor — never stored by GSG.
Enter your Social Security Number
Pass-through to the payment processor — never stored by GSG.
2
🇺🇸 +1 (___) ___-____
Entered fresh, only when the processor requires it for the fundraiser's country — validated in that country's format from live country metadata.
https://facebook.com/yourprofile
Optional verification-support signal — lives here, removed from account settings.
Address Information
Enter your street address
Pass-through to the payment processor — never stored by GSG.
Enter your city
United States 🔒 fundraiser's country
Banking Information
Enter your Routing number
Locked once verified. Re-enterable after a failed transfer.
Enter your Account number
Complete Setup

Business account variant

Today
My Fundraisers › Fundraiser › Recipient
Recipient Information
bens biz
A
ben
Seeded from the account name.
frank
C
benfrankster@gmail.com
ⓘ This is your account email. As the recipient, donations are tied to this email. To change the email or recipient, go back and select Invite a Recipient. ← the helper-text band-aid (DEV-1667) shipped instead of a data fix (the lock's DOM-bypass / silent-failure gap was closed June 2026, DEV-1602).
Enter 9-digit EIN
Must exactly match your IRS documents, including capitalization and punctuation.
F
Enter DBA name
(optional) — but leave it blank and the public page shows the representative's private personal name instead of the business (TS-480).
🇺🇸 +1 (___) ___-____
G
✓Sign up for SMS updates
Silent fail (see legend G).
Month ▾ · Day ▾ · Year ▾
D
Enter your Social Security Number
Stored in GSG's database.
Address + Banking Information
Street · City · State · Postal · Country — then Routing · Account · Confirm
And no way back to bank-account-type selection from here (unticketed form-state bug).
Complete Setup
Proposed
My Fundraisers › Fundraiser › Recipient
Recipient Verification · Business account ‹ change
1
Enter your legal business name
Entered fresh — exactly as registered. Shown publicly on the fundraiser only when no DBA exists.
Enter first name
Entered fresh; never shown publicly.
Enter last name
3
sarah@example.com 🔒 matches your account
Locked to your account email, enforced server-side. Someone else receiving? Go back and choose Invite a Recipient.
5
Enter 9-digit EIN
Pass-through to the payment processor — never stored by GSG.
6
Enter DBA name
Optional. If present, it's the public received-by name; if blank, the legal business name shows — never the representative's personal name.
2
🇺🇸 +1 (___) ___-____
Only when the processor requires it; validated for the fundraiser's country.
Month ▾ · Day ▾ · Year ▾
Pass-through — never stored by GSG.
Enter your Social Security Number
Pass-through — never stored by GSG.
Address + Banking Information
4
Street (pass-through) · City + Country (stored) — then Routing · Account · Confirm
Bank account type re-selectable until submit ("‹ change" above); banking re-enterable after a failed transfer.
Complete Setup
ASeeding is the defect. The form already asks for the legal name but pre-fills it with the account name — the exact coupling that welds public identity to verification identity.
BPhone autofill (DEV-1661) copies a security credential into a banking-validated context — TS-482. The same phone component carries a separate six-country blocking history (DEV-1223, TS-402, TS-412, TS-433, TS-482, TS-485).
CEmail lock is right policy — the defects were around it: a DOM-bypassable visual lock that failed silently (fixed June 2026, DEV-1602; the server always persisted the canonical email), TS-436's self-rejecting autofill, and the DEV-1667 helper-text band-aid instead of a data fix.
DSSN, DOB, and street address are stored in GSG's database today.
EForm-state traps: business form can't return to bank-account-type selection; an abandoned unsubmitted form sticks on the Transfers revisit.
FThe blank-DBA leak: no DBA → the representative's private personal name displays publicly (TS-480).
GThe SMS opt-in fails silently in production today (observed Aug 7) — the subscription doesn't take effect and no error surfaces. Another consumer of the coupled phone field; needs its own ticket.
1Fresh entry, purpose-built. Legal names entered exactly as ID/registration shows; account renames can never break the match.
2Phone in country context — collected only where the processor requires it, validated against the fundraiser's country from live metadata. Ends the HK/Morocco/Benin/Thailand/T&T whack-a-mole.
3Email is the single anchor between account and verification record — the April lock decision kept, enforced server-side.
4Form state unlocked: both prior selections re-selectable until submit; abandoned forms re-present the options.
5Data minimization: SSN/EIN, DOB, and street address pass through to the processor and are never stored in GSG's database.
6Received-by precedence made explicit at entry: DBA if present, legal business name otherwise — never free text, never the representative's name.

4 · Fundraiser page — names derive; nothing is stored twice

Public names stop being stored copies and become derived fields: the byline from the creator's display name, the received-by line by precedence — recipient display name → DBA → legal business name — so renames propagate automatically and the broken no-DBA fallback (TS-480: a law firm's page showing the representative's private personal name) becomes a first-class path.

Individual recipient
Help for the Mitchells
1Created by Sarah Mitchell · Virginia Beach, US from display name
2Funds go to Sarah Mitchell recipient display name
Business · DBA present
Rebuild the Bakery
Created by Tom Nguyen
3Funds go to Sunrise Bakery ✓ verified business
Business · no DBA
Legal Defense Fund
Created by Anna Reyes
4Funds go to Reyes & Associates LLC ✓ verified business
5Location moves here too: withdrawal country = the recipient's country (locked at creation, drives banking + verification), plus a postal code for "nearby" discovery — label and validation driven per-country from maintained address metadata, never a hand-rolled list. An optional "Representing / Fundraising on behalf of" label can sit alongside the names, never replacing them.
1Byline derives from the creator's display name — renames update it automatically, no stored copy to drift.
2Received-by default: the recipient's display name.
3Verified business wins: once the business bank account verifies, the verified name takes over — DBA when present…
4…legal business name when no DBA exists — never the representative's personal name (the TS-480 leak), never free text. Displaying the verified name publicly stays: it's a trust feature competitors don't offer.
5Fundraiser owns location. The account-level location block retires (surface 2).

5 · Admin — same pages, decoupled behavior

No admin redesign is being proposed — layout stays exactly as it is; the engineering spec session owns any UX changes. What changes is what the fields are: names become derived values with a visible source instead of stored copies, the backend pencil-edit becomes an audited rename on the user account, the beneficiary email stops being an editable copy, "Recipient Type: Self" splits into the two real fields (GPD-135), and the PII the processor owns stops being stored. The naming rule the fields follow: created-by = the account display name, always; received-by = the recipient's display name until a business bank account verifies (then DBA, else legal business name); legal identity lives only in the locked verification record.

SysVerify › fundraiser admin (admin/update)

Today
Sys Verify Ben
Stripe Account Details
Account DetailsDisable CampaignEdit Bank AccountVersion HistoryStatus HistoryActivity LogView Donations
Mark this account as pending · rejected · completed
L1 Verification   Email payout notification   Flag Account
Campaign Urlhelp-me-rebuild-my-life-after-devastatin
Campaign Id765780
Campaign NameHelp Me Rebuild My Life After Devastating Surgical
ACampaign Owner namePetra Zuzul 👤
Campaign Owner emailpetra.zuzul911@gmail.com
BBeneficiary emailpetra.zuzul911@gmail.com
A stored copy of the account email — the drift class: recipient email drifted between the processor and admin with no audit trail (TS-434); TS-476 is the sibling orphaned-record failure (a recipient record with no user account behind it, plus duplicate user rows).
Beneficiary Phone+385976297624
CBeneficiary name ✏️Petra Zuzul 👤
The backend display-name edit — a direct write, no audit trail. This pencil is the five-step support procedure's last step.
Stripe Accountacct_1U1gZq6aCaDtUf2x
DRecipient TypeSelf
One value conflating recipient type and bank account type (GPD-135).
Amount Raised · Paid Out · BalanceEUR 0.00 · EUR 0.00 · EUR 0.00
E · One flat page mixes fundraiser, account, verification, and processor data — nothing tells an admin which value is public, which is legal identity, and which is a copy that can drift.
Proposed — sectioned by record, new vocabulary
Sys Verify Ben
Stripe Account Details
Account DetailsDisable CampaignEdit Bank AccountVersion HistoryStatus HistoryActivity LogView Donations
Mark this account as pending · rejected · completed
L1 Verification   Email payout notification   Flag Account
Checkboxes, IPs, failed-donation %, and all buttons: untouched.
1
Fundraiser
Fundraiser Urlhelp-for-the-mitchells
Fundraiser Id812744
Fundraiser NameHelp for the Mitchells
Date Created · Published7 Aug 2026, 04:54 · 7 Aug 2026
Emergency Spotlight TagSelect an option ▾
Amount Raised · Paid Out · Balance OwedEUR 0.00 · EUR 0.00 · EUR 0.00
2
User profiles — GSG accounts
Fundraiser CreatorSarah Mitchell · sarah@example.com live from account
Displayed from the user record, not a stored copy — created-by already reads live this way (TS-399, fixed May 2026); this proposal generalizes that derived-name pattern to the remaining stored copies.
Recipient usersame account Recipient Type: Myself
Shows the invited user's account when someone else receives.
3
Recipient verification (recipient record · per fundraiser)
Verified Recipient NameSarah J. Mitchell ✓ verified · locked
Recipient Emailsarah@example.com 🔒 matches account
Recipient Phone+1 (804) 555-0134 processor-required
Recipient Type · Bank Account TypeMyself · Personal
Stripe Account · Approved Dateacct_1U1gZq6aCaDtUf2x · —
Account Completed By · Date— · —
Legal Business Name · DBA · Legal Representative— (personal account)
Business accounts: DBA shows publicly if present, else LBN — never the representative's name.
4Change log — this recipient recordno changes · view
Every name and email change: old / new / timestamp / actor. Replaces untracked edits.
5Fields here are read-only — changes go through re-verification and propagate to the processor automatically. Retires the "edit in Admin, then re-key into Stripe by hand" procedure.
Recipient Relationship Disclosures, notes, payout requests, transferred-amount list, campaign percentage — unchanged.

Admin › Users (list_user)

Today (layout approximated)
Users Ben
IdUser TypeFirst NameLast NameEmailCountry
1491099User / Campaign OwnerOlawaleOyeleyeOlawaleoyeleye72@gmail.comNigeriaUpdate
F · First/Last here is simultaneously the public name on every fundraiser and the verification seed; Country is the dead account-level field.
Proposed — same table, two deltas
Users Ben
IdUser TypeDisplay NameEmail
1491099User / Campaign OwnerOlawale OyeleyeOlawaleoyeleye72@gmail.comUpdate
First/Last becomes the display name — public identity only, no verification duty. Country column drops with the retired account location block. Nothing else changes.

Admin › Update User (update-user)

Today
system_admin_menu / update-user?id=1491099 Ben
Update User
Fields with * are required.
User / Campaign Owner
G
Olawale
Editing this silently renames every public page AND the seed of any future verification — direct DB write, no audit trail (the TS-464 admin workaround lives here).
Oyeleye
H
Olawaleoyeleye72@gmail.com
An unaudited email edit here is how the admin and processor records drift apart with no audit trail (TS-434) — nothing re-checks the lock.
Nigeria
The dead account-level field.
SubmitCancel
Proposed — same form, new edit behavior
system_admin_menu / update-user?id=1491099 Ben
Update User
Fields with * are required.
User / Campaign Owner
6
Olawale
Now the display name only. Every edit lands in the rename audit log (old / new / timestamp / actor "admin") and feeds manual verification review. Verification records are untouched.
Oyeleye
7
Olawaleoyeleye72@gmail.com
Saving a change runs the email-change flow: re-verification plus a lock-match re-check against any active verification record — never a bare DB write.
retired
Retired with the account location block — location lives on the fundraiser.
2026-07-30 · name · Olawale O. → Olawale Oyeleye · by user view all
Name and email changes both logged: old / new / timestamp / actor.
SubmitCancel
APre-TOS vocabulary: "Campaign Owner" and "Beneficiary" — the July TOS terms are creator and recipient. Left as-is in the proposed pane (relabeling is cosmetic, not part of this proposal).
BStored copies drift: beneficiary email duplicates the account email with no lock re-check — the TS-434/TS-476 class.
CThe pencil edit on Beneficiary name is a direct backend write with no audit trail — today's only rename path, mediated by support.
D"Recipient Type: Self" conflates two questions (GPD-135).
EFlat field soup: public, legal, and copied values are indistinguishable on one page.
FUser list carries the coupling: First/Last is public name + verification seed at once; Country is dead weight.
GUnaudited admin renames: the update-user form writes identity straight to the DB.
HUnaudited admin email edits bypass any account/verification match.
1Fundraiser section: URL, ID, name, dates, spotlight tag, and money facts grouped as fundraiser data — vocabulary updated to fundraiser / creator / recipient (no "campaign," no "beneficiary").
2User profiles section: creator and recipient GSG accounts displayed live from the user records — no stored copies. Extends the TS-399 pattern (created-by already reads live from the user record since May 2026) to the remaining recipient-side copies. Shows two users when someone else receives.
3Recipient verification section = the recipient record surfaced honestly: verified name, lock-matched email, phone, Recipient Type · Bank Account Type as the two fields the code already keeps separate (behavior dictionary, CONFIRMED), Stripe account + approved date, completed by/date, LBN · DBA · legal representative for business.
4Per-record change log — every name and email change with old / new / timestamp / actor. TS-434's untracked email drift becomes visible history.
5Verification fields are read-only in admin — changes go through re-verification and propagate to the processor automatically, retiring the documented "edit in Admin, then update Stripe by hand" procedure (AK editing guide).
6Admin renames are audited — same log as user renames, actor recorded, history feeds VCR review.
7Email edits go through the flow, not around it — re-verification plus lock-match re-check, and both name and email changes land in the update-user change log.
Scenario
Become a Recipient · Personal bankSarah Mitchell raises for herself
Become a Recipient · Business bankTom Nguyen receives via Sunrise Bakery (DBA)
Invite a Recipient · Personal bankMarcus Hale invites Elena Vasquez
Invite a Recipient · Business bankDana Whitfield invites Reyes & Associates (no DBA)
Switches sections 3–5 (step chips, form variant, fundraiser card, admin values). "Today" panes are real captures and stay fixed. All names are fictitious.
Scenario Become · Personal ▴