Purpose
Explain the PayPress diagnostics system and how operational events are surfaced to merchants and technical users.
Overview
Diagnostics helps merchants and technical users understand Stripe connectivity, webhook activity, installation identity, log retention, timestamp repair, and operational events without direct database access.
How It Works
PayPress writes webhook and diagnostic entries to the webhook log table. The Event Timeline reads recent entries and displays event type, status, message, and failure details when available.
Diagnostics include normal webhook processing, ownership decisions, refund actions, installation identity events, timestamp anomalies, repair actions, and maintenance operations.
Important Components
- Webhook log table.
- Event Timeline.
- Diagnostics page.
- Log retention setting.
- Manual log cleanup.
- Ownership diagnostics.
- Timestamp anomaly diagnostics.
- Timestamp repair diagnostics.
- Refund diagnostics.
- Installation identity diagnostics.
Data Flow
Operational event -> diagnostic row inserted -> Event Timeline displays row -> retention cleanup removes old log rows when configured.
Timestamp Diagnostics
Timestamp diagnostics exist to make invalid order-date behavior visible without direct database inspection.
Relevant statuses include:
order_timestamp_fallback: PayPress generated an invalid timestamp from the WordPress time helper and usedgmdate('Y-m-d H:i:s')instead.order_timestamp_repaired: PayPress found an invalid persistedcreated_atand repaired it.order_timestamp_repair_failed: PayPress attempted to repair an invalidcreated_at, but the persisted value remained invalid.order_insert_success: A fresh order insert succeeded.order_update_success: An existing order update succeeded.order_duplicate_recovery_success: A duplicate-key race was recovered by updating the existing order.
The v1.3.13 timestamp hardening cycle added update-path and duplicate-recovery repair so existing invalid created_at values do not survive future webhook enrichment.
Packaging Incident Note
The v1.3.13 investigation also uncovered a packaging defect unrelated to timestamp logic. A ZIP package was built with Windows-style backslashes embedded in archive entry names, such as assetsadmin.css and includesclass-settings.php, instead of directory paths such as assets/admin.css and includes/class-settings.php.
On Linux, those entries are treated as literal filenames, so WordPress could not locate required include files and the plugin failed before initialization. The package was rebuilt with correct ZIP directory separators. Future release validation must verify that archive entries use forward slashes only.
Security Considerations
Diagnostics should not log sensitive payloads, raw card data, API keys, webhook secrets, or raw Payment Form responses.
Webhook signature validation failure diagnostics may be expanded as a beta-readiness item to include safe request metadata such as source IP, User-Agent, request URL, and whether the Stripe signature header was present. Sensitive payloads should still never be logged.
Known Limitations
Diagnostics logs are operational support records, not a complete audit ledger. Log cleanup can remove historical diagnostic entries without affecting orders or subscriptions.