#lowercase00_best-practices
hazy bloomBOT
👋 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/1298110483886506136
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
analog mauve
From what I understand, approach (1) requires the customer to authorize (and have limit) for the full amount, while (2) and (3) would allow to process payments without the need for the customer to have the full amount available at once. Wondering if I'm understanding this correctly, and whether more experienced developers with Stripe have best practices when handling this sort of flow. Any inputs are appreciated, thanks!
valid patio
I think subscription schedules actually suit your use case better than the other options : https://docs.stripe.com/billing/subscriptions/subscription-schedules/use-cases#installment-plans
analog mauve
Thanks for the input - as I understsand there's 2% overhead on the subscription/billing API, though, no?
It's a rather unusual situation in our case, since our payment plans are fairly tight (eg. 6x $25 every 2 weeks for example), it's been a while since we've looked into the subscription and ended rulling it out, but I honestly don't remember correctly, I think it was a mix of pricing (tight margins) and implementation, but not too sure
valid patio
We aren't very familiar with pricing here so we can't really advise on that here on this channel. Okay, it sounds like you don't want to use subscription schedules,
approach (1) requires the customer to authorize (and have limit) for the full amount, while (2) and (3) would allow to process payments without the need for the customer to have the full amount available at once.
your understanding is correct for the above statement
analog mauve
got it - yeah, I will double check the subscription schedules though, appreciate you poiting that out
would you happen to know if there's any practical differences in (2) and (3) ?
i was going through the logs of an older integration and it was basically just:
POST /customer
POST /payment_method
POST /payment intent
seems simple enough, but can't get a sense of the tradeoffs I'd be making between those two approaches.
valid patio
i think the difference btw 2 and 3 is really how you want to handle the first payment. If you want to collect the first payment immediately, then 3. If you collect the payment at a later point, then 2
are you using the Payment Element?
analog mauve
hmm, I think we are. those custom objects in React, right
yeah I am
just confirmed, it's been a while i wrote the POC. the payment flow itself is mostly custom, but the components to get the card details are done through Elements
valid patio
there're different kinds of element components though
just to confirm again, you're using the Payment Element now?
analog mauve
yeah, I just have the PaymentElement component, wrapped in the Element with the stripePromise associated with it
I'm not familiar with all the Element components though, maybe there's more to it that I don't know
valid patio
I don't have context on your existing / older flow, so I'm not too sure why you're explicitly creating a PaymentMethod first. There could be a very good reason for that.
Just so you know though, you don't have to explicitly create a PaymentMethod first - you can just use setup_for_future_usage=off_session and include the customer when creating the PaymentIntent, and the PaymentMethod collected with the Payment Element will automatically be attached when the PaymentIntent is successful
analog mauve
perfect. just for context I had a working proprotype with this exact setup: creating the payment intent, creating the checkout session, updating backend state with the webhooks and using the callback url for the UI.
this prototype was only functional for single payments though, so we started investigating the implementation for multi payment / multi capture. that's when I came accross the logs of a previous implementation (other application) that used the manual payment method creation (mentioned as a form of benchmark).
valid patio
onesec, there's something odd about your prototype. If you create a Checkout Session, you don't need the PaymentIntent for the first payment
the Checkout Session itself creates an underlying PaymentIntent when payment is attempted
analog mauve
hm, understood. this was ~6mo ago, so I don't remember exactly why I made that decision - if I'm not mistaken it was for better control of the webhook, since by having the paymentIntentId would save a couple of requests when the webhook that the Checkout was completed arrived
valid patio
just so you're aware also, Checkout Sessions don't support saving Apple Pay for future use at the moment in case that's important to you. This is temporary until we can build support for creating Apple Pay Merchant Tokens with Checkout Sessions.
analog mauve
I might be wrong though, or might have implemented it in a less than optimal way
got it, that's helpful. from what I understand so far, probably the best mix between simple implementation and flexibility would be:
- (server) Create the
CheckoutSession - (client) go through checkout process with the
Embeddedforms - (server) get the webhook after checkout is finished, it will have the
setup_intent - (server) capture a payment by creating a
PaymentIntent
valid patio
the first question i have is if you intend to collect payment immediately?
analog mauve
We have both cases: some payment plans have a downpayment, some don't
so it seems this approach would allow us to use the same setup/flow for both use cases
whereas the previous approach (2) would only work for cases where the payment plan includes a downpayment (eg. less flexibility)
valid patio
personally, i would create two separate flows - the ones that require a downpayment, you would pass in this parameter : https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-payment_intent_data-setup_future_usage
it's better in a couple of ways :
- less API requests necessary
- the Checkout Session will handle payment failures for synchronous payment methods e.g. cards so that you don't have to deal with that. It's possible that you collect the payment method, and then when you attempt to charge, it fails / gets declined
analog mauve
I see... I would have to handle the payment failures for the off_session captures either way though, no?
valid patio
yes, but that would be a separate / different flow
analog mauve
your point is that at least for the downpayment that would be automatically handled
valid patio
because you need to request your customer to come back to provide a new payment method. they aren't currently on your site
your point is that at least for the downpayment that would be automatically handled
yep
analog mauve
got it, makes sense
So at the end is just creating the Session, saving the payment method, and creating the payment intent on further collections
valid patio
you would just create the Session to collect payment (assuming we're talking about the flow with a downpayment). The PaymentMethod is already saved for you when the Checkout Session is created because of this parameter : https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-payment_intent_data-setup_future_usage
analog mauve
i meant saving it on my DB, i assumed i would need that for the future paymentIntent
To reuse the payment method, you can retrieve it from the Checkout Session’s PaymentIntent.
Apparently no need
valid patio
i meant saving it on my DB, i assumed i would need that for the future paymentIntent
Ah then yes, that's correct
analog mauve
saving it would just save a couple of requests, but it would still be available at the original session
valid patio
weeell, you should still save it to your DB. Generally, you don't want to make more requests than necessary : https://docs.stripe.com/rate-limits#rate-limiter
analog mauve
yeah definitely, i actually already have that field, just trying to understand if it's something that would be attached to a previously created resource was something that I would have to use a more manual approach to retrieve (eg. list payment methods for a customer)
well, understood... i guess the (1) multi capture makes sense when we want to make sure the customer has limit for the full amount, (2) the checkout with save for later allows for automatic handling of failures during the downpayment, while still allowing for future collection, and the (3) setupIntent allows to handle cases where there is no downpayment. so it seems I might be using all of them at some point, with a preference for (2) since it does a couple of things automatically
valid patio
for 3 - you can use Checkout Sessions for this too, with mode="setup"
analog mauve
perfect, even better then
valid patio
the rest of what you mentioned is correct
valid patio
again, just to reiterate, Apple Pay isn't supported for Checkout Sessions for your use case (i.e. cannot be saved for future usage with Checkout) in case that's important to you
analog mauve
understood, will keep that in mind, not that important at this time we can live with that at least for a while
valid patio
happy to have been able to help! feel free to reach out again if you have more questions