#ben_webhooks

1 messages ¡ Page 1 of 1 (latest)

vernal mauveBOT
#

👋 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/1298253396993642518

📝 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.

native ledge
#

hi there!

#

yes there is a limit to the number of webhooks you can create

#

is it perfectly fine to have 40 events tied to one endpoint?
yes you can have one endpoint listening to as many events you need

ornate forge
#

OK, so it isnt preferable to split them out per type or anything?

native ledge
#

since we limit the number of enpoint you can create, I would say it's better to have one endpoint listening to many events that many endpoint listening to a few events each.

ornate forge
#

Perfect, that answers my question then!

I have an unrelated question for API, do you want me to open a fresh request?

native ledge
#

feeel free to ask it here

ornate forge
#

OK thanks.

We are allowing our users to create complex products in our platform, then are then created in stripe. We are letting them do this witjh the intention of applying schedules to subscriptions when they sell a subscription product to their customer.

For example, first 3 months is $500 then $150pm for 3 months with end_behaviour release.

To do this we are creating a schedule object in our DB with a related phases array. Obviously at the point of product creation the schedule does not exist in stripe. We hold some of it in meta but it is all in our backend.

They can tehn sell this product to people.

From what I understand we cannot generarted a checkout session that sells a schedule, as a schedule is something that is either created in the dashboard and subsequrntly creates a subscription through it, or it can be. done via hte API. But checkouts only support subscriptions and one time charges.

How can we faciliate this type of product being sold?

native ledge
#

From what I understand we cannot generarted a checkout session that sells a schedule,
correct. if you want to use Checkout Session, it will create a regular Subscription. but then you can convert the existing subscription into a Schedule if needed.

ornate forge
#

OK, so to facilitate what we want to do, we would need to create a checkout session based on the first price referenced in the phaser array, then on succesful purhcase and receipt of the hook, do some checks and apply a schedule?

native ledge
#

yep. or don't use Checkout Session at all, and instead directly create the Subscription Schedule and collect a payment method with the Payment Element. Up to you!

ornate forge
#

To do the latter though, we would need to still send some form of checkout to the customer that uses the payment element to collect a payment method?

So its either a checkout session, let stripe do the heavy lifting and deal with it in the hooks

or

Build a custom check out of sorts, setup the schedule with no payment method initially, and then send the end customer a link to a secure 'custom checkout' to collect their paymnet?

native ledge
#

correct

ornate forge
#

OK, do we have any control over what we could show the buying customer with the standard checkout? So they know they are actually buying a product that will run for X time in Y stages?

native ledge
ornate forge
#

Good point, I will have to have a play with that.

I dont have an issue with custom check out as we have one in app for our paying customers, but thats behind a login wall. For the scenario above this is to the custoemrs of our customers, so for all intense and purposes would be a public checkout that grabs the 'basket' info with an id from our backend. I suppose the elements are secure but something still makes me nervous there!

native ledge
#

I'm not sure I understand the concern here.

ornate forge
#

I suppose in a round about way i am saying, is there any issue with putting the payment elements on a page that is essentially public to collect card information

native ledge