OFFLINE-PAYMENTS-001 — Define the audited in-person payment and pickup ledger

[daliu]

Officer impact: Officers need one online, read-only operational view for Shop obligations and club-hosted run registrations, plus narrowly scoped actions to record, verify, correct, and resolve in-person payment and pickup outcomes. This issue defines that trusted workflow before any editor or ledger becomes usable.

Officer documentation: Update OFFICER_START_HERE.md only if routing changes; update docs/officers/EVENTS_SHOP_MEMBERS.md, docs/officers/SYSTEM_MAPS.md, the data inventory/retention guide, and finance/recovery procedures when implementation begins.

Deployment evidence: This issue is design only. Source, tests, merge, website publication, runmprc.com, Firebase, provider configuration, production data, and production behavior remain unchanged and unverified.

Owner-approved input recorded 2026-07-29

• MPRC Hat is USD 10.00 and MPRC Jacket is USD 25.00.
• In-person payment methods are cash and Venmo.
• Merchandise is picked up in person from the Treasurer at a club run.
• Officers need to check who is settled for Shop items and for MPRC-hosted runs.
• Officers currently share access to the club mailbox, but the owner accepts either a website-server or Google Sheets operational surface.

Atomic outcome

Approve one server-authoritative, append-oriented data and command contract for in-person obligations, payment evidence, corrections, and pickup/registration resolution. Define the minimum read model officers may use. Do not build the UI, mutate production data, or configure a provider in this issue.

Security and money invariants

• Shared mailbox possession, a matching email string, a profile field, or a visible browser control grants nothing.
• Every mutation is attributed to one individually authenticated officer account with one explicit scoped capability.
• The browser never writes paid, price, method, balance, pickup, fulfillment, refund, or reconciliation truth directly.
• Cash and Venmo evidence never fabricate a Stripe object or Stripe identifier.
• Amounts use integer cents and explicit USD currency with an immutable item/event price snapshot.
• Payment state and fulfillment/attendance state remain separate.
• A correction appends a compensating command and audit record; it never overwrites or deletes history.
• Every command has a stable idempotency key and exact retry behavior.
• The operational table is a bounded projection, not editable ledger cells.
• Access, exports, commands, failures, and corrections are audited with no raw notes, payment handles, contact details, promo codes, or provider secrets.
• Shop and event obligations share infrastructure only where their owner-approved lifecycle is genuinely identical.

Owner decisions still required

• Name the finance approver, backup, event approver, shop approver, privacy owner, and platform/security owner.
• Approve the exact scoped capabilities for viewing, attesting, verifying, correcting, refunding/reversing, and resolving pickup or registration.
• Approve what evidence is sufficient for cash and for Venmo without publishing a handle, transaction detail, or screenshot.
• Approve cash counting/reconciliation, Venmo account ownership/reconciliation, correction, dispute, refund, receipt, notification, and incident procedures.
• Approve the minimum person/item/event fields, search fields, export columns, retention period, deletion restrictions, and officer access review interval under DATA-001B — Inventory personal data and approve a minimization/retention matrix #110.
• Decide whether Google Sheets is only an exported read view or is excluded. A shared editable Sheet cannot be canonical payment authority.
• Define which MPRC-hosted runs need an obligation record and how free, comp, waived, Stripe-paid, cash, and Venmo states differ.

Dependencies

• DATA-001B — Inventory personal data and approve a minimization/retention matrix #110 personal-data minimization and retention approval.
• BACKEND-001 — Audit the Firebase cutover and approve legacy data disposition #113 Firebase and legacy-data inventory/disposition.
• MEMBERS-ADMIN-001 — Add audited officer membership association and manual activation #115 audited individual officer association and capability provisioning.
• The relevant Shop, event, commerce-state, idempotency, audit, and protected-release dependencies in the root implementation plan.

Acceptance criteria for this design issue

• State separate obligation, payment, reconciliation, and fulfillment/attendance lifecycles with allowed and impossible transitions.
• Define exact bounded server command envelopes and idempotent retry results.
• Define append-only audit/evidence records and a minimal officer read projection.
• Define capability checks at the Function, Rules/read-model, and website-display boundaries.
• Define correction and unknown-outcome behavior without an editable Paid field.
• Define compatibility/migration and a dry-run, no-production-data test plan.
• Include negative tests for anonymous, unverified, member, event manager, shop manager, fulfillment, finance, and platform roles.
• Prove the club mailbox string grants no capability.
• Document purpose, approver, prerequisites, steps, expected result, stop conditions, proof, undo, and escalation for backup officers.

Explicitly out of scope

Production records; real member, buyer, payment, or registration data; Google Sheets creation; Firebase/Stripe/Venmo configuration; role grants; browser editor; CSV export; cash counting; provider calls; checkout; refund execution; receipt delivery; deployment; live verification.