meisei81_api

[calm igloo]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1224991424945328160

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[blazing canopy]

Hi, let me help you with this.

[cedar onyx]

Great. Thanks.

[blazing canopy]

You can look at the latest_charge property, it will contain the Charge object, whose created time is the time of the actual payment confirmation.

[cedar onyx]

Got it.

Is there any other way?

[blazing canopy]

You could potentially look for the time of the checkout.session.completed event, and check the created time too.

[cedar onyx]

The event's created time is later than the latest_charge created time

event created time: 1711982903

latest_charge created time: 1711982890

The interval between the two is 13 seconds

[blazing canopy]

Yes, it's the time to create and send out the event, I guess.

[cedar onyx]

Here's the thing, our client was paid twice caused by the delay of the checkout session completed event

Do you have any suggestions to avoid this situation?

[blazing canopy]

It depends on how your application is architected.

Allowing only 1 active session per customer would be one solution.

[cedar onyx]

The active session means checkout session? How to implement the only 1 active session per customer?

[blazing canopy]

You can list Checkout Sessions by customer + status: "open".

[cedar onyx]

Let me check on this

Thanks for you advice. It helps a lot.

[blazing canopy]

Happy to help.