#mel_api

1 messages · Page 1 of 1 (latest)

arctic elbowBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1342513429298286734

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

storm totem
#

Entitlements won't distinguish between different subscriptions. As long as there's a subscrition active with a certain feature, then the entitlement will be active on the customer

arctic elbowBOT
jaunty jasper
#

hmm that's such a shame. I think that kind of rules out the option of using Entitlements for us

#

I'll have to rethink our integration

tardy lark
#

So if the customer has two subscription with two features, you can look at the lookup_key, no?

jaunty jasper
#

I'm not sure the lookup_key will help here.
As an example, we may have a customer who has 2 Subscriptions. One subscription may have an add-on enabled (e.g. lookup_key= custom-domain), and the other may not. If I look for entitlements for this customer with this lookup_key, there is no way to know which Subscription (and therefore which community) their custom domain add-on applies to.

#

I was hoping to have a Product for the Basic Plan, then add-on products that the user can add/remove themselves in the Customer Portal.

#

I think what you're suggesting is to instead have a unique subscription for each add-on product (feature) - is that right?

#

But even if I did that, they would still have duplicate lookup_key values across their multiple subscriptions for their 2 communities

#

Not sure if that makes sense?

#

It's a similar product structure to having a single Meetup Organiser account, running more than one Meetup and paying for each separately, with different add-ons for each.

tardy lark
#

I was assuming you had separate features for each product.

#

It more sounds like you have one product

jaunty jasper
#

Yes, outside of Stripe it's one product with optional add-ons.

Base subscription - access to our AI Assistant for a Community Group
Add on e.g. 1 - add a custom domain for that group

#

So I was originally planning to create a Stripe Product for each of the above, each connected to a Feature

tardy lark
#

I see. I was assuming that you'd have separate products, and you'd attach the feature to that product: https://docs.stripe.com/api/product-feature

Hence, I thought you would be able to use that lookup_key property.

Stripe API Reference

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

#

Let me think what might work for your setup

jaunty jasper
#

Thank you 🙏

tardy lark
#

So I was originally planning to create a Stripe Product for each of the above, each connected to a Feature

This would work, you can use the lookup_key in this case.

jaunty jasper
#

But if the customer has 2 subscriptions:

Sub 1 for Group 1:
AI Assistant Product

Sub 2 for Group 2:
AI Assistant Product

  • Custom Domain

Then surely a List Entitlements call for this customer would simply list:
AI Assistant Product, Custom Domain

And we wouldn't know which Group to apply the Custom Domain Entitlement to

tardy lark
#

What do you mean by 'which Group to apply the Custom Domain Entitlement to'?

jaunty jasper
#

The user has 2 meetup groups in our app, each paid for separately in its own subscription. EG Group 1 is a book club, Group 2 is a networking group.

#

They have paid extra for the custom domain add-on for their networking group, but not for their book club

#

Like having 2 workspaces you manage in Slack

#

If there was a way to force a unique Stripe Customer ID even for users with the same email address, that could work

tardy lark
#

I think this might work. You have two products, AI Assistant Product and AI Assistant Product+ Custom Domain.

Then, you create separate features, and use the metadata, https://docs.stripe.com/api/entitlements/feature/create#create_entitlements_feature-metadata to identify the group. You then map these in your database as well.

Finally, you can list all active entitlements: https://docs.stripe.com/api/entitlements/active-entitlement/list which will surface the feature id, where you can look in your database and identify which group to apply it to.

#

You can create a unique customer by an email. You would need to keep track of these on your end, and only create the customer if that email address is not there, https://docs.stripe.com/api/customers/create. Otherwise, you retrieve the existing customer.

jaunty jasper
#

I'm not sure I understand the middle step. Are you suggesting:

  1. Create a Feature for AI Assistant, and another Feature for "AI Assistant + custom domain"?
  2. How would we identify the group in metadata? Do you mean we'd need to create a unique feature for every single group?
#

Could you illustrate with a worked example, perhaps?

tardy lark
#

Create a Feature for AI Assistant, and another Feature for "AI Assistant + custom domain"?

Yes!

How would we identify the group in metadata? Do you mean we'd need to create a unique feature for every single group?

When they sign up, you now which group right? You have 2 groups, you create 4 features. You will create two products: AI Assistant Product and AI Assistant Product + Custom Domain. When you create the features, you will pass in the metadata to identify the group:

{metadata: {'group':'1'} }

You then, map these features in your database. When you list all active entitlements: https://docs.stripe.com/api/entitlements/active-entitlement/list you get the feature id. You look at your own database, and identify which group it belongs to so you can separate the entitlements on the customer.

jaunty jasper
#

Right, so we'd need to create a new Feature in Stripe every time a new user (Group) signs up and creates a Subscription.

Then we'd need to maintain our own mapping of features to groups in our database anyway.

And then if they wanted to upgrade or downgrade using the Customer Portal, they would need to change product. And then we'd need to update everything, and maybe even create a new Feature?

It feels... messy. And potentially more confusing than not using Entitlements at all.

tardy lark
#

Your example only mentioned two groups hence, I was trying to come up with a workaround. Yeah, this is not scalable in the long term.

jaunty jasper
#

Ha yeah. Have we accidentally landed on a rare pricing model?

tardy lark
#

Ha!

#

I mean if there were only two groups, it would have worked.

jaunty jasper
#

well, yes

#

I think I need to go back to the drawing board. Thanks for trying to brainstorm with me

tardy lark
#

Sure

jaunty jasper
#

Just to double check, you can't create 2 different Stripe Customers with the same email address?

tardy lark
#

No, you can.

jaunty jasper
#

You can? Okay. So the only unique identifier is the Customer ID?

tardy lark
#

Yes

jaunty jasper
#

So is there a way to send a user to their Customer Portal for a specific Customer ID?

#

(rather than just based on them entering an email adress and getting emailed a magic login link, which could send them to either)

tardy lark
jaunty jasper
#

Perfect!
I think that's what I'll do. I don't think our users will care if they can't see their different subscriptions together in one portal, we can just send them to the right one for each of their Groups. Then that means I can use Entitlements per Customer ID as it's designed.

#

Hooray! Solved it 🙌
Thanks again