#wsteelix-sepa-ideal-setup-pe

1 messages ยท Page 1 of 1 (latest)

cursive whale
#

Hi there ๐Ÿ‘‹ can you share the ID of a Setup Intent where you saw this behavior?

gritty rampart
#

hi, here is one: seti_1LFI8jLiXZrLhRYlWps8UvWL

#

here is how i'm currently call confirmSetup: const { setupIntent, error } = await stripe.confirmSetup({ elements, redirect: 'if_required', confirmParams: { return_url: window.location.href, // This is required onSubmit as we hid Country drop down from the form payment_method_data: { billing_details: { address: { country, }, }, }, }, })

cursive whale
gritty rampart
#

hmmm... but it did return the successful setupIntent object in case 'card' was the only payment method ๐Ÿค”

#

i'm wondering if there's something wrong with my setup regarding the redirect.. lemme try again and see if I can get the error or not from failed authorization

#

alright, I don't seem to get any error back either

#

so whatever happens, it seems that confirmSetup will just append the result to the end of the return_url, and doesn't run any further code once it has been resolved..

#

that makes me wonder if I'm doing something wrong with the return_url and/or redirect setup here ๐Ÿค”

cursive whale
#

What is it that you're trying to do on the frontend with that information after the confirmation?

gritty rampart
#

if there is error, then I would handle it by displaying a custom message to customers based on the type of the error

#

if the setupIntent was successful (and I got the setupIntent back), then I will use the payment_method attached to the setupIntent to create a subscription

cursive whale
#

Hm, can you try using the .then() structure to catch the entire result of the confirmSetup function and then review everything that the function is returning?

gritty rampart
#

hmmm.. couldn't seem to get anything out of that either. I think it's most likely due to the redirect nature of this payment method, hence the page is always re-rendered upon the promise resolves, and I just cannot catch anything on the front end anymore ๐Ÿค”

#

so basically: customer fill in the payment form -> click subscribe button -> we try to call confirmSetup -> with the form content -> customer got redirected to another page to authorize -> customer completes the authorization -> get redirected back to the return url as setup above, but at this point, the page is already re-rendered -> nothing returned from the initial confirmSetup promise is accessible anymore

cursive whale
#

My teammate is taking over handling the channel, so I'm going to focus on this more closely and go do some testing.

gritty rampart
#

sure. thanks a lot! ๐Ÿ™

#

the above setup has worked well with card for us, but then I haven't found a way to get it working fully with bank redirect options

#

please take your time. i'll be heading off now as I'm already over time. Just leave your messages here if you find something. I'll get back at it tomorrow. Thanks a lot for helping!

#

and have a good day/evening! ๐Ÿ™‡โ€โ™‚๏ธ

cursive whale
#

So it looks like you were spot-on with the whole-page redirect being the limiting factor here. Because of this, we rely on query params appended to the return_url to relay information back to your pages.

Based on my testing, there are three params that are appended to that URL which your site can consume:

  • redirect_status - indicates whether the redirect/authentication was completed successfully
  • setup_intent - contains the ID of the Setup Intent
  • setup_intent_client_secret - contains the client secret of the Setup Intent

You can use these to retrieve the associated Setup Intent to confirm what state it is in