#mesudev_api
1 messages ¡ Page 1 of 1 (latest)
đ 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/1328777227600531520
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hello! Yeah, with up to 60 days placing a hold isn't practical. Renewing a hold over that period of time also isn't practical. The two things that come to mind are to charge them the full amount up front and refund part of that amount if they don't show up, or you can collect their payment information and set it up for future use without charging anything, then attempt to charge later for whatever amount you need.
The problem is that setting up for future payment will require their consent to pay for the no-show fee
Angry / Complicated customers won't do that
I've seen that you have listed extended authorizations, here https://docs.stripe.com/terminal/features/extended-authorizations. 30 days would already be excellent. But I guess that wouldn't work, given that the concerned industry is a beauty clinic making medical treatments
Or can there be exceptions ?
That's not my area, so I can't say, but I doubt your use case would qualify for an exception. No harm in asking, though: https://support.stripe.com/contact
Ok, will do
Seems like charging up front and then refunding might be the best approach though.
Yeah maybe charging upfront and then deducing the charged amount from the doctors bill to pay
if they show up
Yep.
to really convert 100%
Or
maybe
let them make the booking with a setup payment method. 4 days before the appointment, an e-mail is sent asking them to authorize the payment (which will thus only be done once). If they don't do that, the appointment is cancelled.
In this way, the capture can then be made independently of the concerned person, if his content was given at the moment of the booking, which should be okay. Plus only one authorization is required. Makes sense ?
Or do you see any issues with that strategy?
Yep, sounds like it's worth a try.
because I get it correctly that refunding will always come at a cost, right ?
What do you mean?
Like if a payment is charged upfront, 100 USD. The patient shows up > 100 USD will be refunded (If I use the refund strategy). Of the 100 USD initially charged, there aren't 100 USD available anymore, due to stripe's transaction fees. Correct ?
You'll be charged fees either way.
Yes I know but the thing I'm trying to say is even if I "refund", I'll have to pay part of that refund myself to pay the entire amount of the initially charged 100 USD
right ?
Yes? Sorry, I'm not sure I fully understand the context/flow you're describing.
Just to confirm that charging upfront is the only way where no money is lost in case the patient shows up
Cheers, I'll check now if extended authorizations are possible
Have a g one!
Losing money to fees, you mean? Or losing money because charging later fails?
Losing money to fees
If you successfully charge you'll always pay the fee for that, so I'm not sure it makes a difference when that happens?
Because the amount the doctor makes with a no-show is smaller when the patient does not show up, if refunds are used
IF I am right, that's my question
Oh, so you're saying if you charge $500 up front and pay fees on that whole $500, but then refund $400, you're losing out because the fees on the $500 charge are overall higher than just charging $100?
If so, yep.
Case i): Patient A pays 100 USD upfront and shows up > 100 USD must be refunded. Of the originally paid 100 USD, the transaction fee is deducted. So to refund the entire amount of 100 USD, the doctor must pay for a small part.
Case ii): Patient A pays 100 USD upfront and shows up > 100 USD are discounted from the doctors bill the patient has to pay.
Ah but in case ii) loses the same transaction fees, I get your point now
Yeah, either way you pay the fees on that $100 charge.
but that means that exclusively for the reversed transaction, there are 0 fees?
as long as the money stays in stripe and is not paid out to the doctors bank
I don't think so. We aren't fee experts here, but I believe you also pay fees on those?
Pricing and fee questions are better for support than here though: https://support.stripe.com/contact
okok I'll check on that with the support channel too
last question then
I currently always integrated stripe connect, but mainly because split payments / a marketplace payment flow had to be automated. From an API perspective, I think stripe connect is unnecessary here?
Or is that also sth I should ask the support channel?
I don't have enough understanding about your use case and situation. It sounds like you have three parties involved, though; you, the doctor, and the customer. When three parties are involved Connect is usually required.
Can you describe an example transaction/flow end-to-end, including example amounts, where funds come from, and where funds flow, including who gets what monies/fees?
sure
atm it would be customer pays 100 USD, to the doctors bank account. That's it
I only come into play if the doctor (my client wishing for the integration done by me for him) agrees to some kind of commission model to me per transaction. Then connect will be the case, but not before
Yeah, if only two parties are involved in that initial payment then Connect isn't needed at that stage, as long as you don't need any control over that payment as a third party. Like you're not initiating it or involved in that payment in any way, right?
Not at the begining no
which stripe API would you recommend for this pure A to B setup ?
There are several options. You could potentially use a Payment Link, a Checkout Session, a one-off Invoice, or a Payment Intent. Whichever suits your needs and preferences best.