#jesper_deferred-intent-subscriptions

1 messages ยท Page 1 of 1 (latest)

strange larkBOT
#

๐Ÿ‘‹ 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/1358822776407851120

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

hallow olive
#

Fwiw I considered using express checkout for payment method collection only, and only then creating the subscription. It seems like that way it doesn't create any invoice unless the payment succeeds. But not really sure whether this is possible at all.

ripe lantern
#

Hi there ๐Ÿ‘‹ I'm not really sure this is avoidable, since you need an intent to process the payment and won't know if the payment will fail until it's attempted.

The alternative that came to mind is to use this approach where you surface the Element first and create the Subscription later:
https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=subscription
(I know this guide shows using the Payment Element, but if I recall correctly that approach works with the Express Checkout Element as well. )

But if the first payment fails, you still have the Subscription and Invoice created by the time the payment is attempted.

hallow olive
#

Hmm I see

#

One thing I tried was adding a 'decline after attach' test card through the dashboard. Then when you create a subscription (also through the dashboard) it just immediately fails. It will show a failed payment but no subscription/invoice.

#

So I was hoping this would work with express checkout as well.

#

The link you sent seems to be what I'm looking for though!

ripe lantern
#

I wouldn't suggest comparing how the dahsobard does things to how your integration will do them, the behavior between the dashboard and API isn't always at parity.

hallow olive
#

Oh shoot haha ok

#

Well maybe voided invoices aren't so bad. But another issue is that we allow guest users to subscribe first and register afterwards. At the moment when an express checkout payment fails, stripe sends an email which allows the user to update their payment method. I'm kind of worried this would enable some nasty edge cases where users end up with multiple subscriptions.

#

So hopefully that approach will prevent the email from being sent. Or at least cause our site to continue with the registration flow as if the payment initially succeeded.

strange larkBOT
hallow olive
#

And it actually seems to work! The api call to create a subscription fails if the payment fails

#

The thing is though, that guide recommends I should use mode: "setup" when configuring stripe elements. But when I do that, the displayed amount is forced to $0

#

However, it seems like if I keep using mode: "subscription" still works just fine.

#

I'm not sure if this is intentional behavior though.

pallid chasm
#

Hi ๐Ÿ‘‹

I'm stepping in as my colleague needs to go.

#

It's not clear to me what the actual question is here (sorry if I'm missing something). Using a deferred intent approach with Stripe elements does offer some additional flexibility but comes with it's own caveats and unique conditions. Can you clarify how you are attempting to use it?

hallow olive
#

So basically my steps right now are:

  • Client creates an express element with mode: "subscription"
  • When the "confirm" event fires, a request is made to our server which:
  • Creates a customer through the API
  • Creates a setup intent using the customer
  • Then once the payment_method.attached webhook event is received:
  • Creates a subscription through the API, causing either one of two things to happen
    • The payment succeeds and a subscription + invoice is created
    • The payment fails, in which case Stripe doesn't seem to create an invoice
#

But my main concern here is that I'm using mode: "subscription" even though that guide recommends I use mode: "setup"

#

Everything seems to work, but I'm kind of worried this is unintentional behavior

pallid chasm
#

Is your intent to create a Subscription for the Customer?

hallow olive
#

Eventually yes, but the setup intent I create using the api never refers to it being for a subscription

#

So to clarify, mode: "subscription" sounds like it was intended to only be used with subscription.latest_invoice.client_secret, whereas mode: "setup" sounds like it's intended for stripe.setupIntents.create()

pallid chasm
#

No

hallow olive
#

But in this case I'm mixing the two, and only creating a subscription after the payment method is attached

pallid chasm
#

Eventually yes, but the setup intent I create using the api never refers to it being for a subscription
So to clarify, mode: "subscription" sounds like it was intended to only be used with subscription.latest_invoice.client_secret

That describes the Intent-first approach. However, if you are using deferred intent that is not the case

hallow olive
#

Hmm ok so in this case using mode: "subscription" is fine?

pallid chasm
#

Yes

hallow olive
#

Alright cool, thanks so much!

pallid chasm
#

Happy to shed what ๐Ÿ’ก I can ๐Ÿ™‚