#Jasperste

1 messages · Page 1 of 1 (latest)

thorny kettleBOT
safe tulip
#

hi

In the docs it seems like the id of the intent is set on create
Where did you see this ?

sterile sonnet
safe tulip
#

I don't see where you need/must set a PaymentIntentId ?

sterile sonnet
#

No sorry, it returns a paymentIntent on this response, but the response we get the payment intent is null

safe tulip
safe tulip
low trail
#

it's expected to be null, we only generate the PaymentIntent when the customer visits the page and starts paying

#

that was different in the past but it changed a dew months ago.

sterile sonnet
#

@safe tulip cs_test_a1AklMHstAtTP4A7QjOuEj7TanA1TUp6MLMG7vPUaJqddqbIOfxmytxJ8z

#

@low trail Ah thanks, that makes sense!

low trail
#

was there a specific problem you had?

#

you should only look at/use the PaymentIntent when handling the checkout.session.completed event after the customer pays

sterile sonnet
#

We are managing some session/payment attempt ourselves, so hence we wanted to keep track of some more info/details (for example for debugging) (we store the session id for example). We thought it would be good practice to store the intent id when creating the session. But we will then store it the first time we receive an event with the value set

low trail
low trail
sterile sonnet
#

We are listening for payment_intent.created, .failed and .succeeded events. But we get the order id from the metadata for updating payment status. But though it would be more sufficient to link to an intent id instead

low trail
#

We are listening for payment_intent.created, .failed and .succeeded events.
if you use Checkout, you must use the checkout.session.completed event, not the raw PaymentIntent events.

sterile sonnet
#

We are not sure if listening to checkout then makes sense for us in that case, but might be relevant. What would be the downside of listening to the raw paymentIntent events instead of the checkout.session.completed events?

low trail
sterile sonnet
#

Yes, the 'custom payment flow' option

#

Sorry, thought the link was a direct link to that selection

low trail
#

We are not sure if listening to checkout then makes sense for us in that case, but might be relevant
well if you're only using Elements then there's no point listening to checkout.session.completed. If you do use Checkout, you must listen to that event.

What would be the downside of listening to the raw paymentIntent events instead of the checkout.session.completed events?
for example if you use mode:setup CheckoutSessions there is no PaymentIntent and no events so you would miss that entirely; if you use mode:subscription, you are missing the context of it being a subscription/invoice payment since you're looking at the raw PI.

docs are https://stripe.com/docs/payments/checkout/fulfill-orders and this blog is also useful https://dev.to/stripe/purchase-fulfilment-with-checkout-or-wait-what-was-i-paid-for-335d .

sterile sonnet
#

Interesting.
So if we use checkout we should listen for checkout, if we use custom payment flow we should listen for payment intent events?

Note, we are not using setup or subscription currently

low trail
#

yes

#

we are not using setup or subscription currently
but you might later

#

and then your code won't work and you won't know why you're not tracking subscription creations or card saving because it's easy to miss the webhook

#

best to do it right from day 1, and all our docs everywhere say to use checkout.session.completed so that's what you would use.

sterile sonnet
#

But that's something we could tackle then right? We have test environments to prevent any customers ending up in states were events are missed.

#

We might also start moving to custom flow soon, so that would mean listening to session checkout would make less sense again

low trail
#

any other questions?

sterile sonnet
#

All right, I will check with the team

#

Checkout sessions is for us an intermediate step to building towards using Elements (which requires substantial more work). It's already used in production for quite some payments, without any troubles or missed events.

When working with Elements you have no session completed events to listen to and payment_intent.succeeded is the most reliable. Hence we already decide to listen to that one. We will probably build Elements first before considering Subscriptions or setup intents.

#

Hence we approached it in this way

sterile sonnet
#

Thanks for providing clarity about the API change for the payment_intent being null and thinking along.
We will consider moving to listening to checkout session events instead of to the payment intent, but need to be done in consideration with our roadmap to move to Elements as a whole.

Since otherwise we're have to change it, not gain much benefit from it (except needing to pay attention when adding subscription and setup), and then revert back to listening to the same events again due to us moving away from Checkout.