cal.com
cal.com copied to clipboard
calcom
[CAL-969] RFC: rethink payments flow
Our current flow goes like this:
graph TD
A[User books]
F[Unconfirmed/unpaid booking is created]
P[Booking updated to paid and confirmed]
C[Pay Later]
I[Stripe Elements]
L[Paid]
A --> C
C --> F
F --> I
I --> L
L --> P
We want to increase the flexibility for our users in payment flows in order to accommodate to more use cases:
- Allow users to choose between Stripe Elements or Stripe Checkout payment flow
- Implement a callback endpoint for users who choose Stripe Checkout
- Allow users to choose between Pay before or Pay later
- If pay before, we show payment screen (or stripe checkout) before confirming
- Using Stripe Checkout would open up the possibilities for more payment methods as Apple Pay and Google Pay. Related #6629
It would look something like this:
graph TD
A[User books]
F[Unconfirmed/unpaid booking is created]
P[Booking updated to paid and confirmed]
B[Pay Now]
C[Pay Later]
D[Stripe Elements]
E[Stripe Checkout]
G[Paid]
H[Success]
K[Callback]
N[Confirmed/paid booking is created]
I[Stripe Elements]
J[Stripe Checkout]
L[Paid]
M[Success]
O[Callback]
A --> B
A --> C
B --> D
B --> E
D --> G
G --> N
E --> H
H --> K
K --> N
C --> F
F --> I
F --> J
I --> L
L --> P
J --> M
M --> O
O --> P
@Peer I agree. It would be better to postpone it until it pays; Otherwise, we create a lot of false positive, and I risk to fill my calendar and move meeting around, until is not paid;
Plus, i got a regular email, to accept the meeting, as any other meeting;
it would be great to change also the content of the alert and being able to say: • hei, this person X was interested in this service, this is the content of the form he/she provided (as I have multiple input text required), once the person confirm the payment, you receive another email about the confirmation of the event; Also here, what happens if the person buys a meeting a 7am, and complete the payment at 6.59? :slightly_smiling_face: We should add a disclaimer to say: all right, you paid, get in touch with X now (where X can easily be the email associated to my cal.com account)
To decrease responsabilities http://cal.com|cal.com side;
@zomars
From SyncLinear.com | CAL-969
worth mentioning a team is currently adding a Lightning Network Payment App: https://github.com/calcom/cal.com/pull/6320
it should not create any merge conflicts but just a heads up
@zomars @PeerRich I've been able to take a closer look at the code, and am wanting to confirm the approach I'd take with this change.
Firstly, I'm guessing that a Host User might want some Event Types to be Pay Later, and might want others to be Pay Now. Therefore it seems appropriate to add more options to the Event Type > Apps > Stripe section (in addition to the cost option that's there now).
Pardon the terrible mockup, but I'm thinking something similar to this. I just noticed I'm calling Stripe Elements "Stripe Express" in this mockup, but you get the idea 😬
Once published, new Booking Users would be redirected to the Pay Now / Pay Later flow based on the Host User's preferences for the given Event Type.
So this PR would really include 2 changes that aren't necessarily directly related:
- Add the ability to require Pay Now (and preserving Pay Later)
- Allow Host Users to choose between Stripe Elements or Stripe Checkout
Let me know if I'm misunderstanding anything, and I'll change my approach. Also, I think it will be important to think through the wording on why a Host User might want Elements vs Checkout, but that's not an urgent need at this stage.
A simple toggle should work:
most users don't know what Stripe Elements is
@PeerRich agreed. The wording will need to communicate why a Host User would choose one over the other. I'm back to working on this today, let me know if you have any suggestions 👍
worth mentioning a team is currently adding a Lightning Network Payment App: #6320
it should not create any merge conflicts but just a heads up
@PeerRich could you clarify the areas of the code I should be cautious about changing? I'm starting to modify the booking page, and I'm guessing some of this code will be modified by this mentioned PR. Any upfront advice on avoiding future conflicts?
you should be fine to move forward, spoke to @zomars and I think the files are scoped fine to not have conflicts
we get a lot of requests for RazorPay nowadays. I think there is also Mercado Pago as well that is being requested. Can we keep new external payment providers in mind when architecting this?
The process flow of how to make a booking is confusing and should be improved. Our clients get unnecessary emails. Here is the whole process flow our customers have to go through.
context: When setting up the event type by using the Stripe app on cal.com, there are only two options to choose from in regard to how the payment should be made. It’s either by “Collect payment on booking” or “Charge no-show fee”. The process flow varies for both, and both of them seem to have issues, at least for us.
For the 1st option - “Collect payment on booking” When I have the first option enabled, our clients pay immediately on the booking, but right after, they get an email saying that “Your meeting is awaiting payment”. When paying immediately on the booking page, this mail should not be sent. This confuses many, and currently, we always have to communicate that the payment is made correctly, and they should ignore the “Your meeting is awaiting payment”-mail. Also, once the client books a call, they get a confirmation email saying, “Your event has been scheduled”. However, we as a host haven’t confirmed the booking yet. Once the host confirms the booking, the client gets the same confirmation email again. The only thing that is added to this 2nd email is that there is a link for the video call. But both confirmation emails have event.ics files. This is unnecessary, the file should only be sent only once.
For the 2nd option - “Charge no-show fee” When I have the second option enabled, our clients pay immediately on the booking, but right after, they get an email as well saying that “Your meeting is awaiting payment”. Same here: If they pay immediately on the booking page, no such mail should be sent. What’s better here is that after paying, the client gets an email saying, “Your booking has been submitted”. The remaining problem is that after the host accepts the submitted booking, the client doesn’t get any confirmation email, which means the event.ics file is missing, and the video call link as well. Also, the client’s card isn’t charged even though the host has accepted the booking request.
What we need:
- We need a 3rd option in the Stripe app when setting up an event type. Which could go like “Collect payment after booking via email payment link”. This means there shouldn't be any Stripe embedding when doing the booking, otherwise the client might be tempted to pay immediately.
- Once a booking is made, the client should get an email with a payment link (e.g.“Your meeting is awaiting payment”).
- Once the payment is made, the client should get a confirmation mail saying that his/her request for a meeting has been submitted, and the client should wait for a confirmation from the host. Also, telling that if the meeting is rejected/canceled by the host, they will get a refund.
- Once the booking has been accepted by the host, a confirmation mail (incl. a video call link) should be sent to both client and the host. Only this mail should have an event.ics file in it.
Happy to show and discuss this in a call: https://cal.com/mehmetademi
we get a lot of requests for RazorPay nowadays. I think there is also Mercado Pago as well that is being requested. Can we keep new external payment providers in mind when architecting this?
Coming back to this, I'm also looking to integrate another Payment Gateway other than Stripe (Opn - https://www.opn.ooo/) since it allows for more local payment options in the region I'm in.
What's the best way for me to make this happen - particularly if I were to hire someone to do the dev work?
