#poekie-checkout-id

1 messages ยท Page 1 of 1 (latest)

molten linden
#

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

naive hatch
#

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

molten linden
#

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.

naive hatch
#

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?

molten linden
#

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.

naive hatch
#

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?

molten linden
#

No I don't, this is the first I've heard of it happening.

naive hatch
#

ok, now what? ๐Ÿ™‚

molten linden
#

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

naive hatch
#

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

molten linden
#

Expiring checkout sessions is normal, by default they expire 24 hours after creation if not completed.

naive hatch
#

Ok, yes. So this could not be related to the weird behaviour I'm seeing, correct?

molten linden
#

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.

hard mural
#

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?

naive hatch
#

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

molten linden
#

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.

hard mural
naive hatch
#

The time is Amsterdam time zone, so UTC+2

hard mural
#

I gave you the wrong link one moment

#

Wait. I am sorry, I was the cause of that error.

naive hatch
#

Toby: I don't think so, but I will double-check the verbose logs

hard mural
#

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.

naive hatch
#

phew, ok

hard mural
#

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?

naive hatch
#

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

hard mural
#

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?

naive hatch
#

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?

bleak yacht
#

Hi ๐Ÿ‘‹ I'm stepping in for @hard mural .

naive hatch
#

Hi! ๐Ÿ™‚

bleak yacht
naive hatch
#

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?

bleak yacht
#

The redirect URL in your checkout session, correct? (Sorry there's lots of context here)

naive hatch
#

the success url in the checkout session, yes

bleak yacht
#

Hmmm....I think only the Cancel URL is made public on the Checkout session page.

naive hatch
#

this is so puzzling

bleak yacht
#

Very much so.

bleak yacht
#

When you say you are seeing suspicious activity, what are you referencing?

naive hatch
#

I only meant that I saw a series of checkout sessions that expired, I thought that was odd

ashen depot
#

๐Ÿ‘‹ I'm hopping in since snufkin had to go - give me a few minutes to get caught up

naive hatch
#

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).

ashen depot
#

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

naive hatch
#

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?

ashen depot
#

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

naive hatch
#

alright, thanks