Soundsounds

[dreamy oak]

Hi 👋 can you elaborate on what you're hoping the flow you want to build will accomplish? What is your desired outcome when you change the amount of a price on your end?

[bitter gorge]

Hi Toby! Here's the scenario:

• A customer opens the app and adds a product to their cart
• While the customer is finishing up their order, the price of that product is changing in realtime.
• At some point during the checkout flow we want to either:

(a) Lock-in the price for a set amount of time e.g. 5 minutes to give them a chance to check out at the current price

or

(b) Display a static price on the checkout page, and if that price changes behind-the-scenes in the seconds between viewing the quote and confirming their payment, we warn the customer at the point they click 'Pay' that the price has changed. In this case we would ask if they accept the new price. If yes, payment completes at the new price, or if no, we return to the checkout and display the updated quote.

or

(c) Update the price live on-screen, perhaps with a UI element to notify them that the price has changed, so they must acknowledge the change before proceeding

There might be further options that we haven't considered, so it'd be great to hear your thoughts - is there a preferred/standard way of dealing with realtime pricing? Are both of the above options possible?

We're currently somewhat undecided which of the three are best for us, and what's possible/easier technically will play a part in that decision

[dreamy oak]

Gotcha, I don't think I've worked with anyone implementing this type of behavior before, so I don't have a recommended approach for it.

Building any of the above options is going to be complex.

Part of that is because using the Payment Element typically means you're working with Payment Intents, which are not directly related to Price objects.