fix(console): activate Lite subscription in invoice.payment_succeeded to handle 3DS/SCA#28409
Open
PanAchy wants to merge 6 commits into
Open
fix(console): activate Lite subscription in invoice.payment_succeeded to handle 3DS/SCA#28409PanAchy wants to merge 6 commits into
PanAchy wants to merge 6 commits into
Conversation
Billing.generateReceiptUrl was calling Stripe with a caller-supplied paymentID without checking that the payment belongs to the caller's workspace. Any authenticated user who knew a payment intent ID from another workspace could retrieve that workspace's Stripe receipt URL (billing email, card last-4, amount, date) — a classic IDOR. Fix: look up the payment in PaymentTable scoped to Actor.workspace() before calling Stripe. Throw if not found.
… to handle 3DS/SCA
In 3DS/SCA payment flows Stripe attaches the payment method asynchronously
after the checkout redirect, so default_payment_method is null at the time
customer.subscription.created fires. The previous guard
if (!paymentMethodID) throw new Error('Payment method ID not found')
caused the entire activation block to be skipped. Stripe retries the webhook
for 72 hours and then gives up, leaving the user permanently locked out of
Lite with no recovery path.
Fix:
- Move lite subscription activation (BillingTable.lite, LiteTable insert,
coupon redemption) from customer.subscription.created to
invoice.payment_succeeded with billing_reason === 'subscription_create'.
Payment confirmation is the correct trigger; it fires for both immediate-
payment and 3DS/SCA flows.
- Look up workspaceID, userID, userEmail, and coupon directly from the
Stripe subscription metadata instead of BillingTable, making activation
independent of whether customer.subscription.created succeeded.
- Split subscription_create and subscription_cycle branches in
invoice.payment_succeeded so activation logic is isolated.
- Add an idempotency guard (billing.lite check) so Stripe retries are safe.
- customer.subscription.created now only records customerID and
liteSubscriptionID; activation is deferred to payment confirmation.
…on redemption from activation guard
Contributor
|
The following comment was made by an LLM, it may be inaccurate: Found 1 potentially related PR:
|
This was referenced May 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue for this PR
Closes #28408
Type of change
What does this PR do?
Lite subscription activation was handled in
customer.subscription.created, which readsdefault_payment_methodfrom the subscription object. In 3DS/SCA flows Stripe attaches the payment method asynchronously after the redirect, sodefault_payment_methodisnullwhen this event fires. The handler threw before writing anything to the DB. Stripe retried for 72 hours then stopped — the user's card was charged butBillingTable.litewas never set andLiteTablewas never populated.The fix moves activation to
invoice.payment_succeededwithbilling_reason === "subscription_create", which fires only after Stripe confirms payment and is correct for both immediate-payment and 3DS/SCA flows.customer.subscription.creatednow only recordscustomerIDandliteSubscriptionID. All activation logic —BillingTable.lite,LiteTableinsert, payment method fields, coupon redemption — happens ininvoice.payment_succeeded.Workspace/user metadata is read from the Stripe subscription object (always available) rather than from the webhook payload, making activation independent of whether
customer.subscription.createdsucceeded.Two additional correctness fixes are included:
userIDis validated before thePaymentTableinsert so a missinguserIDcannot produce an orphan payment row that blocks retries.!billing.liteguard so that if the activation transaction commits but redemption fails, a Stripe retry can still redeem the coupon (redeemCouponis idempotent ontimeRedeemed).How did you verify your code works?
bun typecheckinpackages/console— no errors.invoice.payment_succeededwithbilling_reason === "subscription_create"fires after payment confirmation in both the immediate and 3DS/SCA Stripe flows (Stripe docs).workspaceID,userID,userEmail,coupon) is always set at subscription creation time and available on the subscription object regardless of webhook ordering.Screenshots / recordings
If this is a UI change, please include a screenshot or recording.
Checklist
If you do not follow this template your PR will be automatically rejected.