feat: automate abandoned-checkout recovery email firing (drop the manual CSV step)

[aalemayhu]

Current state

POST /api/ops/send-abandoned-checkout-recovery exists (shipped in #2270, RequireOpsAccess) but is fed manually: extract abandoned checkout emails from a Stripe CSV on Al's box, paste them into the request body, fire once.

Manual = it doesn't happen on a cadence = revenue left on the table.

Goal

Remove the manual step. The system should detect abandoned Stripe Checkout sessions and email those users automatically, on a predictable schedule, with idempotency so a single user isn't emailed twice for the same session.

Mechanism — open question

Two viable triggers:

Option A — Stripe webhook on checkout.session.expired

• Stripe fires this event when a Checkout Session expires (default 24h after creation).
• Pros: event-driven, no polling, exact timing.
• Cons: needs webhook signature verification (already in place for other events), needs storage to dedupe replays.

Option B — Daily cron pulling from Stripe

• stripe.checkout.sessions.list({ status: 'expired', created: { gte: <yesterday> } })
• Pros: simple, no new webhook surface, easy to backfill.
• Cons: timing is approximate, polling cost.

Lean: A. We already verify Stripe webhooks for subscription events; this is an additional event type, not a new mechanism. Confirm before building.

Dedupe

New table or column: track which Stripe session IDs have already received a recovery email. Reject duplicates at the use case.

Acceptance

• Stripe webhook on checkout.session.expired (or cron, depending on the trigger decision) fires SendAbandonedCheckoutRecoveryUseCase automatically
• Each session ID is emailed at most once (dedupe column or table)
• Backfill ran once with the 234-email CSV on Al's box, then the manual endpoint is retired
• Performance tab /ops/performance shows recovery-email volume (extension to existing observability)

Out of scope

• New email copy — the template shipped in feat: observability — performance tab, country capture, recovery email #2270 stands as-is until we measure conversion
• Subscription cancellation recovery (different funnel, different copy)

Effort: S–M. Dependency on #2270 which is already shipped.

[impetus82]

Hi, I can take a focused first pass on the abandoned-checkout automation for USD 90.

Scope:

• wire checkout.session.expired or the existing scheduled path into the recovery-email flow
• add dedupe so the same abandoned checkout does not email twice
• keep manual CSV replacement limited to this recovery path
• include tests or a documented local verification using a fixture event

Recent payment/webhook work:

• Stripe signature PR: Verify Stripe webhook signatures niro3-1/saas-backend#13
• ActualBudget: Fix split transaction popover wrapping actualbudget/actual#7814
• Qualcomm PatchWise: Allow grep file filter to target directories qualcomm/PatchWise#89

If this is still needed, confirm whether you prefer event-driven Stripe handling or a scheduled job first.

[aalemayhu]

Thanks, I am currently AFK. Let me get back to you. Mit freundlichen Grüßen Alexander Alemayhu søn. 17. mai 2026 kl. 12:34 skrev Tonchain ***@***.***>:

…

*impetus82* left a comment (2anki/server#2279) <#2279 (comment)> Hi, I can take a focused first pass on the abandoned-checkout automation for USD 90. Scope: - wire checkout.session.expired or the existing scheduled path into the recovery-email flow - add dedupe so the same abandoned checkout does not email twice - keep manual CSV replacement limited to this recovery path - include tests or a documented local verification using a fixture event Recent payment/webhook work: - Stripe signature PR: niro3-1/saas-backend#13 <niro3-1/saas-backend#13> - ActualBudget: actualbudget/actual#7814 <actualbudget/actual#7814> - Qualcomm PatchWise: qualcomm/PatchWise#89 <qualcomm/PatchWise#89> If this is still needed, confirm whether you prefer event-driven Stripe handling or a scheduled job first. — Reply to this email directly, view it on GitHub <#2279 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHB25FOKZY57GYT5STVS4L43GITNAVCNFSM6AAAAACY7YIRWOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINZQGMYTCNZTGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[impetus82]

Thanks, no rush. I will wait for your confirmation before starting any code. If you decide to proceed, I can keep the first PR limited to one recovery path plus dedupe and verification notes.

[aalemayhu]

Hi @impetus82,

Thanks for the offer. I'm going to keep #2279 in-house — Stripe webhook + dedupe + email touches enough of our payment and user-trust surface that I'd rather ship it myself.

If you'd like to contribute, #2360 (replace window.confirm with an in-app modal for account deletion) is a clean first issue. We don't run a paid bounty arrangement — contributions go through normal PR review, same as anyone else.

Thanks again,
Alexander

[impetus82]

Thanks for the clear reply, Alexander. That makes sense for a payment/user-trust flow.

I will skip #2279 then. Appreciate the pointer to #2360.

[aalemayhu]

@impetus82 you run the commands /spec-draft-pr and then /implement with the github url #2360. Also possible to just do

/implement https://github.com/2anki/server/issues/2360

After PR is open remember to run

/pr-checks
/security-review