#derand1_best-practices

1 messages · Page 1 of 1 (latest)

pseudo bloomBOT
#

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

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

charred hornet
#

Hello

#

Is your Connected Account on daily automatic payouts?

surreal wedge
#

I set my connected account payouts to weekly on tuesdays

charred hornet
#

Okay well then yeah you would check if the funds are available on or before Tuesday and that would be the next Payout then

#

There is no API that returns this specifically

surreal wedge
#

Sometimes my users or myself modify the schedule, so displaiyng the next Tuesday isn't the most reliable

#

Sorry I should have added that in the prompt, that's what we have currently

charred hornet
#

Yeah you'll need to check on the current payout schedule of your Connected Account then

#

Like I said, there is no API that indicates the next payout date. Only when funds are available using the Balances API and the Balance Transaction API

surreal wedge
#

So I would calculate it by fetching the Account object's [settings.payouts.schedule]?

#

Is there a timestamp I can use? Or do I have to extrapolate it from the intervals, anchors, etc

charred hornet
#

Correct -- you would use settings.payouts.schedule and then you have to extrapolate.

surreal wedge
#

Got it thank you! That works for me.

I have another question that is pretty unrelated. Should I create another thread or is it okay if i ask you? It's about subscriptions, webhooks, and invoices.

charred hornet
#

Nope you can ask here

surreal wedge
#

Gotcha. So our marketplace model goes like this:

  1. Customer pays upfront (we create a payment intent) and sets a start date for their reservation
  2. Subscription is created (using that payment intent) as a trial that ends on that start date
  3. We hold funds until the subscription trial ends, and their reservation begins.
  4. When 'invoice.created' event is sent to our webhook, we create a new invoice line item to cancel out the amount due (since the customer already paid earlier on) and transfer the customer's original payment to the Host (connect account) to stage for payout.
  5. Finally, we finalize the invoice.

This was written almost a year back and I believe it was to work around some of the limitations of React Native SDK. It's starting to cause problems because we couple a lot of crucial events within a single 'invoice.created'

#

Retries don't really work in the case of transfers failing because Stripe resends the 'invoice.created' event which causes the 'This invoice is no longer editable' error

charred hornet
#

Yeah that doesn't make much sense to me at all

#

First, why use a separate PaymentIntent up front and not just charge the initial amount on the Subscription itself?

#

The simplest thing to do here is to create a Subscription with a trial until the date that you want to start charging and then also add a one-time Price to that Subscription creation which charges for this reservation fee.

surreal wedge
#

Mb, I'm blanking on the reason why we did this in such a confusing way. I recall it being related to not being able to capture funds at the time of creation and holding until the reservation starts.

Can you point me to the doc for adding a one-time price at the time of creation?

charred hornet
#

That said you can still just hold the funds in your platform and transfer them later to your Connected Account (assuming they are in the same region which it sounds like is true based on what you said before)

surreal wedge
#

Ahh yeah, we collect payment method info & use a callback after customers click pay to create a payment intent

#

Then we capture it and use it to create a subscription

charred hornet
#

Is the capture asynchronous?

#

Like why use manual capture here?

#

(That didn't exist a couple years ago so might have been part of the reason you went this route originally, though I do think you still could have accomplished what you wanted with the intent-first flow too)

surreal wedge
#

Oh I just realized why we needed manual capture. It's because we have a 'request' system where our Connected Accounts needed to accept reservations. We didn't want to capture PI's before that and have to deal with refunds.

charred hornet
#

Ah okay yeah that makes more sense.

#

So in that case I would just extend your trial until the first actual billing time. Instead of canceling out the amount on the initial Invoice

surreal wedge
#

That could work, but we use that first invoice to know when to transfer funds to the Connected Account

#

Unless there's something else we can use?

charred hornet
#

Hmm

surreal wedge
#

And we wanted to hold funds until the reservation's start date so we didn't have to deal with debiting the Connected Account if either party decides to cancel

#

Jesus no wonder I blanked out on this. More like I repressed it from the trauma

charred hornet
#

😂

#

Are you billing monthly?

#

You could use the invoice.upcoming Event instead

surreal wedge
#

Both weekly and monthly options 😭

charred hornet
#

Ah then that won't work

#

Well actually, it would work, but would require a lot of logic on your end to handle it

#

Hmm wait no it should be fine

#

Err no no nvm

#

lol sorry thinking through it

#

Would be complex -- would still require a cronjob and what not

#

Would not solve things

surreal wedge
#

Yeah that was my original thought, but didn't want to deal with a cronjob ontop of all that compelxity already

#

Worst case, yeah I can do that. But our current impl. with invoice canceling is probably simplier.

charred hornet
#

Your other option is to use a $0 Price initially

#

So you would put the Sub on trial with a $0 Price. When you receive a customer.subscription.updated Event you would check if the status of the Sub changes from trialing to active. You would then transfer the funds and update the Sub to the $x Price to be charged going forward.

#

That would avoid you handling the invoice.created and having to cancel out things and the complexity there

surreal wedge
#

Hmm that seems pretty good, but I'm worried about a scenario. We let our Host's update their rates for reservations. Let's say the Connected Account update their Price objects before the 'customer.subscription.updated' event, wouldn't that be a problem when trying to set the subscription to $X Price?

charred hornet
#

Not sure what you mean exactly?

#

Can you provide an example scenario?

surreal wedge
#

Yeah, so let's say a Customer reserves @ $100/month using Price Object #1

  1. We capture a payment intent for $100, create a subscription for $0, and save Price Object #1
  2. A few days later, 'customer.subscription.updated' triggers and we transfer funds & update the subscription price using Price Object #1 ($100/month)

What if in between 1 and 2, the Connected Account updates their rates? IIRC, you can't update a Price Object right? You can only delete/disable the old one and create a new one?

charred hornet
#

Sure you can't delete it but that doesn't matter at all. The only thing that matters is the Price of the Sub at the time of the first actual charge.

#

So if during that month the Connected Account changes their rate then you would just update the Sub to the new Price

#

As long as you turn off proration when you do these updates then you can update all you want with no affect on the Sub until the actual billing date.

surreal wedge
#

We only want the new Prices to only apply to future reservations and honor rates at the time of reservation.

#

Unless I'm misunderstanding, this solution would be a problem right?

charred hornet
#

Oh then you would just need to track what the applicable Price is at time of reservation and update to that one.

#

So for instance you could set metadata on the Subscription when created to indicate that

#

Then check that metadata when you update

surreal wedge
#

Oh ok, that's perfectly fine. Would I have to create a new Price object or can I just set an integer? IIRC subscriptions need one to update their Price right?

charred hornet
#

Yeah you would create a new Price object

#

You can't create this inline when updating the Subscription

surreal wedge
#

Sounds like it'll work, thanks! Confusing as hell to document but it'll solve our retries issue.

#

I apprecaite your help