github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 07:18:56 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #3690] Regression: Active subscription detection may select wrong subscription if multiple are present #18320

New Issue
Closed
opened 2026-04-15 16:44:48 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-04-15 16:44:48 -05:00
Owner
Copy Link

Originally created by @fml-aprc on GitHub (Jul 29, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/3690

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

Description
Since commit c2fb1aa3, the logic for retrieving the active subscription has changed. Previously, the code would strictly look for the subscription matching subscriptionToUpdate?.stripeSubscriptionId or ctx.body.subscriptionId among active subscriptions.
Now, it fetches all subscriptions with status active or trialing, and if no subscriptionToUpdate?.stripeSubscriptionId is provided, it simply picks the first result (.find(... ? sub.id === ... : true)).

Steps to Reproduce

Create several active/trialing subscriptions for the same Stripe customer.
Call the feature without providing a subscriptionToUpdate?.stripeSubscriptionId.
Notice that the chosen subscription may not be the expected one.

const activeSubscriptions = await client.subscriptions
  .list({
    customer: customerId,
  })
  .then((res) =>
    res.data.filter(
      (sub) => sub.status === "active" || sub.status === "trialing",
    ),
);

const activeSubscription = activeSubscriptions.find((sub) =>
  subscriptionToUpdate?.stripeSubscriptionId
    ? sub.id === subscriptionToUpdate?.stripeSubscriptionId
    : true, // <== Here the first subscription is selected
  );

Current vs. Expected behavior

If a customer has several active or trialing subscriptions and no subscriptionToUpdate?.stripeSubscriptionId is provided, the current logic just picks the first subscription returned by Stripe.
This can result in selecting the wrong subscription, leading to unexpected behavior when updating or managing subscriptions.

What version of Better Auth are you using?

1.3.4

Provide environment information

- OS Mac OS
- Browser Chrome

Which area(s) are affected? (Select all that apply)

Backend

Auth config (if applicable)

import { betterAuth } from "better-auth"
export const auth = betterAuth({
  emailAndPassword: {  
    enabled: true,
    organization(),
    stripe(),
  },
});

Additional context

No response

Originally created by @fml-aprc on GitHub (Jul 29, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/3690 ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce **Description** Since commit c2fb1aa3, the logic for retrieving the active subscription has changed. Previously, the code would strictly look for the subscription matching subscriptionToUpdate?.stripeSubscriptionId or ctx.body.subscriptionId among active subscriptions. Now, it fetches all subscriptions with status active or trialing, and if no subscriptionToUpdate?.stripeSubscriptionId is provided, it simply picks the first result (.find(... ? sub.id === ... : true)). **Steps to Reproduce** Create several active/trialing subscriptions for the same Stripe customer. Call the feature without providing a subscriptionToUpdate?.stripeSubscriptionId. Notice that the chosen subscription may not be the expected one. ```js const activeSubscriptions = await client.subscriptions .list({ customer: customerId, }) .then((res) => res.data.filter( (sub) => sub.status === "active" || sub.status === "trialing", ), ); const activeSubscription = activeSubscriptions.find((sub) => subscriptionToUpdate?.stripeSubscriptionId ? sub.id === subscriptionToUpdate?.stripeSubscriptionId : true, // <== Here the first subscription is selected ); ``` ### Current vs. Expected behavior If a customer has several active or trialing subscriptions and no subscriptionToUpdate?.stripeSubscriptionId is provided, the current logic just picks the first subscription returned by Stripe. This can result in selecting the wrong subscription, leading to unexpected behavior when updating or managing subscriptions. ### What version of Better Auth are you using? 1.3.4 ### Provide environment information ```bash - OS Mac OS - Browser Chrome ``` ### Which area(s) are affected? (Select all that apply) Backend ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true, organization(), stripe(), }, }); ``` ### Additional context _No response_
GiteaMirror added the lockedbug labels 2026-04-15 16:44:48 -05:00
GiteaMirror commented 2026-04-15 16:44:50 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jul 29, 2025):

Hi @fml-aprc! I'm Dosu and I’m helping the better-auth team.

You’re correct—since commit c2fb1aa3, the logic for selecting an active subscription changed. Now, if multiple active or trialing subscriptions exist and no specific subscription ID is provided, the code just picks the first one returned by Stripe, which can easily select the wrong subscription and cause unexpected behavior when managing or updating subscriptions. This affects endpoints like upgradeSubscription, cancelSubscription, restoreSubscription, and subscriptionSuccess, as well as webhook handling—all of which use similar logic and lack safeguards for this ambiguity (source).

To avoid this, you should require an explicit subscription ID whenever there’s more than one active or trialing subscription for a customer. If no ID is provided and multiple matches exist, throw an error or prompt for selection instead of defaulting to the first result. This will prevent silent mis-selection and make the behavior predictable. There’s currently no test coverage for this edge case, so adding tests that simulate multiple active/trialing subscriptions and assert that ambiguous selection is not allowed would help prevent future regressions.

Let me know if you want a code snippet or more details on how to implement this check.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

<!-- gh-comment-id:3133313975 --> @dosubot[bot] commented on GitHub (Jul 29, 2025): <!-- Greeting --> Hi @fml-aprc! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> You’re correct—since commit c2fb1aa3, the logic for selecting an active subscription changed. Now, if multiple active or trialing subscriptions exist and no specific subscription ID is provided, the code just picks the first one returned by Stripe, which can easily select the wrong subscription and cause unexpected behavior when managing or updating subscriptions. This affects endpoints like upgradeSubscription, cancelSubscription, restoreSubscription, and subscriptionSuccess, as well as webhook handling—all of which use similar logic and lack safeguards for this ambiguity [(source)](https://github.com/better-auth/better-auth/blob/ed574aa2fbd21c1b9e28d4554993067b159a568b/packages/stripe/src/index.ts). To avoid this, you should require an explicit subscription ID whenever there’s more than one active or trialing subscription for a customer. If no ID is provided and multiple matches exist, throw an error or prompt for selection instead of defaulting to the first result. This will prevent silent mis-selection and make the behavior predictable. There’s currently no test coverage for this edge case, so adding tests that simulate multiple active/trialing subscriptions and assert that ambiguous selection is not allowed would help prevent future regressions. Let me know if you want a code snippet or more details on how to implement this check. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/6c9cbad3-0817-42d9-ba9f-98031fcacb4d?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/6c9cbad3-0817-42d9-ba9f-98031fcacb4d?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/6c9cbad3-0817-42d9-ba9f-98031fcacb4d?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/6c9cbad3-0817-42d9-ba9f-98031fcacb4d?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/6c9cbad3-0817-42d9-ba9f-98031fcacb4d?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/6c9cbad3-0817-42d9-ba9f-98031fcacb4d?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/6c9cbad3-0817-42d9-ba9f-98031fcacb4d?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/3690)
GiteaMirror commented 2026-04-15 16:44:51 -05:00
Author
Owner
Copy Link

@fml-aprc commented on GitHub (Jul 29, 2025):

The problem is that you can't create new subscription (with another organization for exemple).
Existing subscription will automatically be selected as active subscription...

<!-- gh-comment-id:3133846800 --> @fml-aprc commented on GitHub (Jul 29, 2025): The problem is that you can't create new subscription (with another organization for exemple). Existing subscription will automatically be selected as active subscription...
GiteaMirror commented 2026-04-15 16:44:52 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jul 29, 2025):

This happens because the current logic always selects the first active subscription for a Stripe customer, so if you try to create a new subscription (for another organization, for example), it just reuses the existing one instead of letting you create a separate subscription.

To support multiple subscriptions per user (e.g., one per organization), you need to enable organization-level Stripe customers. In your Stripe plugin config, set createOrganizationCustomer: true. This makes each organization get its own Stripe customer and subscriptions, so creating a new subscription for a different org won’t conflict with the user’s existing subscriptions. You should also implement the authorizeReference function to control which users can manage subscriptions for which organizations.

Example config:

stripe({
  // ...other options
  createCustomerOnSignUp: false,
  createOrganizationCustomer: true,
  subscription: {
    // ...other subscription options
    authorizeReference: async ({ user, referenceId, action }) => {
      // Check if user is allowed to manage subscriptions for this org
      // e.g., check membership in your DB
      return true; // or your own logic
    },
  },
})

When creating or managing a subscription, pass the organization’s ID as referenceId. This ensures the subscription is scoped to the org, not the user. If you don’t set up authorizeReference, passing a custom referenceId will throw an error see details.

This setup solves the problem of always selecting the user’s existing subscription and lets you create/manage subscriptions per organization.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

<!-- gh-comment-id:3133882131 --> @dosubot[bot] commented on GitHub (Jul 29, 2025): <!-- Answer --> This happens because the current logic always selects the first active subscription for a Stripe customer, so if you try to create a new subscription (for another organization, for example), it just reuses the existing one instead of letting you create a separate subscription. To support multiple subscriptions per user (e.g., one per organization), you need to enable organization-level Stripe customers. In your Stripe plugin config, set `createOrganizationCustomer: true`. This makes each organization get its own Stripe customer and subscriptions, so creating a new subscription for a different org won’t conflict with the user’s existing subscriptions. You should also implement the `authorizeReference` function to control which users can manage subscriptions for which organizations. Example config: ```ts stripe({ // ...other options createCustomerOnSignUp: false, createOrganizationCustomer: true, subscription: { // ...other subscription options authorizeReference: async ({ user, referenceId, action }) => { // Check if user is allowed to manage subscriptions for this org // e.g., check membership in your DB return true; // or your own logic }, }, }) ``` When creating or managing a subscription, pass the organization’s ID as `referenceId`. This ensures the subscription is scoped to the org, not the user. If you don’t set up `authorizeReference`, passing a custom `referenceId` will throw an error [see details](https://github.com/better-auth/better-auth/pull/2794). This setup solves the problem of always selecting the user’s existing subscription and lets you create/manage subscriptions per organization. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/1bb551eb-05fb-4991-948a-12809801f6e1?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/1bb551eb-05fb-4991-948a-12809801f6e1?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/1bb551eb-05fb-4991-948a-12809801f6e1?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/1bb551eb-05fb-4991-948a-12809801f6e1?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/1bb551eb-05fb-4991-948a-12809801f6e1?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/1bb551eb-05fb-4991-948a-12809801f6e1?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/1bb551eb-05fb-4991-948a-12809801f6e1?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/3690)
GiteaMirror commented 2026-04-15 16:44:53 -05:00
Author
Owner
Copy Link

@landoncolburn commented on GitHub (Aug 2, 2025):

This response by @dosubot is a hallucination. 'createOrganizationCustomer' doesn't exist in the Stripe plugin.

<!-- gh-comment-id:3146220852 --> @landoncolburn commented on GitHub (Aug 2, 2025): This response by @dosubot is a hallucination. 'createOrganizationCustomer' doesn't exist in the Stripe plugin.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label bug locked
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#18320
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?