#CheckoutList
fossil wyvern
That's an object ID, not a date.
Sorry, I want to filter them based on a date range, ideally.
tough cedar
ahh
Umm I see. Unfortunately our API seem doesn't support it yet
You can list all then implement your own filter though
fossil wyvern
Yep! Thanks mate. Just trying to get pagination working. I assume the API always lists the latest CheckoutSessions first?
So if I do sessions := session.List(params) I'll always get the latest sessions?
Hmm. I actually can't find a date/time attribute for a CheckoutSession object.
tough cedar
Right, I am looking at the object
A bit surprised to me too, but yes the Checkout object doesn't have the date/time
fossil wyvern
There's a timestamp on the payment for a particular session, when viewed in the console. I wonder if I have to get the Payment object?
session.PaymentIntent.Created?
tough cedar
I think so yes. Payment Intent should be treated as transactions
fossil wyvern
Awesome. I'll take it from there and see how far I get - thanks, @tough cedar
tough cedar
Good luck!
fossil wyvern
😄
for sessions.Next() {
session := sessions.CheckoutSession()
if session.Status != "complete" {
continue
}
if session.PaymentIntent.Created < notBefore {
continue
}
if session.Customer == nil {
continue
}
allSessions = append(allSessions, session)
}```This did it.
tough cedar
Ahh filter directly with the Payment Intent inside
fossil wyvern
Sort of. I had to do params.AddExpand("data.payment_intent") and then I can access .PaymentIntent.Created, which is a UNIX timestamp.
tough cedar
Go lang, right?
fossil wyvern
Aye
tough cedar
This part
if session.PaymentIntent.Created < notBefore {
continue
}
If you have 100 sessions, the notBefore happens at 60th. You will loop 60 times with appending and 40 times without appending
If you break instead of continue, you will only loop 60 times and exit
Just my guts when imaging the pagination logic
fossil wyvern
I see what you mean - you're suggesting I short-circuit the loop once I hit an invalid date? That's a great suggestion, thank you, but it comes back to my original question above: in what order do the checkout session objects come back from the API? 🙂
What if the order is random?
I could stop on the first invalid date, at sessions[10], break from the loop and miss out on 30-40 checkout sessions, no?
tough cedar
Right, fair point. To confirm your original intention is to filter out "after some created date", correct?
and using auto pagination hmm
fossil wyvern
Yep! So I want to run a cronjob based worker every few minutes, find new CheckoutSessions that were created in the last 72 hours, determine if I've never seen the item before (based on the customer's email), and then create a new customer account in a DB if I've never seen that email.
I want to avoid using web hooks as I find them fragile. If I'm reaching out to the API on a periodic basis, there will be a slight delay for the customer of a few minutes, but it's easier for me to maintain and it scales to infinity. Also, I don't have to worry about missing customer payments during a deployment of anything, as a service that's down cannot receive a web hook.
tough cedar
I totally understand the concern as of a dev, but I would say Webhook still save you from more troubles, like you could end up with higher chance hitting rate limit for the polling strategy, or your cron job could error/down on network connect just like if your webhook endpoint is down via a deployment
👋 I will need to step down for the day. If you have other questions feel free to ask in the channel and my colleagues would be happy to assist
For above code, I think if you control the pagination yourself by starting_after and limit to load batch of 100 sessions for example, you can control the order and short-circuit, but yes a full loop using auto-pagination shouldn't have much impact over performance 😄