Improve user session handling during pending Stripe payments to avoid booking_conflict errors

[DmytroCrawford]

Is your proposal related to a problem?

I use Cal.com for booking on a Rally School and integrate with Stripe for payments. Occasionally, when users are midway through the booking cycle (go to the pending waiting for payment phase) they click off of an event to check a different date or time, and then come back to the original cycle. When this happens, the user is met with a Could not book the meeting. booking_conflict. I assume this is because the platform has registered the user in the waiting for payment workflow and doesn't want to create duplicate entries for an event. Although yes, an email is sent, most users' first instinct is not to check their email when the issue arises. Its a little annoying cause I assume this effects conversion.

Describe the solution you'd like

Is there a way to somehow cache a user session in the browser with some sort of TTL, or have a TTL for pending payments? I have only thoughts about this for about a second but open to hearing ideas.

Describe alternatives you've considered

I have thought and looked into making the pay now button open in a new tab.

House rules

• If this issue has a 🚨 needs approval label, don't start coding yet. Wait until a core member approves feature request by removing this label, then you can start coding.
  • For clarity: Non-core member issues automatically get the 🚨 needs approval label.
  • Your feature ideas are invaluable to us! However, they undergo review to ensure alignment with the product's direction.
  • Follow Best Practices lined out in our Contributor Docs

[DmytroCrawford]

For more context, 1353 in HandleNewBooking invokes the error after receiving err.code -> "P2002". This is more of DB design thing, which is why I am kind of open to a discussion about how to handle this and haven't necessarily gone about fixing it myself.