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

[GH-ISSUE #6075] Make Stripe Plugin More Generic to Support Connect and Other Use Cases #19046

New Issue
Open
opened 2026-04-15 17:49:38 -05:00 by GiteaMirror · 8 comments
GiteaMirror commented 2026-04-15 17:49:38 -05:00
Owner
Copy Link
Copy Source

Originally created by @AntonVishal on GitHub (Nov 18, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/6075

Originally assigned to: @bytaesu on GitHub.

Is this suited for github?

  • Yes, this is suited for github

Is your feature request related to a problem? Please describe.

The current Stripe plugin is tightly coupled to subscription management use cases. While this works well for SaaS applications with billing models, it excludes other important Stripe features like Stripe Connect (marketplace/payment distribution), one-time payments, invoice management, and other payment workflows.

Describe the solution you'd like

Split the plugin into feature modules that users can opt into:

stripe({
    features: {
        subscriptions: {
            enabled: true,
            plans: [...],
            // subscription-specific config
        },
        connect: {
            enabled: true,
            accountType: "standard" | "express" | "custom",
            // connect-specific config
        },
        payments: {
            enabled: true,
            // one-time payment config
        },
        invoicing: {
            enabled: true,
            // invoice config
        }
    }
})

Support multiple entity types and relationships:

stripe({
    entityAssociation: {
        user: {
            stripeId: "stripeCustomerId",
            type: "customer" // or "connect_account"
        },
        organization: {
            stripeId: "stripeConnectAccountId",
            type: "connect_account"
        },
        marketplace: {
            stripeId: "stripeConnectedAccountId",
            type: "platform_account"
        }
    }
})

Provide a cleaner hook system for different features:

stripe({
    hooks: {
        // Subscription hooks (existing)
        subscription: {
            onCreated: async (data) => { /* */ },
            onUpdated: async (data) => { /* */ },
            onCanceled: async (data) => { /* */ }
        },
        // Connect hooks
        connect: {
            onAccountCreated: async (data) => { /* */ },
            onPayoutPaid: async (data) => { /* */ },
            onVerificationUpdated: async (data) => { /* */ }
        },
        // Payment hooks
        payment: {
            onSucceeded: async (data) => { /* */ },
            onFailed: async (data) => { /* */ }
        }
    }
})

Describe alternatives you've considered

This is something new to BA, so let the maintainers decide.

Additional context

No response

Originally created by @AntonVishal on GitHub (Nov 18, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/6075 Originally assigned to: @bytaesu on GitHub. ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. The current Stripe plugin is tightly coupled to subscription management use cases. While this works well for SaaS applications with billing models, it excludes other important Stripe features like Stripe Connect (marketplace/payment distribution), one-time payments, invoice management, and other payment workflows. ### Describe the solution you'd like Split the plugin into feature modules that users can opt into: ``` stripe({ features: { subscriptions: { enabled: true, plans: [...], // subscription-specific config }, connect: { enabled: true, accountType: "standard" | "express" | "custom", // connect-specific config }, payments: { enabled: true, // one-time payment config }, invoicing: { enabled: true, // invoice config } } }) ``` Support multiple entity types and relationships: ``` stripe({ entityAssociation: { user: { stripeId: "stripeCustomerId", type: "customer" // or "connect_account" }, organization: { stripeId: "stripeConnectAccountId", type: "connect_account" }, marketplace: { stripeId: "stripeConnectedAccountId", type: "platform_account" } } }) ``` Provide a cleaner hook system for different features: ``` stripe({ hooks: { // Subscription hooks (existing) subscription: { onCreated: async (data) => { /* */ }, onUpdated: async (data) => { /* */ }, onCanceled: async (data) => { /* */ } }, // Connect hooks connect: { onAccountCreated: async (data) => { /* */ }, onPayoutPaid: async (data) => { /* */ }, onVerificationUpdated: async (data) => { /* */ } }, // Payment hooks payment: { onSucceeded: async (data) => { /* */ }, onFailed: async (data) => { /* */ } } } }) ``` ### Describe alternatives you've considered This is something new to BA, so let the maintainers decide. ### Additional context _No response_
GiteaMirror added the payments label 2026-04-15 17:49:38 -05:00
GiteaMirror commented 2026-04-15 17:49:40 -05:00
Author
Owner
Copy Link
Copy Source

@better-auth-agent[bot] commented on GitHub (Nov 18, 2025):

Hi there! Thanks for opening this issue. We understand you’d like to see the Stripe plugin made more generic, so it’s not limited to subscription management only but can also support features like Connect accounts, one-time payments, invoicing, and other payment workflows. Your suggestion to split the plugin into separate feature modules and provide a cleaner hook system makes sense for adapting to different use cases.

Next steps would be to review how we could modularize the existing Stripe integration while ensuring smooth backwards compatibility with current subscription flows. Our team will evaluate this enhancement and consider community feedback to prioritize work on this feature. In the meantime, could you share any additional specific use cases or examples of workflows you have in mind? tag @better-auth-agent if you would like an answer from the Agent.

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3549052588 --> @better-auth-agent[bot] commented on GitHub (Nov 18, 2025): Hi there! Thanks for opening this issue. We understand you’d like to see the Stripe plugin made more generic, so it’s not limited to subscription management only but can also support features like Connect accounts, one-time payments, invoicing, and other payment workflows. Your suggestion to split the plugin into separate feature modules and provide a cleaner hook system makes sense for adapting to different use cases. Next steps would be to review how we could modularize the existing Stripe integration while ensuring smooth backwards compatibility with current subscription flows. Our team will evaluate this enhancement and consider community feedback to prioritize work on this feature. In the meantime, could you share any additional specific use cases or examples of workflows you have in mind? tag @better-auth-agent if you would like an answer from the Agent. <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
GiteaMirror commented 2026-04-15 17:49:41 -05:00
Author
Owner
Copy Link
Copy Source

@bytaesu commented on GitHub (Dec 11, 2025):

Thank @AntonVishal, I'm looking into this

<!-- gh-comment-id:3641177275 --> @bytaesu commented on GitHub (Dec 11, 2025): Thank @AntonVishal, I'm looking into this
GiteaMirror commented 2026-04-15 17:49:41 -05:00
Author
Owner
Copy Link
Copy Source

@AntonVishal commented on GitHub (Dec 11, 2025):

Cool @bytaesu , whenever you start begin with stripe connect!

<!-- gh-comment-id:3642014349 --> @AntonVishal commented on GitHub (Dec 11, 2025): Cool @bytaesu , whenever you start begin with stripe connect!
GiteaMirror commented 2026-04-15 17:49:42 -05:00
Author
Owner
Copy Link
Copy Source

@maxvaljan commented on GitHub (Jan 12, 2026):

Hi will there be support for stripe connect?

<!-- gh-comment-id:3737551523 --> @maxvaljan commented on GitHub (Jan 12, 2026): Hi will there be support for stripe connect?
GiteaMirror commented 2026-04-15 17:49:42 -05:00
Author
Owner
Copy Link
Copy Source

@ethan-huo commented on GitHub (Feb 26, 2026):

@bytaesu Are there any updates? This feature is very important.

<!-- gh-comment-id:3967778337 --> @ethan-huo commented on GitHub (Feb 26, 2026): @bytaesu Are there any updates? This feature is very important.
GiteaMirror commented 2026-04-15 17:49:43 -05:00
Author
Owner
Copy Link
Copy Source

@bytaesu commented on GitHub (Mar 9, 2026):

Right now everything is built around Subscriptions, and since Connect is a completely separate concept, supporting it would likely require significant structural changes.

If there's strong demand we could consider it, but it's not a high priority at the moment. For now we're focusing on improving Subscriptions so they can cover more flows.

<!-- gh-comment-id:4025666668 --> @bytaesu commented on GitHub (Mar 9, 2026): Right now everything is built around Subscriptions, and since Connect is a completely separate concept, supporting it would likely require significant structural changes. If there's strong demand we could consider it, but it's not a high priority at the moment. For now we're focusing on improving Subscriptions so they can cover more flows.
GiteaMirror commented 2026-04-15 17:49:43 -05:00
Author
Owner
Copy Link
Copy Source

@bytaesu commented on GitHub (Mar 9, 2026):

I mean, it's nice to have, but it requires heavy work, so it's not a high priority.

<!-- gh-comment-id:4025673279 --> @bytaesu commented on GitHub (Mar 9, 2026): I mean, it's nice to have, but it requires heavy work, so it's not a high priority.
GiteaMirror commented 2026-04-15 17:49:43 -05:00
Author
Owner
Copy Link
Copy Source

@ttmachado commented on GitHub (Apr 4, 2026):

I have another use case that could benefit from making this more flexible.

I manage organizations internally and use referenceId for subscriptions. With this approach, the user is still the customer but ideally it should be the organization.

Looking at the current implementation, I think most of the pieces are already there and just need to be slightly generalized so customer creation isn’t tied only to users or requiring the organization plugin.

authorizeReference(user, referenceId)

  • Works great as is.

getCustomerCreateParams(user, ctx)

  • Currently this only runs on user creation. It would be much more flexible if it also ran anywhere a customer can be created (e.g. first subscription, upgrade, etc.), optionally receiving the referenceId.
    This would allow resolving the correct entity (like an organization) at the moment a customer is actually needed and returning customized params accordingly.

onCustomerCreate({ stripeCustomer, user }, ctx)

  • Same limitation. It currently only runs on user creation but should run everywhere getCustomerCreateParams runs.
    This would make it possible to use metadata or context to link the stripe customer to the correct internal entity (e.g. an organization) and persist it accordingly.
    It would also require returning something like skipDatabaseUpdate so the plugin doesn’t automatically attach the customerId to the user when it’s already been handled manually.

Bonus: a disableUserCustomer, requireReferenceId property or hook to block any attempt of interacting with the plugin without using a referenceId.

With these changes, the plugin could support user-based, organization-based, and fully custom ownership models without requiring the organization plugin, while keeping the existing behavior intact.

<!-- gh-comment-id:4187738464 --> @ttmachado commented on GitHub (Apr 4, 2026): I have another use case that could benefit from making this more flexible. I manage organizations internally and use referenceId for subscriptions. With this approach, the user is still the customer but ideally it should be the organization. Looking at the current implementation, I think most of the pieces are already there and just need to be slightly generalized so customer creation isn’t tied only to users or requiring the organization plugin. `authorizeReference(user, referenceId)` - Works great as is. `getCustomerCreateParams(user, ctx)` - Currently this only runs on user creation. It would be much more flexible if it also ran anywhere a customer can be created (e.g. first subscription, upgrade, etc.), optionally receiving the _referenceId_. This would allow resolving the correct entity (like an organization) at the moment a customer is actually needed and returning customized params accordingly. `onCustomerCreate({ stripeCustomer, user }, ctx)` - Same limitation. It currently only runs on user creation but should run everywhere `getCustomerCreateParams` runs. This would make it possible to use metadata or context to link the stripe customer to the correct internal entity (e.g. an organization) and persist it accordingly. It would also require returning something like skipDatabaseUpdate so the plugin doesn’t automatically attach the customerId to the user when it’s already been handled manually. --- **Bonus:** a disableUserCustomer, requireReferenceId property or hook to block any attempt of interacting with the plugin without using a referenceId. With these changes, the plugin could support user-based, organization-based, and fully custom ownership models without requiring the organization plugin, while keeping the existing behavior intact.
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 labels payments
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#19046