#Gizmo - Saved Payments
1 messages ยท Page 1 of 1 (latest)
Hi Snufkin, how are you?
Peachy keen. Let's see if we can get you sorted. So in this situation you want one checkout to cover both a one-off purchase and the first charge for a subscription?
Yes, exactly. The subscription is an optional add-on in my purchase/checkout flow.
Okay, that add-on part is the tricky one I think
In most cases the one-off is the add-on and in that case you can create an InvoiceItem to represent this charge that would get appended to the subscription.
Yeah, unfortunately that's not the case here. Plus I believe it was explained to me previously that you couldn't refund each separately doing it that way.
Is there a way to just store the provided payment method and then create a one-time charge against it and then create the subscription against it?
Yes, that might be your best bet. It would separate the actions in your integration but if you first store a payment method (card) for use off-session then you can create both a single charge and start a subscription.
Thanks, do you have any documentation that instructs how to accomplish this?
You can select a different type of integration (Prebuilt Checkout, iOS, etc.) from the tabs on the top if they better match your approach
Thank you very much, I'll give this a read and give it a shot
Okay great! We'll be here if you have more questions.
Much appreciated ๐
Does setting off_session to true make transactions any less likely to go through successfully?
If the issuing bank decides that they want to require something like a 3DS authentication flow it can hold things up until you bring the user on-session to authenticate
Do you know how often that happens? Is it a mistake to use off_session if my user is present making the purchase? Is there any way to achieve when I need to do without going off-session?
if I may: you're optimizing for the wrong thing
I'd recommend doing one payment for the one-time payment and the subscription together
it's a way better experience overall, lower fee for you, less risk of a decline, etc.
you're still able to refund partially the charge for the relevant information
That's how I would build this personally at least
other than that, we don't have stats to share, it's really up to the bank and depends on many factors. If you get a decline, you'd mostly be getting the customer back on session
Thanks for chiming in, koopajah. Can you please tell me how I would do that?
you would pass the right line items to Checkout. You can combine a recurring Price and one-time Price
Does that mean I would need to create all of my products in Stripe beforehand? The one-time charge price can be variable
Not really
sorry I assumed you were already familiar with the basics of Checkout if that's not the case I'd recommend starting with our docs https://stripe.com/docs/payments/checkout
you can use dynamic pricing if you need to via price_data https://stripe.com/docs/api/checkout/sessions/create
No worries. Yeah, I'm still trying to get started. The idea of refactoring this app I've been building for 6 months to use Stripe is daunting. ๐ฑ
ah yeah I bet
Ok, I'll go through these links. One of them describes how to add both a one time charge and a subscription?
https://stripe.com/docs/payments/checkout/how-checkout-works#mixed specifically yes
Awesome, thank you koopajah
sure thing!
koopajah can I do it without using the Stripe hosted payment page?
yes but it's days of work ๐
lol. is there any way to do it with the PaymentIntent form that can be made to appear integrated with a site?
yes all of that is doable easily
just way more work. I would strongly recommend just letting us do it for you with Checkout
I appreciate that, and I would love to do it the easier way you propose, but unfortunately I think I'm going to need to put in the work so that checkout appears to happen on my site.
fair, that's a mistake though ๐
everyone thinks you need it on your own website, but you don't, and Checkout increases conversions, supports Apple Pay, Google PAy, tax calculation, discounts and then some
but you can definitely try via https://stripe.com/docs/payments/accept-a-payment mostly
Don't most polished ecommerce experiences have you checkout from their own website?
My take is no, more and more websites redirect (more and more people use Checkout for example)
Ultimately you can totally follow our main docs, just based on your comments earlier about rebuilding this all, I wanted to nudge you in the right direction, spending all your time designing a tweaking a payment UI flow when you could grow your business or add new features seems like not the best focus
I definitely understand where you're coming from and appreciate you trying to guide me in the right direction, but I really want to get it to work on my site.
Were you referring to the "Custom payment flow" on https://stripe.com/docs/payments/accept-a-payment? I was able to do a one time payment that way, but I'm not sure how to do both the one time payment and the subscription that way.
it's really the same as what I explained earlier
you'll need a lot of code to handle the complexity
but overall you either do one-time payment (what you have already) or you create a Subscription upfront with both the recurring Price and the one-time item in https://stripe.com/docs/api/subscriptions/create#create_subscription-add_invoice_items
the subscription has an invoice, that invoice has a PaymentIntent which has a client_secret same as the one-time payment
Thank you. And they can be refunded independently? Or I can refund an arbitrary amount so it's as if they can be refunded independently?
the latter
Got it, thanks. Is there any way for me to access this thread again once it's archived so I can refer back to it? If I keep the link to it, will it still work?
Terrific, thank you. That's all I've got in me for tonight, I'll have to pick this up tomorrow evening. Have a good night.