#poekie-checkout-id
1 messages ยท Page 1 of 1 (latest)
Hi there ๐ can you share the ID of a checkout session where you saw this behavior?
The thing is, I'm not entirely sure, this is just an error message I'm getting from the server. This has happened only once so far. And as I don't have a session ID, it's hard to relate. But I see only one checkout session completed webhook on the Dashboard for today, so I'm guessing this is the one: evt_1KkyHHBy4su9ppSN44Xpve6j
This is the checkout session itself: cs_live_a1z6Q6r0SHorbkqXtoViQrBE6LJ9cWXTvFPfUcEunnvU8do1ep7J4JNvmU
Was mostly looking to make sure there wasn't a typo, but it looks like the success url is defined correctly.
I'm struggling to think of why you might have encountered that behavior.
What's odd about it, is that the error log message from our server is set to 14:44, but I can't see any events in Stripe that match this
the event that I sent you is from hours ago
I have been working in the Stripe Dashboard the entire day, is there any way that I could have triggered this from the Dashboard?
Nothing comes to mind, but admittedly we focus more on API integrations and aren't terribly familiar with the dashboard.
Just making sure I understand though, it was actual redirect that still had the placeholder value? Disregard, silly question.
Scrolling back in the server log, I do see another attempt at checking out, but it's hard to see whether that process was continued
do you know under what circumstances the CHECKOUT_SESSION_ID is not replaced with an actual session id?
No I don't, this is the first I've heard of it happening.
ok, now what? ๐
Sorry, things are pretty hectic here currently. I would recommend gathering the details that you have and submit a ticket to our support team for further investigation:
https://support.stripe.com/?contact=true
I do see some suspicious activity in Stripe's event log now. A number of checkout sessions appear to have expired. Could that have something to do with it?
and some canceled payments
Expiring checkout sessions is normal, by default they expire 24 hours after creation if not completed.
Ok, yes. So this could not be related to the weird behaviour I'm seeing, correct?
Maybe, maybe not, it's hard to say without being to deep dive into a specific example where this behavior was encountered. I wouldn't expect the Checkout Session to redirect to the success_url after it's expired though.
Things have quieted down a bit, so I'm trying to take a closer look now.
Hm, it is odd that there isn't a corresponding event indicating a checkout session completed successfully.
Is that 14:44 UTC or another timezone?
Also, the redirect has largely been working for you other than this one error from the user navigating to a URL that still had CHECKOUT_SESSION_ID in it?
sorry, back
The plot thickens... I just received another error, and our production server receives a success url, now with session ID cs_test_b1Jwm3AWz19QvNUYACZNtVHP9Ly5QRhS3uIaUTANjewiAfCbZp6swpoHyU, which I assume is an ID that belongs only to test envionments. How is that possible?
Pompey: yes, it has been working so far, although we're running only for a couple of weeks now. So I can't guarantee that there could still be issues left
From the inbound request to your server that still had {CHECKOUT_SESSION_ID}, do you have any additional information in your logs? Particularly do you have the referrer or origin of the request? I'm wondering if maybe someone hit that URL directly rather than it being a redirect from us.
The success_url provided in your creation call appears to be to the same URL https://dashboard.stripe.com/test/logs/req_yupz9u5PfGbn6b
The time is Amsterdam time zone, so UTC+2
I gave you the wrong link one moment
Wait. I am sorry, I was the cause of that error.
Toby: I don't think so, but I will double-check the verbose logs
I tried using your exact URL but I let the redirect go through on my test
The cs_test_b1Jwm3AWz19QvNUYACZNtVHP9Ly5QRhS3uIaUTANjewiAfCbZp6swpoHyU error was from me checking to see if I could repro the URL not being formatted correctly.
phew, ok
Yeah unfortunately I am still not seeing much. As you note, there weren't really checkout sessions created or completed along then.
Is it possible that someone at your company tried going to that URL directly after seeing it in code?
The only thing I can think of on our side is that while browsing data in the Dashboard, I accidentally clicked on a part of the data, and that it happened to be the payment confirmation url. But that's quite far fetched as I was inspecting other data
I will at least see if I can see something in the access logs
Yeah, that may be helpful to check your logs. Would it be possible for you to see if you got redirects for other completed checkout sessions before that one?
checked the access logs. The source IP is not from my machine unfortunately
is there some way I can check if the IP is from Stripe?
Hi ๐ I'm stepping in for @hard mural .
Hi! ๐
We do keep a list of IP addresses Stripe requests will come from here: https://stripe.com/docs/ips
Ok, then it's not a Stripe IP
does that mean the payment confirmation was not sent from Stripe checkout?
is there any way possible that this link is visible somewhere to the outside world?
The redirect URL in your checkout session, correct? (Sorry there's lots of context here)
the success url in the checkout session, yes
Hmmm....I think only the Cancel URL is made public on the Checkout session page.
this is so puzzling
Very much so.
When you say you are seeing suspicious activity, what are you referencing?
I only meant that I saw a series of checkout sessions that expired, I thought that was odd
๐ I'm hopping in since snufkin had to go - give me a few minutes to get caught up
Hi Karbi! I'm a bit unsure if there's anything left to investigate. The summary is: there's an url that is visited that is usually only visited when checkout completes (the success url). However, the url still has the CHECKOUT_SESSION_ID parameter, it has not been converted. Nobody really understands why. After inspecting the access logs, it appears as if the url was not visited from a Stripe server (not a Stripe IP, nor is it an IP from anyone within our company). The IP seems to originate from a far away country :). The puzzling thing is how somebody from the outside world would access the success url directly (and why).
Ahhhh gotcha!
Yeah that really could be anything - I'm not really sure how or why a third-party would come across that link but it sounds like someone just went directly to your success url
yeah, exactly
Perhaps we should leave it at that - puzzling as it sounds
There's not really anyone can do to harm our server that way. It's important though to rule out that there's a bug in the system somewhere. And I'm fairly sure that we can.
Thanks for all the help. I'm keeping a close eye on things and will get back to you if it happens again. Is there a way to reference this thread later?
The thread will be archived if there are no other questions, but you can always come back to reference it, and if you need it to be reopened you just have to ask one of us in the main channel
alright, thanks