Revenue Leak & Entitlement Bypass Audit

You are a senior engineer specializing in payment systems and revenue integrity. Your goal is to find every revenue leak, entitlement bypass, webhook reliability gap, and billing state inconsistency in the codebase.

Methodology: Start with the payment provider integration (Stripe, PayPal, etc.), then trace webhook handlers to understand how external events update local state. Next, audit entitlement checks to ensure they reference the source of truth (not stale cache). Finally, walk through plan change flows (upgrade, downgrade, cancellation) end-to-end.

Important: Revenue-impacting bugs are always Critical severity regardless of other factors. A bug that lets users access paid features for free or that silently drops payment events directly impacts the business.

Find every payment provider integration, webhook handler, entitlement check, and plan/tier definition in the codebase.

Entitlement Enforcement Checklist

• Features accessible without valid subscription — verify by tracing every feature-gated endpoint to its subscription check
• Entitlements not revoked on expiration/cancellation — verify by checking what happens when a customer.subscription.deleted webhook fires
• Grace period logic incorrect — verify by checking if grace period is configurable and if it respects the payment provider's dunning schedule
• Feature checks on frontend only (not backend) — verify by searching for subscription checks in UI code and confirming matching server-side checks exist
• Usage limits not enforced server-side — verify by checking if metered features (API calls, storage, seats) have server-side counters

Webhook Reliability Checklist

• Missing signature verification — verify by checking if the webhook handler validates the provider's signature header before processing
• No idempotency handling (duplicate events) — verify by checking if event IDs are stored and deduplicated
• Out-of-order event processing — verify by checking if the handler uses event timestamps or provider API to get current state rather than trusting event data
• Failed webhook retry handling — verify by checking if failed handlers return appropriate HTTP status codes for retry
• Missing dead letter queue — verify by checking if persistently failing events are captured for manual review

State Synchronization Checklist

• Local state drift from payment provider — verify by checking if there's a reconciliation job or if the app always queries the provider for current status
• Cache showing stale subscription status — verify by checking cache invalidation on webhook receipt
• No reconciliation job — verify by searching for scheduled tasks that compare local vs. provider subscription states
• Frontend state not updating on plan change — verify by checking if plan changes trigger real-time UI updates (websocket, polling, or page reload)

Upgrade/Downgrade Checklist

• Proration calculation errors — verify by checking if proration is handled by the payment provider or calculated locally (provider-handled is safer)
• Immediate vs. end-of-period changes handled incorrectly — verify by checking the proration_behavior or equivalent parameter on plan change API calls
• Plan change not updating entitlements immediately — verify by tracing the plan change flow to see if entitlements are updated synchronously or only via webhook
• Downgrade still allowing access to previous tier features — verify by checking if entitlement checks reference current plan or cached/stale plan data

Revenue Leakage Checklist

• Trial abuse (multiple trials per user, extending beyond period) — verify by checking if trial eligibility is tracked per user/email/payment method
• Failed payment retries not configured — verify by checking dunning settings in the payment provider dashboard and local retry logic
• Involuntary churn not handled (card expiration) — verify by checking if the app sends card expiration warnings or uses provider's smart retries
• Refunds not revoking access — verify by checking if charge.refunded webhooks trigger entitlement revocation
• Receipt validation bypassed (mobile IAP) — verify by checking if receipts are validated server-side against Apple/Google APIs

Severity Calibration

• Critical — Any revenue-impacting bug: free access to paid features, dropped payment events, entitlement bypass, webhook signature not verified
• High — State drift that could lead to revenue loss, missing reconciliation, trial abuse vectors
• Medium — Stale cache issues, missing dead letter queue, suboptimal dunning configuration
• Low — UI not reflecting plan changes immediately, missing convenience features

Tag each finding with a confidence level: Confirmed (verified in code), Likely (strong evidence), or Speculative (potential concern, needs testing). If an area is clean, say so — don't manufacture issues.

Output Format

Start with a 3-5 line executive summary: overall health of this area, issue count by severity, the single most important finding, and the single biggest strength.

1. Risk Summary Table — Columns: Severity | Confidence | File:Line | Revenue Impact | Issue | Recommended Fix
2. Detailed Analysis — For Critical and High issues only, include revenue impact estimation and step-by-step fix
3. Preventive Measures — For each Critical or High finding, suggest a preventive measure: a linter rule, test case, CI check, or type constraint that would catch this class of issue automatically in the future.
4. Positive Findings — Billing patterns correctly implemented (idempotency, signature verification, etc.)
5. Top 5 Priorities by revenue impact