Add voter_limit column & stripeCheckoutSessionsDB table (migration + shared pricing config)

[ArendPeter]

Question / Task

Part of the Phase 1 Payment System: Design & Build Map, graduated from Design backend data model & Stripe integration flow for Phase 1 payments (see that ticket's resolution comment for full design rationale).

Add the foundational schema and shared pricing constants everything else in this map builds on.

Migration (follow packages/backend/src/Migrations/2026_03_19_email_events.ts's style):

• Add voter_limit (integer, not null) to electionDB. Backfill existing rows: voter_limit = GREATEST(100, current roll count for that election) — so no election that already has more than 100 voters on its roll today becomes retroactively unable to keep its current voters (it just can't add more without paying, same as any other election over the free limit). New elections get voter_limit = FREE_TIER_LIMIT (100) at creation.
• Add voter_limit to the Election interface (packages/shared/src/domain_model/Election.ts) and to electionValidation().
• Create stripeCheckoutSessionsDB: id (serial PK), election_id (varchar, not null), user_id (varchar, not null), product (varchar, not null — 'voter_limit' for now), amount_cents (integer, not null), voter_count_granted (integer, nullable), stripe_checkout_session_id (varchar, not null, unique — the webhook idempotency key), stripe_customer_id (varchar), status (varchar, not null, 'pending' | 'paid'), created_date (timestamptz, not null). Index on election_id.
• Model class StripeCheckoutSessionsDB in packages/backend/src/Models/, following EmailEvents.ts's thin-wrapper style: insert(), getByStripeSessionId(), markPaid(), sumVoterLimitPurchases(election_id) (sums voter_count_granted where product='voter_limit' AND status='paid' — useful for audit/support, not for computing voter_limit itself, which is authoritative on the election row).

Shared pricing config (packages/shared, alongside SharedConfig.ts or a new small config module): FREE_TIER_LIMIT = 100, BLOCK_SIZE = 200, PRICE_PER_BLOCK_CENTS = 1000.

No Stripe dashboard Product/Price objects need to be created — pricing uses dynamic price_data per Checkout Session (confirmed in the closed research ticket).

[ArendPeter]

For now this still has to also respect the overrides in the shared package. So each election has a voter_limit in the DB, but whenever callers are trying to access that limit, they should still default to the override

[github-actions]

👋 Hi @ArendPeter! Thank you for taking on this issue!

To help us track progress and support you effectively, please provide the following information:

Availability for this week:

My estimated ETA for completing this issue:

Feel free to ask questions in the #bettervoting Slack channel if you need any help!

[ArendPeter]

Resolution

Implemented and committed. Draft PR: #1589

Migration (2026_08_24_voter_limit_and_stripe_sessions.ts): adds voter_limit (integer, not null) to electionDB, backfilled via a correlated GREATEST(100, COUNT(head roll rows)) update before the not-null constraint is applied. Verified by hand against a disposable Postgres container: an election with 2 rolls → 100, one with 150 head rolls → 150 (a non-head historical roll row correctly excluded, and both the head and a historical electionDB row for that election correctly backfilled to 150), one with 0 rolls → 100. up/down both round-trip cleanly.

Creates stripeCheckoutSessionsDB exactly per spec (serial PK, unique stripe_checkout_session_id, index on election_id).

Shared config: pricingConfig (FREE_TIER_LIMIT/BLOCK_SIZE/PRICE_PER_BLOCK_CENTS) added in packages/shared/src/config/PricingConfig.ts, re-exported from config/index.ts.

Model: StripeCheckoutSessionsDB in packages/backend/src/Models/ (+ __mocks__ counterpart) with insert/getByStripeSessionId/markPaid/sumVoterLimitPurchases, mirroring EmailEvents.ts's thin-wrapper style.

Election/electionValidation: voter_limit: number added as a required field; validation checks it's a non-negative integer when present.

New-election default: rather than trusting the frontend to send voter_limit, it's set server-side in ElectionsDB.createElection() (election.voter_limit = pricingConfig.FREE_TIER_LIMIT), matching the existing pattern for create_date/update_date/head — same tamper-resistance rationale as those fields.

Bug found and fixed along the way: packages/shared's package.json "./config" export pointed directly at dist/config/SharedConfig.js/.d.ts, bypassing config/index.ts entirely. This meant nothing re-exported from the barrel file — including the new pricingConfig — was actually reachable via @equal-vote/star-vote-shared/config from any consumer. Fixed by pointing the export at index.js/index.d.ts instead (matching how the root "." export already resolves).

Compile-time fallout fixed: five DevElections seed fixtures, test/database_sandbox.ts's buildElection(), and Database.ts/Elections.ts all needed voter_limit wired in to keep Election-typed literals compiling. (Several other typed fixtures using as Election/as NewElection assertions — testInputs.ts, anonymizedBallots.test.ts, writeIns.test.ts, multiRaceResults.test.ts, Wizard.tsx's makeDefaultElection — did not need changes: TS type-assertion comparability doesn't enforce missing required properties the way a direct literal annotation does, confirmed by a full npm run build -ws passing clean.)

Full build (npm run build -ws) and backend test suite (27 suites / 211 tests) both green.

[ArendPeter]

Resolved — see the resolution comment above. Draft PR: #1589