#rovarma

1 messages · Page 1 of 1 (latest)

ruby rapidsBOT
late gulch
#

Either would work here. I think it is more up to which UI you want them to work with. I think the Invoice page would allow them to retry just the 3DS auth but otherwise these would be pretty functionally the same

merry ocean
#

Related to this, if the user doesn't complete their payment within 24 hours, the Subscription that was created will transition to incomplete_expired. I haven't tested that case yet, but when that happens, does the subscription continue to be associated with the customer, or does it "disappear" from the customer object?

late gulch
#

Ahem, to be clear the Invoice would allow them to put in a new card or just try the 3DS part, Checkout I think would always require a new payment method input

#

It is still on the customer but is default hidden from the dashboard and list calls

merry ocean
#

Ok, thanks. I asked because docs seem to suggest a new checkout session should be created each time payment is attempted. I wasn't sure if it was "ok" to re-use existing sessions like this

#

Alright, thanks!

#

If the user does pay through the invoice payment link, I assume we would still get the CheckoutSessionCompleted webhooks?

late gulch
#

You can definitely re-use checkout sessions like this if it is for the same payment.

That is a good point, as far as I know CheckoutSessionCompleted won't get triggered in this scenario but InvoicePaid will be triggered for both. I am honestly not 100% sure that the checkout event won't get triggered, if you want you can test this flow in test mode to check what events are sent.

Can you link me to the doc? Happy to suggest we change the wording to our doc team.

merry ocean
#

Thanks! I'll test the webhooks to make sure. I naively thought it would trigger since there is still a checkout session associated with the subscription. If it doesn't trigger CheckoutSessionCompleted, then we'll definitely need to go the reuse-checkout-session-route, as we rely on that event to update our database after payment completes

#

In particular:

"A Checkout Session represents your customer's session as they pay for one-time purchases or subscriptions through Checkout or Payment Links. We recommend creating a new Session each time your customer attempts to pay."

#

I guess it depends on how you interpret "each time your customer attempts to pay" 🙂

late gulch
#

Thank you, yeah that definitely implies a new one per attempt. I will see if we can clarify that a bit better because re-using them is definitely a valid use case

merry ocean
#

makes sense, thanks again for the help!

#

sorry, one more related question. You mentioned that incomplete_expired subscriptions don't show up in list calls. Does that include if I retrieve the Customer object and specify the "subscriptions" property in the expand set?

late gulch
merry ocean
#

thanks! Yeah I was just wondering if the incomplete_expired subscriptions would also be filtered out in this case, but it's fine if not, I can just filter them out on our side

late gulch
#

I am still bouncing around threads at the moment but will try to check this behavior in a moment and get back to you. I think they will be filtered out by default but it may only be subscriptions with a status of canceled

rugged acorn
#

👋 stepping in as Pompey needed to step away