feat: add Stripe Terminal SDK integration and on-site POS

[JacobCoffee]

Summary

• Add TerminalPayment model extending Payment with terminal-specific fields (reader_id, capture_status, card_brand/last4, receipt_url)
• Add Stripe Terminal SDK methods to StripeClient: connection tokens, reader listing, pre-auth payment intents, reader dispatch, capture/cancel
• Add 8 JSON API endpoints for the POS flow: connection-token, create-payment-intent, capture, cancel, attendee lookup, inventory, cart operations, reader list
• Add POS UI template in manage app: three-panel layout with reader connection, attendee lookup, product catalog, cart builder, and full payment flow with Stripe Terminal JS SDK
• Add TERMINAL payment method to Payment.Method choices
• 22 tests covering models, API views (with mocked Stripe), and manage views

Design notes

• Pre-authorization flow: create intent with capture_method=manual → dispatch to reader → cardholder taps → capture after confirmation
• Supports both order-linked payments and walk-up (amount-based) sales
• POS UI uses Stripe Terminal JS SDK v1 for reader connection and card collection
• Permission model matches check-in system (requires change_conference perm)

Test plan

• 22 new tests pass (tests/test_registration/test_terminal.py)
• All 1903 tests pass (1 pre-existing flaky test)
• Lint, format, and type-check pass (make ci)
• Manual verification with Stripe Terminal simulated reader
• Verify POS UI renders and connects to reader

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[Copilot]

Pull request overview

Adds a staff-facing Stripe Terminal Point-of-Sale flow to the registration system, including a new terminal payment model, JSON API endpoints for the POS workflow, and a manage UI page for on-site payments.

Changes:

• Introduces TerminalPayment model and adds TERMINAL to Payment.Method.
• Adds Stripe Terminal support in StripeClient and new staff-only JSON endpoints (views_terminal.py) + URL wiring.
• Adds manage UI page (terminal_pos.html) and navigation entry, plus tests covering the new model/endpoints/manage view.

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 12 comments.

Show a summary per file

File	Description
tests/test_registration/test_terminal.py	New tests for terminal model, API endpoints (mocked Stripe), and manage POS view permissions/context.
src/django_program/registration/views_terminal.py	Implements staff-only JSON endpoints for connection tokens, intents, capture/cancel, attendee lookup, inventory, cart ops, and reader listing.
src/django_program/registration/views_checkin.py	Small refactor/formatting change in JSON parsing helper and a long line wrap.
src/django_program/registration/urls.py	Wires up new terminal JSON endpoints under the registration app.
src/django_program/registration/terminal.py	Adds TerminalPayment model to store terminal-specific metadata/lifecycle.
src/django_program/registration/stripe_client.py	Adds Stripe Terminal wrapper methods (connection token, list readers, create/process intents, cancel action).
src/django_program/registration/models.py	Adds TERMINAL payment method choice and exports TerminalPayment.
src/django_program/registration/migrations/0018_alter_payment_method_terminalpayment.py	Migration to add Terminal payment method choice and create TerminalPayment table.
src/django_program/registration/admin.py	Adds read-only admin for TerminalPayment.
src/django_program/manage/views_terminal.py	Adds manage TerminalPOSView rendering the POS template.
src/django_program/manage/urls.py	Adds manage route for the terminal POS page.
src/django_program/manage/templates/django_program/manage/terminal_pos.html	Adds POS UI (layout + Stripe Terminal JS integration + client-side flow).
src/django_program/manage/templates/django_program/manage/base.html	Adds sidebar nav entry for “Terminal POS”.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

In general, to fix information exposure through exceptions, you should avoid returning raw exception messages or stack traces to the client. Instead, log the exception (including stack trace) on the server for debugging, and send the client a generic, non-sensitive error message (optionally with a stable error code) so that behavior is preserved without leaking internal details.

Here, the problematic code is in src/django_program/registration/views_terminal.py inside the post method shown, specifically the except ValueError as exc: block at lines 348–351. The fix is to change this block so that it logs the exception (using the already-configured logger in this module) and returns a generic error string. To avoid changing existing functionality more than necessary, we keep the HTTP status code 400 (client error) and still indicate a configuration failure in a generic way, e.g. "Stripe configuration error" or "Unable to initialize Stripe client", while not including str(exc) in the response. We can also include the exception and, optionally, stack information in the log via logger.exception, which uses the existing logger import and definition at the top of the file, so no new imports are needed.

Concretely:

• Edit the except ValueError as exc: block so that:
  • It calls logger.exception("Failed to initialize Stripe client") (or similar), passing exc for context.
  • It returns JsonResponse({"error": "Unable to initialize Stripe client"}, status=400) (or a similarly generic message).
• No changes are needed elsewhere in this file for this fix.