Applications

An application begins as an anonymous completion of a club onboarding, with no person or account required. The consumer creates a draft for a club and advances through one ordered block at a time. Its URL identifies the draft; reading or advancing it also requires its scoped application token. A new browser session can recover access by verifying the mailbox. Completing the last block submits the application. The back office lists applications for a club next to the action for editing its onboarding.

Starting an application copies the onboarding revision, questions, options, and signature documents. Drafts and submitted applications therefore remain readable when an administrator edits the source onboarding. Answers are keyed by stable block IDs inside that snapshot.

Every onboarding contains exactly one required Applicant name block and one required Email verification block. The entered name is shown in the back office's Applicant column. Before it is completed, the UI displays Application in progress.

Payment and document-signature steps are explicit, required after-approval steps. Payment opens Stripe Checkout for the plan selected in the application and the club's connected merchant. The step advances only after Champagne receives the signed paid webhook and verifies that exact application Checkout session. On return from Checkout, payment confirmation uses the scoped application access token: applicants do not need to sign in as members before their account setup is complete. While the paid webhook is pending, the consumer checks every two seconds; an error stops automatic checks and offers a retry. Document signature uploads the snapshotted club PDF to Yousign, redirects the verified applicant to its hosted signing flow, and advances only after Champagne confirms the stored Yousign signer is signed. Email verification sends a random six-digit code that expires after ten minutes. Development messages are delivered to the local Mailpit inbox printed by make dev or make worktree-up.

Submitted applications may be Accepted or Rejected. Both actions require confirmation in a dialog before any change or email is sent; rejection allows an optional internal reason. Acceptance atomically creates a person from the name, verified email, and collected address, copies ordinary answers into additional information, and links that person to the originating application. Acceptance and rejection send an email to the applicant. A rejection may include an optional reason, which appears on the application detail page and in its status history. The current rejection email does not include this internal reason. Every applicant advance and reviewer update checks the application revision, preventing two stale clients from silently overwriting one another.

Set YOUSIGN_API_KEY in the API's ignored .env.local during local development and as a secret environment variable in hosted environments. Local development defaults to the sandbox URL in config.mk; override YOUSIGN_API_URL in config.local.mk for another endpoint. Set YOUSIGN_API_URL=https://api.yousign.app/v3 in the hosted runtime for a production key. CONSUMER_ORIGIN supplies the exact return origin, and local .localhost origins are accepted for development. Yousign custom redirect URLs require an eligible paid plan. Sandbox requests use Yousign's supported embedded flow, which emits a completion event before Champagne verifies the signer and returns to the application; production requests use Yousign's hosted redirects.

See Application operations for the complete API contract.

Decision history

The application detail page includes Status history, ordered chronologically, with transition dates, action origins and the reason recorded for a rejection. A rejected application can be accepted directly after confirmation; accepted applications remain final. The former Under review step is no longer available. Its existing history entries are retained; applications still in that old state appear as Submitted and can be accepted or rejected.

Staff decisions record the authenticated actor ID and name. Applicant access uses a scoped application token or the linked member session; older actor details may be absent. Older applications display an explicit incomplete-history notice; no dates or authors are reconstructed. See Status transitions and history for the allowed transitions, atomic persistence and API fields.

Finding applications

Use Filters beside the search field to select one or more statuses and an optional submission-date range (UTC). No selected status means all statuses. Apply filters updates the list; Cancel discards edits; Reset clears the draft filters and takes effect when applied. The button counts active filters. Filters and name/email search are combined on the server and stored in the page URL. The list shows up to 200 newest matches and asks you to narrow the search if that limit is reached.