Stripe integration: due diligence, modernization arc, and tracking

[rdhyee]

Purpose

Umbrella tracking issue for the Stripe integration in regluit:

• Capture the current state and architecture
• Track the open due-diligence questions raised at the 2026-04-16 and 2026-04-30 Eric meetings
• Track the long-term modernization arc (API version, PaymentIntent, webhook signing)
• Provide a single place to link related issues and PRs

This is not a single-deliverable issue. It will stay open across the Django 4.2 migration (PR #1123) and beyond.

Knowledge map (living): kept in Raymond's notes; this issue is the public anchor.

Context

Eric flagged at the 2026-04-30 meeting that Stripe DD is the named gate for the Django 4.2 migration ship. Doing the DD revealed that we don't have a single place that documents how Stripe is wired into regluit, what's on the modernization arc, or what's known to be broken (#1125). This issue fills that gap.

Architecture, in one paragraph

regluit's `payment/` app abstracts payment processors via `baseprocessor.py`. Today only `stripelib.Processor` is live (PayPal Adaptive and Amazon Payments are vestigial). The `Transaction` model in `payment/models.py` is the canonical record (with `host='stripelib'` for modern rows); `PaymentResponse` is the raw audit log; `Account` links a regluit user to a Stripe Customer. `manager.py` handles transaction lifecycle and dispatches to `stripelib.py`, which calls the Stripe API. `views.py` hosts the webhook receiver and donation endpoints. Three campaign types (REWARDS, B2U, THANKS) interact with Stripe differently; THANKS is by far the dominant active flow.

Yellow flags (known)

• Stripe API version pinned to `2013-02-13` in `stripelib.py`. Stripe is backwards-compat-friendly but this is 12 years old. Modernization to `PaymentIntent` / `PaymentMethod` is a bounded project, not a Django 4.2 prerequisite.
• Webhook signature not verified. The `stripe_webhook` view doesn't validate `Stripe-Signature`. Bounded risk based on what we do with events, but should be fixed.
• Anonymous Stripe Customer for logged-in donors — see Logged-in donations create anonymous Stripe Customer due to token-presence check #1125.
• `Receiver` table is dead — vestige of PayPal Adaptive Payments era. Dead code complicates the payment paths.

Due-diligence checklist (Phase B of #1123)

• B.1 — Quantify completed Stripe charge volume over the last 24 months on prod
• B.2 — Test-mode end-to-end on dj42 (save card with `4242`, charge $1, verify in Stripe dashboard, confirm `Account` and `Transaction` rows correct)
• B.3 — Decide Logged-in donations create anonymous Stripe Customer due to token-presence check #1125 fix in-scope for Upgrade Django 1.11 → 4.2 LTS #1123 vs follow-up
• Confirm dj42 settings point at Stripe test keys, not prod
• Confirm `stripe` Python library version on the Django 4.2 branch (and what changed between current and that)
• Verify the `2013-02-13` API version still works as expected in 2026 (it should — Stripe doesn't deprecate — but worth a sanity check via the dashboard)

Modernization arc (post-#1123)

These are not migration prerequisites. Listed in rough priority:

1. Webhook signature verification (security; small)
2. Fix Logged-in donations create anonymous Stripe Customer due to token-presence check #1125 (correctness; small if not folded into Upgrade Django 1.11 → 4.2 LTS #1123)
3. Strip `Receiver` and PayPal/Amazon vestiges (clarity; medium)
4. API version upgrade to a modern version (forward-compat; medium-large, requires `PaymentIntent` flow)
5. Webhook idempotency review (correctness)

Children / linked issues

• Logged-in donations create anonymous Stripe Customer due to token-presence check #1125 — Logged-in donations create anonymous Stripe Customer

(Will be expanded as DD surfaces things.)

What this issue is NOT

• Not a deliverable issue. Don't expect to "close" this.
• Not a replacement for focused issues — those still get filed separately and linked here.
• Not a Django 4.2 blocker on its own. The DD checklist is the blocker.

[rdhyee]

B.1 — Stripe volume on prod (2026-05-06)

Ran the volume query against payment_transaction filtered to host='stripelib'. Results:

Year	Attempts	Completed	Revenue
2026 YTD	3	1	$5
2025	26	2	$20
2024	23	4	$27
2023	23	3	$41
2022	9	5	$24
2021	4,050	70	$3,225 ← outlier
2020	21	18	$188
2018	74	74	$3,098
2014	244	242	$2,290
2012-2013	335	236	$8,223

Key facts

• Last 24 months: 7 completed Stripe charges totaling ~$52.
• Last 4 years (2022-2026 YTD): 15 completed, $117 total revenue — averaging ~$29/yr.
• Lifetime: 752 completed Stripe charges @ $23.39 avg = $17,589.53.
• Last Stripe Error row: 2024-11-06 (no errors in the last 6 months — the integration works when it's exercised).
• 2021's 4,050 attempts vs only 70 completes (1.7%) looks like card-testing / bot probe activity, not real users. Filed as a separate scan to do.

Reframing for DD

The Stripe integration is technically alive but financially negligible. Migration regression risk is bounded — if Stripe broke entirely on Django 4.2 ship, we'd lose ~$30 of donations/year until detected. The risk model is reputation, not revenue.

DD scope shrinks proportionately: test-mode end-to-end on dj42 (B.2) plus a verified $1 prod charge post-deploy is sufficient. Don't need an exhaustive Stripe sweep.

Strategic question (not a DD blocker, for Eric)

With ~$30/year flowing through Stripe, is the long-term modernization arc (PaymentIntent migration, webhook signature verification, API version upgrade) worth the investment? Or is the right arc "deprecate paid donation flows entirely, leaving only B2U if a campaign returns"? This isn't a question for Phase 2 of #1123 — it's a separate conversation, but the volume data is what makes it a sensible question to ask.

[rdhyee]

Reframing the modernization arc (Raymond, 2026-05-06)

Rereading the B.1 numbers with the right lens: the low volume isn't a "deprecate this?" signal — it's a "now is the cheapest moment to harden Stripe before the spiffed-up unglue.it relaunch brings in real donation traffic" signal.

Stripe's backwards-compat record is excellent (API version 2013-02-13 still works in 2026), so the risk isn't that Stripe breaks. The risk is that we ship a relaunch on top of:

• A 2013-era integration with no webhook signature verification
• No SCA / 3DS support (will silently fail on European-issued cards as donor base grows)
• Logged-in donations create anonymous Stripe Customer due to token-presence check #1125 anonymous Customer bug — annoying at $30/yr, reconciliation hell at $30K/yr

The arc above stays the same, but the priority shifts up:

1. Webhook signature verification — cheap security hardening; trivially worse to fix after traffic arrives
2. Logged-in donations create anonymous Stripe Customer due to token-presence check #1125 anonymous Customer — gets worse with scale
3. API version + PaymentIntent migration — unlocks SCA/3DS, Apple Pay / Google Pay, better card-on-file UX. The features that increase donation conversion live on the modern API. Doing this pre-relaunch means new donation flows ride on the modern surface from day one.
4. Strip Receiver and PayPal/Amazon vestiges (clarity)
5. Webhook idempotency review

None of this changes Phase B's DD scope for #1123 — test-mode on dj42 + verified $1 prod charge post-deploy is still proportionate. But this changes how I'd talk to Eric tomorrow about what comes after #1123.

[rdhyee]

B.2 (Stripe E2E smoke) — done, green.

Save-card + $1 charge validated end-to-end on the Django 4.2 stack (dj42): both the low-level StripeClient path and the regluit Processor/Transaction integration passed (transaction.status = Complete). Stack: Django 4.2.21 / Python 3.12.3 / stripe 5.5.0, API pinned 2013-02-13.

Full result + IDs: #1123 (comment #1123 (comment)).

This closes the B.2 line of the DD checklist. Open Stripe-DD threads unchanged: #1125 (anonymous-customer) still needs a quick test-dashboard check to confirm whether it reproduces under Stripe 5.x; modernization arc (webhook signing, PaymentIntent) remains post-announcement per the low-volume reframe.