#jaba-checkout-redirect

1 messages ยท Page 1 of 1 (latest)

still berryBOT
shadow shale
#

jaba-checkout-redirect

#

@toxic island when you do a form submission, the whole page in the browser "resets" it's like the first time you load a URL. The browser says "hey https://example.com/checkout/session/create tell me what to do" and then your server can be like "well really ignore me, go to that other URL instead"
With axios (or a POST request in general) what the browser does is say "hey https://example.com/checkout/session/create it seems you want to give me some extra data and then some JS code client-side will use it, what's up?" and your server is supposed to respond with say a JSON response like a Checkout Session id and URL and then pass it to your JS code to do something with it

#

So we (Stripe) recommend the former option, because it's way easier to implement. But if you're more familiar with axios all you need to do is have your reserver return the Session's url back and then your client-side code can get that URL and do a redirect to it in Javascript

toxic island
#

Hi Koopajah, thanks for the speedy response and explanation! Just to make sure i've got this right. When I submit a form is that the same as telling the browser to go to https://example.com/checkout/session/create (which can/is later redirected to stripe), along with all the data that's being posted? And that varies to using axios because when using axios the POST request is made from the javascript (rather than the browser doing it). Therefore there's nothing telling the browser to go to that new url, the js just receives whatever is returned from the post request? This is also the reason i get a CORS error because the server is redirecting the post request to another domain?

shadow shale
#

yes exactly

toxic island
#

so in both cases the redirection to stripe is occurring on the client side. just in the first case it's being done by the browser due to the 302 response and in the second case it needs to be handled via js because that's where the request originated from?

shadow shale
#

Kind of. The way I view it, the redirect in the former case happens server-side. Your server says "hey 302 to xxxx please" and the browser follows that decision.

#

it's not completely wrong to think "but the browser redirects so it's client-side" so you're not really off. It's just not how I would have framed it

toxic island
#

with ya, i guess when a requests gets redirected is it actually two requests? one from the original target which responds with "302, try here at xxxx" and a second one to xxxxx? Like the content returned by xxxx doesn't go via the original target that responded with a 302 does it?

shadow shale
#

yes

#

and sometimes, if you have old websites, you get from 302 to 302 to 302

#

Like imagine a blog over the years where every time you move platforms you change your old URLs to redirect to the next one (but you forget to go to the years old blog post so that one goes from domain to domain)

#

but it's more the extreme edge-case ๐Ÿ™‚

toxic island
#

okay great. so a 302 can be thought of as "what you're after isn't here, try again over there", which triggers another request with the same method and params/body etc.

shadow shale
#

yep

toxic island
#

amazing. Thank you so much for clarifying all that for me. I'll go and implement the redirecting in my js clientside as i've got some forms that are being submitted via js. I wasn't sure if that was be best/an okay approach before. You guys provide such an amazing service, every time i've asked a question it gets answered super quickly and really clearly so thank you so much! Have a wicked rest of your day! ๐Ÿ˜„

shadow shale
#

Glad we could help ๐Ÿ™‚