#tounka

1 messages · Page 1 of 1 (latest)

ember narwhalBOT
wet hull
#

Do you have a request ID for the request you sent which shows that these attributes are missing?

past sky
#

i don't have a request. i am trying to access these attributes in code but it is saying it does not exist

wet hull
#

Can you copy/paste the exact code you're trying to run?

past sky
# 
s.Invoice.ID
s.Created```
wet hull
#

What's the whole request that you're trying to run?

past sky
#

well i'm trying to save this object to my database so i'm just mapping all the fields i care about

wet hull
#

Are you able to log the object out to your console and look at it?

past sky
#

i'm not. i haven't started testing receiving the events yet

wet hull
#

So a simple retrieve call doesn't give you an Event. It will give you the Checkout Session object. I would recommend finding a way to log that to a console, as that will always be the fastest way to know what attributes your object actually has

sinful jay
#

Is this further to our discussion yesterday @past sky ?

past sky
#

i don't believe so @sinful jay can you refresh my memory

sinful jay
#

Never mind - just wondering aloud

past sky
#

am i missing something or should the InvoiceId be apart of the checkoutsession object that i get from the checkout.completed.event ?

sinful jay
#

In subscription mode?

past sky
#

yea

sinful jay
#

Yes, it looks like that invoice is included - I thought it would just be the subscription but i tested with my own account just now

#

Are you not seeing that set?

past sky
# 
s.Invoice.ID
s.Created```
#

i can't do either of the above as it says Invoice isn't an attribute and neither is Created

sinful jay
#

It's not invoice ID -- just invoice in the response

#

so perhaps s.Invoice?

#

(and the value is an ID string)

#

Can you log out s to inspect it?

past sky
#

session.Invoice undefined (type *stripe.CheckoutSession has no field or method Invoice)

#

but using the go sdk version v72 doesn't have the attribute

sinful jay
#

Can you share an example event/checkout session iD?

past sky
#

i don't have any of that because i haven't started doing integration testing

sinful jay
#

I dont understand how you're encountering these errors then

past sky
#

i know the object has the fields. i just don't know why the sdk version i'm using doesn't include them

#

should i/should i not be using v72

sinful jay
past sky
#

let me try that

#

yoooo that worked, thank you so much

sinful jay
#

NP!

past sky
#

had one last question for now

#

From the time the user completes their payment and the checkout.session.completed event is sent how much delay is there? I know its real time but I’m unsure whether the front end can immediately make a request to our internal back-end to get the latest subscription details or whether a Server Side Event should be sent to the front end notifying that a user’s subscription status has changed

twilit hearth
#

It would happen quickly but we recommend having logic on your server that retrieves the objects from Stripe if you haven't gotten the other relevant event yet.

#

For example it is common for users to run their fulfillment logic either when they get that webhook or when the user hits the success URL, whichever happens first, they just need to make sure to make retrieve calls on the Checkout Session and other objects that they don't have updated info on yet

past sky
#

on your first recommendation, at what point in time would my server retrieve the object from stripe? not sure i follow

#

when the user hits the success URL, is it 100% guaranteed that i will get the checkout.session.completed event at some point? if so, i can just provision when they hit the successURL

#

i just don't want to be in a situation where they hit the successURL, i provision access immediately, but i haven't received the event yet and something wrong ended up happening

twilit hearth
past sky
#

"For example it is common for users to run their fulfillment logic either when they get that webhook or when the user hits the success URL" sounds like the latter isn't the most full proof solution then?

#

if i still haven't received the webhook event after the user is navigated to the successURL, my front end could make a call to retrieve the checkout session to confirm the subscription status? am i understanding that correctly

twilit hearth
#

Your backend would be what is making that call

twilit hearth
#

Basically, you are guaranteed that you will get the checkout.session.completed event but there is always a strong possibility that your server will get the request from the user's browser to see your success page first

#

If the user's browser wins the race, you might not have some data on your server yet that you need to render your page. If that is the case, you can just make a retrieve call from your server to get the latest info on whatever Stripe objects you are interested in

past sky
#

i'm under the impression when the user is done checking out is redirected to the success page, i will definitely be receiving the checkout.session.completed event

#

i'm more concerned about the provisioning of access not the user seeing the success page. for example, if they pay and see the success page and then try to navigate to portion of our site that requires a subscription, i'm not sure if its possible that i still haven't received the event checkout.session.completed to provision their access

twilit hearth
#

So in that scenario, would you still have some kind of record on your side of what this user's Customer ID was or of some other stripe object related to them?

past sky
#

for the success url page, yea i would have the customer ID

twilit hearth
past sky
#

i'm not sure that solves my issue

wet hull
#

Hi there 👋 taking over, as my colleague needs to step away

How does that not solve your issue? You want to make sure that the customer should have access to your service in the event that the checkout.session.completed takes more than 3 seconds to fire, so I'm failing to understand why listing the Customer's active subscriptions is not a workaround?

#

Also, checkout.session.completed only fires on payment success, for what it's worth

past sky
#

so if the user is redirected to the success page, is it possible the payment wasn't successful?

#

it seems like the suggestion was to list the subscription on the server? if so, i could be making these api calls for users who have never even paid. if on the client side i think that would be fine

#

what is the delay for this event typically checkout.session.completed

wet hull
#

so if the user is redirected to the success page, is it possible the payment wasn't successful?
Only if they paid with a delayed payment method type (like SEPA, ACH Direct Debit, or BACS). For card payments and other non-delayed payment method types (e.g. Google Pay, Apple Pay, etc.) it will only redirect if the payment was successful, otherwise it falls back to the cancel_url

#

what is the delay for this event typically checkout.session.completed
Less than 5 seconds

past sky
#

gotcha

#

so what i'm thinking of doing in scenarios for non-delayed payment methods is when the user is navigated to the success page, querying my back end for the subscription info, but if it doesn't exist yet, querying stripe directly for it.

#

is this something you'd recommend doing?

wet hull
#

Yeah, that would be a good way to go about it, since the DB query will be basically instant, and falling back to an API call to Stripe will give you a response in less than 3 seconds

past sky
#

got you

#

and for delayed payment methods, it sounds like i would receive the checkout.session.completed event before knowing if the payment succeeded?

#

stripe recommends provisioning access once that event is received but its possible that the payment will fail right

wet hull
past sky
#

wait so for a delay payment method, i won't get the checkout.session.completed at all?

wet hull
#

wait so for a delay payment method, i won't get the checkout.session.completed at all?
Correct

#

You still want to listen for invoice.paid and all the other relevant events in those docs. You just need to make sure you're not relying on checkout.session.completed for provisioning access to Subscriptions that have a delayed payment method type

past sky
#

dang thanks for the heads up

#

on invoice.paid events, what indication do i use to know that i'm dealing with a delayed payment method type

wet hull
#

invoice.paid will only fire if the payment was successful, so you don't really need to know if it was/wasn't a delayed payment method type

#

That will only fire if funds actually landed in your account

past sky
#

got you. so similarly, invoice.payment_failed would happen at the time the delayed payment failed

wet hull
#

Correct

past sky
#

going back to what i mentioned earlier... is whether the payment was made with delayed/non delayed apart of the checkout session object? i don't want to query my back-end for subscription updates unnecessarily

#

like if it was a delayed payment method, no need to do anything but let the user know to come back in a couple days when the payment was received. unless, does stripe recommend provisioning access immediately

wet hull
#

You would have to check the status of the Payment Intent object. If the status of the PaymentIntent object is processing, then don't provision access.

#

unless, does stripe recommend provisioning access immediately
Eh, this is largely up to each individual/organization. I personally would not provision access to a subscription service with delayed payment methods, since bad actors could just repeatedly use bad account info to get free access to your service for 3 to 5 business days

past sky
#

for non-delayed payments what would the status of the PaymentIntent object be?

wet hull
past sky
#

ok

#

ty!