#CaptainYarb-pendingupdate-sub

1 messages ยท Page 1 of 1 (latest)

proper bobcat
#

hello, can you share the example request you're making, so I can understand?
I think you might need to give a trial but not sure

mental nebula
#

Jon stepped away for a moment, but we're effectively trying to call this: https://stripe.com/docs/api/subscriptions/update, with some updated items, proration_behavior, and payment_behavior: pending_if_incomplete, but prevent the invoice is creates from being automatically charged.

Although I just saw collection_method.. so maybe we can set that to send_invoice and the prorated invoice will be created but not attempted to be charged?

#

That will update the entire subscription though I think, meaning subsequent renewals won't be auto-billed? Hmm ๐Ÿค”

proper bobcat
#

I'm not fully understanding the scenario, which is why I said that seeing an example would help me understand

fervent lance
#

We are effectively wanting to replicate the payment_behavior: 'default_incomplete' behavior we see when creating the subscription, but want the update to be pending until payment is completed.

shrewd walrus
#

๐Ÿ‘‹ Hopping in - is there a reason you don't want the payment to be automatically collected?

fervent lance
#

Much like when we create the subscription we want to verify that the user intends to pay with the selected payment method. We also offer other payments out of bound which won't play nicely.

#

This is also the only part of our billing which doesn't immediately get a Payment Intent as the update request may also charge them.

shrewd walrus
#

I see - so you're kind of looking for a mix of behavior that combines pending_if_incomplete with default_incomplete (which doesn't attempt payment immediately)

shrewd walrus
#

Justin checking in @fervent lance - is my read on what you're trying to accomplish right?

fervent lance
#

That's correct! ๐Ÿ™‚

shrewd walrus
#

Ultimately, there isn't really a way to get the exact behavior you want with pending_if_incomplete since it will always attempt payment immediately as part of the update request. If they want to switch Payment Methods, you can always take the Invoice/PI and attempt payment again with a new Payment Method until the pending update expires after 23/24 hours

fervent lance
#

Dang, that's really not an ideal solution for us. ๐Ÿ˜ฆ

shrewd walrus
#

Yeah there are some definite gaps in pending updates that make them hard to use with all use cases - is using pending updates a hard requirement for you?

fervent lance
#

Because we're dealing with use content for smaller charges, yes. This is really important for how we implement changes like this. We're having to spend a ton of extra engineering time around this :/

shrewd walrus
#

Can you clarify what you mean by "use content for smaller charges"?

fervent lance
#

consent**

#

sorry

shrewd walrus
#

Personally, if needing user consent is a hard requirement before you continue charging for the update then I'd go with default_incomplete instead since that's the only payment_behavior that will not synchronously attempt payment during the update.

#

I need to head out, but if you need anything else @proud mural can help