#b33-ece-timing

1 messages · Page 1 of 1 (latest)

nova jayBOT
leaden barn
upper mauve
#

b33-ece-timing

#

@leaden barn I would recommend having a PaymentIntent upfront and keeping it updated based on what's in their cart instead. The 1sec limit is a hard requirement from partners like Apple

leaden barn
#

hm ok. I want to reduce the api usage, because normally my customer put something inside their cart and later maybe remove it ... can I somehow set an await function that awaits the paymentintent and then hold the line in the onShippingAddressChange Function? I saw that that function don't need to be resolved within a second? 🤔

upper mauve
#

I don't think so but let me ask my team

leaden barn
upper mauve
#

I don't really get the words you're using sorry

#

You render the buttons without a PaymentIntent, you don't need to create a PaymentIntent with onClick so why are you trying to do that?

leaden barn
#

ah now I got you. Yes, I do render the buttons without a paymentintent.

#

I am creating the paymentintent, to collect payments 🙂

upper mauve
#

yeah you do this later in the flow. It's definitely different from the PaymentElement integration (though we do have that new flow there too, we call it "defer intent")

leaden barn
#

well that sounds a bit crazy... can you link me the defer intent please?

upper mauve
leaden barn
upper mauve
#

You don't need to replace anything, I'm just showing you that we have that integration path on multiple of our UI components

leaden barn
upper mauve
#

I have already given you the exact answer you need earlier though. I'm confused what the problem is

leaden barn
#

I saw and read your answer

yeah you do this later in the flow.
For me the problem is, that my endpoint to calculate the shipping costs need the paymentintentId

upper mauve
#

you can fix that to not need it

leaden barn
#

but I can also await the paymentintent creation inside the onShippingAddressChange Function and check if the paymentintent is null to create only one...
Maybe I can do a third and even a fourth way, but I think all of the are not proper solutions 🤔

upper mauve
#

If it were me, I would do none of this. Your backend knows what the customer is ordering, when you hit your backend for amount calculation for shipping, you can make all the calculations you need and have no reason to need a PaymentIntent. So fix that so that you don't rely on it and create the PaymentIntent at the end

leaden barn
#

yeah, that sounds like an good idea, thanks! 🤗

upper mauve
#

It's definitely a shift in the integraton approach where the PaymentIntent isn't really used to track ongoing payments and really used right at the end when someone is ready to fully pay

leaden barn
#

yes, I think your provided solution is better for the client, but more bad for me as the shop owner. Because I can't track any payments until they are nearly complete

upper mauve
#

I mean you can track them by having your own order representation for example and tracking this the same way you would in a cookie. That's what I would do. PaymentIntents have no "line items" or "shipping calculation" concept so you have to do this already anyways

leaden barn
# upper mauve I mean you can track them by having your own order representation for example an...

exactly. I loved the orders api, because you can do everything like that and now it's gone 😦
I think it's a little hard for me to keep track of all the stuff stripe currently tracks. The shipping calculation and shipping amount and ... are stored in the metadata of my paymentintents. So I can render all the stuff from the paymentintent to the customer. It's like a "trusted object". If something is wrong in my integration and the customer get wrong amounts he can break up the checkout.

So I builded everything around this "trusted object"... maybe I create a new project, just to have "normal" checkout procedures.

upper mauve
#

Then we're back to my earlier advice: Create the PaymentIntent upfront and keep it updated as they modify their cart. There isn't really a better way if you want to "track orders as they happen". It's this or your own model

leaden barn
#

and then create a paymentintent everytime a user open his first product-detail page?

Won't stripe block me for to many unused paymentintents 🤔

upper mauve
#

no we won't block you. You can always decide to do it the first time they are clicking on "pay" or whatever and get to your checkout page. There are many many ways to do this, it's really dependent on your overall needs.
If it were me, I'd have my own orders model. I want to be able to email people when they abandon a cart, offer an upsell, notice when they come back, etc.

leaden barn
#

I think there are many ways too. I have an express checkout element on the product detail page and the same on the /cart-page. When I am currently look at the views of the pages, there are nearly 200 that visit any product detail page... to create everyday nearly 200 or more paymentintents is easily possible for stripe, but I think they would suspense me... I mean 200 intents everyday and maybe 1 a week is used...

#

And then I have a huge problem :/

upper mauve
#

easily possible for stripe, but I think they would suspense me
I work for Stripe, we wouldn't 🙂

#

it's definitely better to optimize your code and have your own tracking/model, but really creating 200 PaymentIntents a day is nothing. I create more than this just by testing to help developers here 🙂

nova jayBOT
leaden barn
#

wow ok, than I will do it like that. You helped me a lot ❤️