#Village-Checkout-Success

1 messages · Page 1 of 1 (latest)

slow gust
worn fractal
#

And is the ID time limited? Is it invalid once the checkout session has expired to the customer?

slow gust
#

Hiya! You can grab the Session ID from the request in the Dashboard where you create the Checkout Session. This will be in your logs at https://dashboard.stripe.com/test/logs and will look like POST /v1/checkout/sessions

worn fractal
#

If its not clear, in testing my custom success page, i just want to hard code in a ID while im working on it so i dont have to trigger a real checkout transaction every time i want to reload the page.

#

To what you said, gab from where i created a checkout session, is this time limited? Can i still use a checkout session from over a day ago? Or does it have to be a non expired session?

slow gust
#

If the session was completed then no it is not time limited and you can then retrieve that Checkout Session at any point in the future

worn fractal
#

Is that the {CHECKOUT_SESSION_ID}?

Capture.PNG
slow gust
#

No, that is a request ID. Scroll down to the Response Body

worn fractal
#

Im guessing here, cause i dont know what the key value is. Is that the ID that starts with cs_test_alskdfj... or something else?

slow gust
#

Yes that is it.

worn fractal
#

Maybe im misunderstanding, it looks to me like this is only showing me the session object i created and sent over to checkout to create the session for the customer. I don't see it containing the results of the checkout process, did they successfully make payment, etc.

slow gust
#

Did you complete that Session?

#

Or did you just create it?

worn fractal
#

Im looking through sessions from yesterdays testing, i guess id have to create a new checkout to know 100%

slow gust
#

If you aren't seeing any data about the payment/customer then you likely didn't actually complete the session. If it hasn't been 24 hours you can grab the URL from the request you were just looking at and go complete the Session now

#

Sessions expire in 24 hours

worn fractal
#

I just went through a test successful checkout.
cs_test_a18VHdXXS4Qt4JfJOH9B2apHKyhjzuYb4w8rj1JBsIIoFwJu4wyBG8uLjw
I dont see anything informative in there, only what i already know, what i sent over to create the session. I assumed this was a way to know the outcome of a checkout for rendering a success landing page for the customer.

slow gust
#

Maybe I'm misunderstanding what you are looking for.

#

But really you use the Checkout Session to then retrieve the other relevant objects.

worn fractal
#

Like was payment successful? Was a customer and subscription created, or is their payment frozen pending review and they need to be told to wait, etc.

slow gust
#

That information is all on the Session

worn fractal
#

Like it would be stupid for me to say, "Congrads on signing up, now go log in" when their payment wasnt approved yet and they cant log in.

slow gust
#

Sure, but like I just said, you can see the outcome just from the Session itself. If you want the specifics of the Subscription to display then you would retrieve the Subscription based on it being a part of the Session retrieval response

worn fractal
#

Okay, i see the session object already has payment_status=paid, i missed it earlier.

slow gust
#

The general flow is to parse the Session ID from the URL and send it to your server. Then you retrieve that session on your server to note the details. You can use expansion to, for example, get the Subscription details all in one retrieval request.

#

Then you pass what you want back to your client to be displayed.

worn fractal
#

Yes, my progress so far is sending to checkout, having https://www.$baseDomain/page?id={CHECKOUT_SESSION_ID}, then on the page im getting \Stripe\Checkout\Session::retrieve($sessId);

#

Im just learning/figuring out what and how to use what's returned in that $session to render the success page. I didn't see at first the payment_status being returned. Thank you for pointing that out to me.

#

Where can i see the different possible values for that? To code in different responses.

slow gust
#

See the link above which has the enums

worn fractal
#

Just the three, paid unpaid no_payment_required? So if stripe is holding a payment for review, does that just kick back as unpaid? Or do they even get sent to the success_url in that case? Is this behavior documented somewhere?

slow gust
#

What does "holding a payment for review" mean?

#

That isn't a thing

worn fractal
#

There isn't a situation where after putting in payment details, stripe might not approve or decline, but send it to some kind of review? I had that happen to me once on a site using stripe, i assumed it was stripe doing it.

slow gust
#

No. If it is a card payment then it will either synchronously succeed or fail.

#

If it fails, the Checkout Session will not be completed.

worn fractal
#

Like i put in my CC info and hit submit, it said thanks for payment but its under review check back later to see if approved.

slow gust
#

No that is not a thing.

worn fractal
#

Okay, must have been something built into the site itself, just made me think it was coming from stripe. My misunderstanding.

#

So is it a safe assumption, if they end up on the success_url and payment_status=paid then we golden?

#

Now what about non-instant payments? Link some of the international banking stuff. How does that flow?

slow gust
#

Yep so asnych payment methods are a little more complicated, and are one of the reasons why Webhooks are much more effective than using the Session ID from the Success URL.

#

With Asynch payment methods then the Checkout Session will show paid, but the PaymentIntent will go into processing

worn fractal
#

Would they still end up on success_url, do i need to worry about those cases in building this page?

slow gust
#

Yes they still end up on Success URL

#

You just need to then figure out a way to know that the payment turns out to be successful later on.

#

We recommend Webhooks

#

The other way would be to poll the API every so often to check on the status of the PaymentIntent.

worn fractal
#

Yes, im relying on endpoint webhooks for creating accounts, granting access on my end. If that is what you are talking about.

slow gust
#

Ah okay, in that case why are you leaning on the Success URL from the Checkout Session at all?

#

Why not just use Webhooks for that

worn fractal
#

Im just building the success_url now, the cosmetics fluff. My backend is already functioning, i just want to make sure what im rendering to the customer on the landing page matches reality.

slow gust
#

I suppose this will result in a slightly delayed success page.... so yeah okay I see.

#

Yeah fair

#

I forgot about the latency with Webhooks and that it doesn't really make sense for rendering your success page

#

But yeah, for asynch paymentmethod order fulfillment all you need to do is listen for the checkout.session.async_payment_succeeded webhook

worn fractal
#

The way im using stripe, they signup, i hold their info in a session on my backend, i listen for endpoint webhooks, when i get invoice.paid i create an account on my end for them and give them access until subscription end time. So i just need something on success page saying "Congrads, you signed up, now you can login with your user/pass, blah blah" but ofcourse it would be stupid to blanket say that without knowing it really happened backend.

slow gust
#

Gotcha.

worn fractal
#

Yesterday it was suggested to use checkout custom success page, im doing that, im getting the {checkout_session_id} and loading the session from that.

What brought me to you now is figuring out what to rely on in that session to know i can tell them, your user/pass works now.

So from what i gather my answer is payment_status=paid. Is that all i have to look out for? I can just build my page around if that is paid or not? Nothing else i need to consider?

slow gust
#

Yes that will let you know that the customer successfully completed a Checkout Session and either completed a card payment or started an asynch payment successfully.

worn fractal
#

Is there any situation where they would be sent to the success_url and payment_status wouldn't be paid?

#

Am i doing a bunch of leg work for no reason if its always paid to even be on that page?

slow gust
#

If you are using setup mode

#

Then it would be payment_not_required

worn fractal
#

Okay, my modes are always subscription

#

so in my case, no

#

Okay, thank you, i believe that covers it all. Im done.

slow gust
#

Are you offering trials?

#

@worn fractal okay I just checked because I wanted to make sure, and we return unpaid for payment_status for asynch payment methods while the payment is processing. Then we will return paid once it finishes processing.

worn fractal
#

No im not offering trails, i only create customer accounts on my end after i get a successful invoice.paid hook

#

For asynch payments that return unpaid is there anything else returned in that $session that would tell me its unpaid because its a pending bank draft (for example), or am i blinding trusting if they on the page and == unpaid then must mean its asynch payment?

slow gust
#

No nothing would inherently tell you, but when you retrieve the Checkout Session you can expand the subscription.latest_invoice.payment_intent and check the status

#

If it is processing then you know it is async

worn fractal
#

Thanks.

#

Im not doing it right, im not getting the expanded info.
I tried both

$session = \Stripe\Checkout\Session::retrieve($sessId, ['expand'=>'payment_intent']);

$session = \Stripe\Checkout\Session::retrieve($sessId, ['expand'=>'latest_invoice.payment_intent']);
slow gust
#

You need subscription.latest_invoice.payment_intent like I stated above

worn fractal
#

I did that too.

Capture.PNG
#

Oh, am i supposed to nest inside another []

slow gust
#

What was the output?

#

No that looks like right syntax to me

worn fractal
#

the output is session object...

Capture.PNG
slow gust
#

Can you log out $session->subscription->latest_invoice->payment_intent?

worn fractal
#

This is the ID im using cs_test_a18VHdXXS4Qt4JfJOH9B2apHKyhjzuYb4w8rj1JBsIIoFwJu4wyBG8uLjw

slow gust
#

lol I just did this in node a few mins ago

shut sky
#

👋 you're using the legacy PHP approach

#

basically your expand is completely ignored @worn fractal, it's easy to see if you just dump the whole object, you'd see the invoice/subscription isn't expanded at all

worn fractal
#

Yes, i see that, thats how i know it isn't working, cause i am dumping the $session

shut sky
#

If you stick to the legacy way (you shouldn't) you want $session = \Stripe\Checkout\Session::retrieve([ 'id', $sessId, 'expand'=>'latest_invoice.payment_intent'] ]);

#

but really the newer way with the client is way easier and would have worked from the start

worn fractal
#

I didn't know i was learning old school, i was just following docs.

#

with client?

shut sky
#

which docs are you following exactly?

worn fractal
#

And based on that, this is how i did checkout session, is this not the "correct" way anymore?

Capture.PNG
worn fractal
shut sky
# 
  'id' $sessId,
  'expand'=>['latest_invoice.payment_intent']
]);```
#

come on

#

sorry my keyboard is not fun today

# 
  'id' => $sessId,
  'expand'=>['latest_invoice.payment_intent']
]);```
worn fractal
#

It needed the subsbcription added to it, this worked

$session = \Stripe\Checkout\Session::retrieve(['id' => $sessId, 'expand' => ['subscription.latest_invoice.payment_intent']]);
#

But you are saying that is frowned upon now, i need to read what you linked before...

shut sky
#

not really frowned upon, but the new way is a lot cleaner

#

if you used it, your original attempt at expanding would have "just worked"

#

you wouldn't need the "trick" of making the id part of the params like you have to right now

worn fractal
#

Okay, im on track for now, thanks for the info. You can close this thread.