Current payment status
No payment webhook endpoint is currently active in this application.
Payment processing, checkout fulfillment, subscriptions, and paid report delivery must not be treated as enabled until the payment integration is implemented, reviewed, and verified.
Future webhook verification requirements
Any future payment webhook must verify the provider signature before parsing trust-sensitive fields, granting access, generating reports, or updating paid status.
The verifier must use the raw request body, the provider signature header, and a webhook secret stored in environment variables, not in source code.
Replay and duplicate protection
Payment event IDs must be stored and processed idempotently so repeated provider retries do not generate duplicate reports or duplicate credits.
Webhook timestamps should be checked when supported by the provider, and stale or replayed events should be rejected.
Event allowlist
Only expected event types should trigger fulfillment. Unknown, test, failed, refunded, disputed, or incomplete payment events must not unlock paid content.
Fulfillment should be based on trusted provider event status and internal order state, not only on client-side success pages.
Storage and download security
Stored PDFs should use private object storage, least-privilege credentials, short-lived signed download URLs, and object keys that do not expose sensitive user information.
Logs should avoid recording secrets, full payment identifiers, signed URLs, or sensitive report contents.
Operational review
Before payment launch, the webhook route should have automated tests for missing signatures, invalid signatures, duplicate events, unrecognized event types, failed payments, and successful fulfillment.
The release checklist should include security audit, dependency audit, environment secret review, and a live provider test event.