Purpose
Identify safe architectural paths for future PayPress features.
Overview
Future PayPress features should extend existing systems instead of creating parallel payment, order, form, or analytics engines.
How It Works
New features should reuse Plans, Checkout Context, Orders, Webhooks, Subscriptions, Campaign Snapshots, and the Admin Design System wherever possible.
Important Components
- Plans as offer configuration.
- Checkout context as pre-webhook durable storage.
- Orders as purchase records.
- Subscriptions as Stripe mirrors.
- Webhooks as synchronization source.
- Campaign snapshots for cache-safe public state.
- Payment Forms JSON model.
.pp-*admin design system.
Data Flow
Feature idea -> identify existing source of truth -> extend smallest existing model -> preserve Stripe authority -> add diagnostics -> update docs.
Security Considerations
New features should preserve ownership validation, server-side validation, Stripe as source of truth, and privacy boundaries around metadata/logging.
Known Limitations
Deferred features include partial refunds, conditional logic, reusable forms, digital downloads, free trial setup, address fields, broader currency hardening, and installation-scoped analytics.