#lil-subscription-basicbuild

1 messages · Page 1 of 1 (latest)

tacit kernelBOT
toxic sable
#

An invoice payment does not necessarily attach a payment method, no. For example if it's used only as a once time payment.

strong chasm
#

What if the invoice is attached to a subscription?

#

Read the thread I attached please... it's a few messages

#

Or re-open it if you don't mind

toxic sable
#

I can see it, but I'm not understanding how that maps to your new question

#

What exactly are you trying to do? A single flow, for example. Since you described multiple flows in the previous thread. Which are you trying to work on now?

strong chasm
#

I'm thinking that instead of listening for the setup_intent.succeeded event I would simply listen for payment_method.attached event and can have the same flow for both

#

That way when I have a user retryt the payment on the invoice w/ a new method I can then use that pm to update the subscription and the customers pms

#

We're enforcing a single pm in our system and so I want to remove all the other saved PMs whenever there's a new method added.

tacit kernelBOT
toxic sable
#

I think your setup_intent.succeeded approach is better/more explicit then, if that's the route you went for collecting new payment details

strong chasm
#

But would the subsequent invoice payment trigger payment_method.attached to fire?

toxic sable
#

Not necessarily, no

strong chasm
#

Is there a way to cause it to?

#

I just did a setup intent with a sepa_debit and the payment_method.attached event had a diff pm_id than the setup_intent.succeeded event

safe flicker
#

Are you looking to make it trigger the first time the payment is made? Or are you asking about triggering it for each recurring payment. It is only attached when it is initially saved so I think the event would only be expected to fire then

strong chasm
#

I'm wondering if it will be fired when there's a retry on a failed payment invoice

safe flicker
#

An automatic retry, or the user manually inputting a new payment method after their first attempt failed?

strong chasm
#

Like this User submits bank payment => invoice processes => payment fails => get client_secret to retry => user puts in new PM & submits => now does payment_method.attached fire?

#

Note the invoice is attached to a subscription

safe flicker
#

I believe so. If you test that scenario in test mode it will confirm for sure if it is fired

strong chasm
#

What I'm thinking is that if it does I will simply disregard setup_intent.succeeded in favor of payment_method.attached.

This way if the user is making a simple update or retrying a failed payment for a subscription's invoice both of them will trigger the pm.attached so I can delete all the payment methods aside from that new one

#

Would that be a sensible flow?

safe flicker
#

Yes if that event is triggered that makes sense as a way to ensure the user only has one payment method

strong chasm
#

Perfect, thanks

#

Would the proper way to retrieve the invoice payment intent that failed be to go down the subscription route and get the invoice's payment_intent client_secret and then use that in the payment element?

tacit kernelBOT
safe flicker
#

Yes, that is how you can confirm the subscription's first intent on your own custom page

gloomy elm
#

lil-subscription-basicbuild