#hendr1x_api
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
๐ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1361422653956686037
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- hendr1x_api, 3 hours ago, 56 messages
- hendr1x_api, 5 hours ago, 8 messages
Hello
Can you elaborate? What do you mean by invalid redirect?
Absolutely.
I was just going to start by saying I talked with toby for a while this morning about this
I'm happy to go over it again...or if you prefer to bring him back whatever is best
Toby isn't around at the moment so a quick summary would be helpful
So high level, confirmPayment + confirmSetup stopped working for my checked when I added a level of abstraction (ie a container class) to the payment system on my site.
So, my checkout is kinda complex
but I'll just start by saying...I'm running the same code as before
if (paymentType && (parseInt(paymentType) === 2 || parseInt(paymentType) === 3)){
var {error} = await xesm.payment.system['stripe'].cache.stripe.confirmPayment({
clientSecret: paymentSecret,
confirmParams: {
//return_url: completeURL,
}
});
} else {
var {error} = await xesm.payment.system['stripe'].cache.stripe.confirmSetup({
clientSecret: paymentSecret,
confirmParams: {
//return_url: completeURL,
}
});
}
if (error){
// This point will only be reached if there is an immediate error when
// confirming the payment. Show error to your customer.
xesm.payment.error("payment.stripe.confirm", "", error);
xesm.redirect(resetURL);
} else {
// Your customer will be redirected to your `return_url`. For some payment
// methods like iDEAL, your customer will be redirected to an intermediate
// site first to authorize the payment, then redirected to the `return_url`.
}
and now what is happening is confirmPayment + confirmSetup is redirecting/reloading my checkout process instead of going to return_url or resetURL
The logs do not show my request going through
(your logs)
an alert directly before the confirmSetup/confirmPayment triggers perfectly
normally return_url is uncommented....sorry...I just tested that..your system returns an error saying return_url is required
I have NO IDEA what is going
I've worked on this all day and have made no movement
Oh yeah....no errors in js at all
(console)
hmm interesting.. Can you throw in a debugger before xesm.redirect(resetURL) gets called?
I just want to mention, when I remove the confirmSetup/Payment code my code runs through/does nothing (as expected) and produces no error
Yeah ok, that doesn't work
the redirect or perhaps its a refresh happens in the confirmSetup/Payment code...nothing after that runs
same goes for alert()
can you add redirect: 'if_required to your confirmPayment function?
https://docs.stripe.com/js/payment_intents/confirm_payment#confirm_payment_intent-options-redirect
My current test is confirmSetup, I assume I can add it there as well
Yup
Ok...that kept me on the page.
I am paused in debugger
Sorry...I'm more a backend developer. Just let me konw what you want need me to do
Thank you so much!
No errors
NP! you can console.log(error) now to look at the error
error = undefined
huh interesting.. that means there's no error..
take out the debugger and try re-running the code..
you shouldn't be redirected
Ok...no redirect now
but the code seems to do nothing
I'm 99% sure has something to do with promises
Check your network console. There must be some network error..
You can also check for failed requests on Stripe - https://support.stripe.com/questions/finding-the-id-for-an-api-request
Can you share the SetupIntent ID you're working with in your tests?
{
"id": "seti_1RDswkCTw3MsNtCvuZbDsSZs",
"object": "setup_intent",
"automatic_payment_methods": {
"enabled": false
},
"cancellation_reason": null,
"client_secret": "seti_1RDswkCTw3MsNtCvuZbDsSZs_secret_S89FntjnDB7EY0WYQz2sEgU7y2hVEgc",
"created": 1744659934,
"description": null,
"last_setup_error": null,
"livemode": false,
"next_action": null,
"payment_method": "pm_1RC4YsCTw3MsNtCvCKY8etJ3",
"payment_method_configuration_details": null,
"payment_method_options": {
"us_bank_account": {
"verification_method": "automatic"
}
},
"payment_method_types": [
"card",
"us_bank_account"
],
"status": "succeeded",
"usage": "off_session"
}
That is the response from
So the request succeeded then?
This is in my network tab
Your code only checks for error and redirects
๐ stepping in here
That SetupIntent you just shared did not have any redirect performed.
It moved directly to succeeded upon confirmation.
Ah sorry one sec ๐
Thought you were setting redirect: 'if_required' but that's not the case.
Okay so let's back up.
Thats what is in place right now on hanzos request
If I pull that out...I am getting a redirect (or refresh I can't tell) which is coming directly from you setupPayment/Intent....but its not the return_url I pass.
What URL are you directed to? Is there somewhere I can reproduce this?
and, based on my research with toby this morning...your logs never see it
if you are willing to spend a moment logging into an account and adding an item to your cart we can reproduce this pretty easily
I didn't confirm that this afternoon
I just pasted above a 200 confirm response from you api
So I have no idea why it wouldn't be in your logs
Yeah...I don't see them now...I might be checking the wrong spot I guess
I'm not sure what you mean by "it wouldn't be in your logs"... like our logs show that we successfully redirected you to your designated return URL. But if you are ending up on a different URL then I'd suspect some sort of redirect occurring from the designated return URL when sent there.
But all hard to say without more information
I'm happy to go reproduce if you give me instructions
does the logs say you are redirect me to the return url?
I can't find that in my logs in the dashboard
This was working fine a couple days ago and all I changed was javascript code
The 200 for the SetupIntent confirmation request indicates that would be the behavior.
Yes changing any sort of client-side code could change the behavior... I'm not sure why that would be unexpected.
(this is all testing, you can do anything you want without restriction)
Went ahead and deleted those since this is a public server
add one shirt to cart
go through checkout
shipping should all be prefilled for you -> button on right "continue checkout"
payment page, select one of the saved payment methods
everything we are doing is on the confirm page
So, unfortunately the path is complicated to get there but...let me start you at the setupIntent/Payment code
So...when you click "Complete Order"
it runs
confirmComplete()
redirect: 'if_required' is still there
so it should just stay on the page
if I remove that (as it was prior) then your code produces a redirect
but it just goes to my checkout
not the return_url or the errorURL
Yep can you remove redirect: 'if_required' so I can repro the redirect
K one sec
Okay so there is a 302 that occurs which does redirect to:
https://dev.winecellar.com/checkout/complete/?setup_intent=seti_1RDtE7CTw3MsNtCvtoOP0qkl&setup_intent_client_secret=seti_1RDtE7CTw3MsNtCvtoOP0qkl_secret_S89XsQl0HRA77ulbBCvBjUk5kU4DzmI&redirect_status=succeeded
Which is indeed your set returnUrl. However, then there is an immediate 200 GET request to https://dev.winecellar.com/checkout/ which would generally occur from a re-render or page refresh. This is coming from your own code though, this isn't happening due to our redirect -- we are redirecting you to your returnURL as is indicated from the 302.
You can see this all in the network requests of your browser if you want to take a look from your side.