#jaba-checkout-redirect
1 messages ยท Page 1 of 1 (latest)
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
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?
yes exactly
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?
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
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?
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 ๐
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.
yep
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! ๐
Glad we could help ๐