#birdy247-subscription

1 messages · Page 1 of 1 (latest)

misty hull
#

👋 happy to help

opaque sleet
#

Can we use this to confirmSetup ?
Does the latestSetupIntent always come with a subscription?

misty hull
#

Can we use this to confirmSetup ?
yes

opaque sleet
#

Is there always a setupIntent for a subscription?

misty hull
opaque sleet
#

You can use this SetupIntent to collect user authentication when creating a subscription without immediate payment or updating a subscription’s payment method, allowing you to optimize for off-session payments. Learn more in the SCA Migration Guide.

misty hull
#

Is there always a setupIntent for a subscription?
no, only when no payment is needed

opaque sleet
#

Ok cool, so how would we use it to update a payment_method?

#

If the payment fails on the subscription, would we then have a setupIntent if we retrieve the subscription?

misty hull
#

I don't really have an immediate answer for you, I'll try to dig around, but IMO, it will only happen when the subscription is an pending state

opaque sleet
#

Ok, that would be great, thanks

chilly path
opaque sleet
#

const {error, setupIntent} = await stripe.<?= $nextAction['next_action'] ?>({
elements,
confirmParams: {
// Make sure to change this to your payment completion page
return_url: "<?= Router::url(['_name' => 'invoice-items:complete'], true) ?>",
},
redirect: 'if_required'
});

    console.log(setupIntent);
#

We are not getting anything back here

#

scrap that!

#

We are

opaque sleet
#

We have recently moved to webhooks

#

And we find ourselves putting in code in lots of places to check for the status of things, should a webhook not arrive, or not arrive as quickly as we need

#

Are we going overkill here?

chilly path
#

hard to say but it doesn't sound unreasonable to have some robust handling there with extra code

opaque sleet
#

We are doing it in 3 places

#

1/ Webhook listener (ideal)

#

2/ Post checkout complete

#

3/ If they try and revisit checkout again

#

Does these seem overkill?

chilly path
#

it doesn't sound unreasonable to have some robust handling there with extra code

opaque sleet
#

Ok, We will keep going this route and try and consolidate things

#

We have a weird process for charnging multiple stripe accounts which adds lots of overhead

#

i.e. we clone the payment_method and then charge this way

#

My thinking was that in this case, we dont leave the page until the setup intent is returned and we then create the payment_intents on the 2 connected accounts

#

But then this takes us back to the old way of using tokens etc..