#thatcantberight-portal
ivory wadi
Gotcha. Would it be ok if I described the scenario I'm working with? Maybe there's another way of achieving what I'm going for.
robust summit
sure
ivory wadi
Our site has Users that belong to Teams. User access to site features is determined by their Team's subscription tier. Each tier has a corresponding Product within Stripe. A User can be on multiple Teams. We want Users to be able to manage each Team's subscription independently. This is technically possible via the Customer Portal, but a User belonging to 2 Teams, each at the same feature tier, would have no way of knowing which Team they're about to purchase an upgrade for. e.g. they'd hit the portal and see this:
I've looked into something like instantiating a Portal with a custom Configuration that would only display a subset of Subscriptions, but that doesn't seem to be possible either.
robust summit
yeah the flow you describe is just not something we support unfortunately
I really can't think of a viable solution right now without duplicating every product and price to have the team name 😦
ivory wadi
Roger that. Alternatively, we could configure our models to have a Team <-> Customer relationship, rather than a User <-> Customer relationship. That way, a User on multiple Teams would hit the Portal as a different Customer, per Team. The one clear problem I see with that is users having to input their payment info once per Team/Customer. I'm wondering if that could be mitigated by tracking which of our Users is interacting with the Portal and, if that User is on another Team that already has a Customer, copying the first Team A/Customer A's payment info to the new Team B/Customer B.
I recognize that that may be too hacky to be a good idea
robust summit
yeah that seems net worse as you need to collect card details N times if you do that
and it's hard to measure the value of the customer with revenue recognition and such too
robust summit
sure thing, I'll flag internally too!