The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
worldmonitor	Ready	Preview, Comment	Jun 26, 2026 8:49am

Greptile Summary

This PR fixes a critical visibility gap in the Dodo Payments webhook pipeline: payment.processing, payment.requires_customer_action, and payment.cancelled events were silently dropped by the default branch of the dispatcher, leaving 3DS/SCA payments with no record in Convex. The fix routes all three through handlePaymentOrRefundEvent and replaces the old binary endsWith(".succeeded") ? … : "failed" status derivation with a lookup map.

• convex/schema.ts: Additive union widening of paymentEventStatus with three new literals (processing, requires_customer_action, cancelled); fully backward-compatible, no backfill needed.
• convex/payments/webhookMutations.ts + subscriptionHelpers.ts: Three new case labels route through the existing handlePaymentOrRefundEvent, and a PAYMENT_EVENT_STATUS map replaces the old binary derivation, correctly labeling all event types for both payment and refund events.
• convex/__tests__/webhook.test.ts: Parameterized test for each new event type plus a two-event sequence test proving dedup is strictly by webhookId, not dodoPaymentId.

Confidence Score: 4/5

Safe to merge — the schema change is purely additive, no existing rows are affected, and the routing change only adds cases to a switch that previously dropped those events entirely.

The map lookup with a ?? "failed" fallback in subscriptionHelpers.ts is an improvement over the old binary derivation, but it can still silently mislabel any future event type added to the switch without a matching map entry. The four changed files are well-tested and all new paths are covered.

convex/payments/subscriptionHelpers.ts — the PAYMENT_EVENT_STATUS map's loose Record<string, …> key type means the map and switch can drift without a compile error.

Important Files Changed

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant Dodo as Dodo Payments
    participant HTTP as HTTP Action Handler
    participant WM as processWebhookEvent
    participant SH as handlePaymentOrRefundEvent
    participant DB as Convex DB

    Dodo->>HTTP: POST /webhook (payment.requires_customer_action)
    HTTP->>WM: internalMutation(webhookId, eventType, payload, ts)
    WM->>DB: query webhookEvents by webhookId
    DB-->>WM: null (not yet processed)
    WM->>SH: handlePaymentOrRefundEvent(ctx, data, eventType, ts)
    SH->>DB: resolveUserId(customer_id, metadata)
    DB-->>SH: userId
    Note over SH: PAYMENT_EVENT_STATUS[eventType] → "requires_customer_action"
    SH->>DB: insert paymentEvents row (status: requires_customer_action)
    WM->>DB: insert webhookEvents row (status: processed)

    Note over Dodo,DB: Later — customer completes 3DS

    Dodo->>HTTP: POST /webhook (payment.succeeded, new webhookId)
    HTTP->>WM: internalMutation(webhookId2, "payment.succeeded", payload, ts2)
    WM->>DB: query webhookEvents by webhookId2
    DB-->>WM: null (distinct webhookId — not a duplicate)
    WM->>SH: handlePaymentOrRefundEvent(ctx, data, "payment.succeeded", ts2)
    SH->>DB: insert paymentEvents row (status: succeeded)
    WM->>DB: insert webhookEvents row (status: processed)

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant Dodo as Dodo Payments
    participant HTTP as HTTP Action Handler
    participant WM as processWebhookEvent
    participant SH as handlePaymentOrRefundEvent
    participant DB as Convex DB

    Dodo->>HTTP: POST /webhook (payment.requires_customer_action)
    HTTP->>WM: internalMutation(webhookId, eventType, payload, ts)
    WM->>DB: query webhookEvents by webhookId
    DB-->>WM: null (not yet processed)
    WM->>SH: handlePaymentOrRefundEvent(ctx, data, eventType, ts)
    SH->>DB: resolveUserId(customer_id, metadata)
    DB-->>SH: userId
    Note over SH: PAYMENT_EVENT_STATUS[eventType] → "requires_customer_action"
    SH->>DB: insert paymentEvents row (status: requires_customer_action)
    WM->>DB: insert webhookEvents row (status: processed)

    Note over Dodo,DB: Later — customer completes 3DS

    Dodo->>HTTP: POST /webhook (payment.succeeded, new webhookId)
    HTTP->>WM: internalMutation(webhookId2, "payment.succeeded", payload, ts2)
    WM->>DB: query webhookEvents by webhookId2
    DB-->>WM: null (distinct webhookId — not a duplicate)
    WM->>SH: handlePaymentOrRefundEvent(ctx, data, "payment.succeeded", ts2)
    SH->>DB: insert paymentEvents row (status: succeeded)
    WM->>DB: insert webhookEvents row (status: processed)

_{Reviews (1): Last reviewed commit: "fix(payments): persist pending/3DS payme..." | Re-trigger Greptile}

Both review points validated and fixed in ce16e87d8.

#1 (P1) — payment.requires_customer_action is not a real event type ✅ Confirmed, was dead code

Verified two independent ways:

• Installed SDK node_modules/dodopayments/resources/webhook-events.d.ts:13 — WebhookEventType payment events are exactly payment.succeeded | payment.failed | payment.processing | payment.cancelled. No payment.requires_customer_action.
• IntentStatus (payments.d.ts:93) — requires_customer_action is a payload data.status value, and Payment.status?: IntentStatus | null (payments.d.ts:254).
• Official docs (Webhook Event Guide + Create-Webhook filter_types) agree: the 3DS/SCA-pending state rides inside the payment.processing event as data.status: "requires_customer_action"; there is no distinct event.

Fix: dropped the dead payment.requires_customer_action case; route the real payment.processing event and read data.status to distinguish plain processing from requires_customer_action. Tests now drive payment.processing + data.status (incl. the 3DS-pending → succeeded distinct-webhookId sequence).

#2 (P2) — Record<string> + ?? "failed" allows silent drift ✅ Fixed

Replaced the string-keyed map + silent fallback with a typed RoutedPaymentEvent union and an exhaustive derivePaymentEventStatus switch with a never default that throws. Now:

• adding a routed event to the union without a switch case → compile error;
• routing a new event in webhookMutations.ts without updating the union → the never default throws loudly (webhook 500 → Sentry), never a silent failed mislabel.

462 convex tests green, tsc -p convex clean.

Good catch — valid precision nit. Fixed in 7e82d66be (comment-only).

You're right: the compile-time exhaustiveness guarantee is intra-file only (the RoutedPaymentEvent union ↔ the derivePaymentEventStatus switch). Cross-file drift — a new case in webhookMutations.ts — is laundered by the eventType as RoutedPaymentEvent cast at the call site, so it's caught at runtime by the never-default throw, not at compile time. The old comment conflated the two; it now spells out both guards and their different enforcement. No behavior change.