#mike35x95x1 - thread
urban bridge
ok, we have 2 flows
- the customer pays an order with a new card (off session)
in this scenario I create checkout.session (with paymentIntent inside) and we store this cardId in our database
- once new order is created it can be paid automatically by this card
so I create paymentIntent with confirm: true
these flows were suggested as a good cover for our needs
the second flow is driven by a queue management and the charge is initiated 36 hours before the order is due
but if the customer pays the order by a new card simultaneously with the automated task from the queue he can be charged twice. is there a way how to avoid it?
and @mighty quiver mentioned these two flows are uselessly complicated and he wanted to suggest another solution but it was busy time and it took so much time that I left my notebook and the thread was closed... 😦
...and I am waiting again for the response...
urban bridge
I've been and I will 🙂
buoyant knot
If you already have a payment method saved, then creating a paymentIntent with confirm: true is the correct approach.
I'm not sure I follow that part:
but if the customer pays the order by a new card simultaneously with the automated task from the queue he can be charged twice. is there a way how to avoid it?
urban bridge
I have finally found the "idempotencyKey" which could be a solution for us. We would include this key in all payment requests linked to the order so there should not be any conflicts.
urban bridge
I'm not sure I follow that part:
> but if the customer pays the order by a new c...
to explain better: we sell software subscriptions (and yes I know you have subscription feature 🙂 but we want to try it without). there is cardId saved on the specific license and the system charges the customer periodically
if the periodic charge will have the same idempotencyKey as the manual customer payment we should be safe, right?
but my main issue is that @mighty quiver expressed opinion that our existing solution of the flows is complicated and promised another solution... I would like to know the solution and/or where is the problem. the flows were developed according to suggestions from your staff
buoyant knot
The main flow you described is fine:
- Collect PaymentMethod with a Checkout Session
- Then for next paymens reuse the PaymentMEthod with
confirm:true
What I don't understand is why you would have both happening at the same time.
urban bridge
I am trying to explain... 🙂 imagine you have a subscription of a product in our database and you purchased "first month" with a card1. the system knows the card1 and will charge you 36 hours before the next subscription renewal date. but the customer decides to pay next month with (new) card2 and uses the previous flow by entering the card2 details (so we initiate the checkout session). he starts the flow and while being on the stripe page (and entering the card details) the automated renewal system will change the card1. meanwhile the customer finishes the card2 details and submit. there will be two independent charges, right?
buoyant knot
Got it! Well that's something that you need to prevent on your end. For example once you already have a saved payment method for a customer, don't allow them to create a new Checkout Session.
urban bridge
ok, we'll do it - just wanted to know if the idempotencyKey would not be a solution...?
and the second thing - the @mighty quiver's comment about our solution. is it or is it not a good solution?
buoyant knot
idempotencyKey use case is quite different, you use it when you are making an API call but you don't get a reply from Stripe, so you are not sure if the request worked or not.
is it or is it not a good solution?
Like I said, your overall flow is totally normal (checkout session + confirm:true). The only strange part is that you allowed both flow to happen at the same time.
urban bridge
btw is it possible to "checkout" existing paymentIntent?
meaning I would create a checkoutSession and link it to an existing paymentIntent...?
buoyant knot
No, not possible.
vital basin
Hi there 👋 I'm jumping in as my teammate needs to step away. Having these two flows that could run in parallel sounds like a race condition that you'll need to build guardrails for on your end.
For instance, if you're using Checkout Sessions then you code that is creating those sessions could first check with your automated task to make sure it isn't running, or could even tell the task to run for a particular customer/subscription.
Another approach we have for creating a Payment Method that can be used in the future is to use our Setup Intents with the Payment Element. This guide walks through that:
https://stripe.com/docs/payments/save-and-reuse?platform=web
urban bridge
ok, we'll take a look. thank you
vital basin
Any time!
urban bridge
I can see there is an amount in the flow but we don't have any amount as we want to create just the card reference. am I missing something?
vital basin
Are you referring to Step 7?
vital basin
Correct, that step is about making a payment using the saved payment method later, it does not need to happen immediately after saving the card.