Purpose
Describe how PayPress starts Stripe Checkout while keeping public marketing pages cacheable.
Overview
The launcher architecture separates public payment presentation from dynamic Checkout Session creation. Cached pages can render payment offers, while uncached launcher endpoints validate requests and create Stripe Checkout Sessions.
How It Works
When a customer clicks a one-time, subscription, donation, or fundraising checkout action, PayPress sends the request to a server-side launcher. The launcher validates the plan, payment type, amount, availability, customer context, and enabled settings before creating the Stripe Checkout Session.
Important Components
- Front-end shortcode/card markup.
- One-time and subscription launcher flows.
- Donation launcher.
- No-JavaScript donation route.
- Checkout service.
- Checkout context table.
- Stripe Checkout Session creation.
- Success page return handling.
Data Flow
Cached offer page -> customer action -> uncached launcher endpoint -> server validation -> Stripe Checkout Session -> redirect to Stripe -> webhook creates local records.
Security Considerations
Launcher validation is server-authoritative. Client-provided amount, plan, or campaign state cannot be trusted. Nonces embedded in cached public pages are avoided where possible.
Known Limitations
Payment Forms currently rely on the JavaScript path for the full dynamic experience. No-JavaScript Payment Form support is a future possibility, not an implemented universal fallback.