Purpose
Explain the durable storage layer used between front-end submission and webhook order creation.
Overview
Checkout context exists because PayPress collects some local data before redirecting to Stripe, while the final order is created later by webhooks.
How It Works
Before creating Stripe Checkout, PayPress persists a context record containing launch details such as plan, payment type, donation amount, customer notes, and Payment Form submission references/snapshots. Stripe metadata stores references, not full customer responses.
Important Components
- Checkout context table.
- Launch token/context identifier.
- Plan ID.
- Payment type.
- Donation amount.
- Customer notes.
- Form submission ID.
- Form revision.
- Sanitized response snapshot.
- Webhook lookup logic.
Data Flow
Customer submits local fields -> server validates -> context persisted -> Checkout Session created with context references -> webhook arrives -> PayPress finds context -> order created with local snapshot data.
Security Considerations
Context prevents data loss without exposing raw responses to Stripe metadata. Context lookup should happen only after webhook ownership validation.
Known Limitations
Context records need cleanup/retention strategy over time. The system is not intended as a long-term form submission table; order snapshots are the durable historical record.