#Nyxi

1 messages · Page 1 of 1 (latest)

limber sageBOT
tender crag
bronze quest
#

Alright, and when a payment intent is confirmed with capture: false, it moves to requires_capture and fires the payment_intent.amount_capturable_updated webhook, correct?

#

(instead of succeeded and payment_intent.succeeded)

tender crag
#

That is correct.

bronze quest
#

Good

#

Thanks

#

Can I determine from a payment intent if it went through asynchrounous payment or went directly to succeeded/requires_capture?

#

I need to ignore the webhook if it didn't require any action

#

next_action null?

tender crag
#

yeap, you can look at next_action

bronze quest
#

And it will retain its information even after the payment intent has moved to requires_capture?

#

At which point there is no next_action

#

Because you already did that

#

Assume I'm fetching the payment intent after receiving payment_intent.amount_capturable_updated and I need to know then if it required action or not to reach that stage

tender crag
#

I'm unsure if you're using this as a rubber duck or if you had a specific question.

bronze quest
#

It was a question

#

If a payment intent that had next_action retains this after moving past said action, so that it can be inspected after to determine how and if it went through the async flow

#

The docs say "If present, this property tells you what actions you need to take in order for your customer to fulfill a payment using the provided source." - implying something needs to be done now, not that something was done in the past

tender crag
#

I see, looking on my end to see how you'd achieve this

bronze quest
#

It's because I have a combination of:

  1. order costs no money, so Stripe is not involved and no payment intent can be inspected (100% discount coupon code for instance)
  2. order costs money but requires no next_action, so it can move directly to order handling
  3. order costs money and requires action, so webhook needs to complete it
tender crag
bronze quest
#

But it's always in requires_capture

#

so I'm not sure how this helps

tender crag
#

Can you confirm why you'd want to know this? Trying to see what your use case would be?

bronze quest
#

Yeah so, I have a flow like I explained above, where I'm either doing synchrounous completion of the order because Stripe is not involved, so there is no webhook to do it, or I am doing synchronous completion because no next action is required or I am doing async completion because action is required.

After payment completion, I capture the charge. I have to do this because of race conditions (it's a ticketing system). For this, I listen to the payment_intent.amount_capturable_updated webhook and I complete the order when I see this. But I should not be doing that in the case where there was no next_action, because the payment will already have moved to requires_capture synchronously. The webhook will fire in both cases, and if I just check the status, it might still be requires_capture when the webhook comes in, if I capture it synchronously (later) in the request that also created it

#

It's a little bit hard to explain

#

So I need to know in the webhook if the payment intent was sent through an asynchronous payment flow. If not, I can discard it

onyx scaffold
#

👋 taking over here

bronze quest
#

Greetings

onyx scaffold
#

Sorry kind of lost in your last explanation. So you have 2 cases: without next_action and with next_action, correct? But that should all before requires_capture AFAIK

bronze quest
#

Yes, but if there is no next_action, the payment intent goes directly to requires_capture

#

and it will fire the webhook in that case as well

#

and I don't know if it will trigger next_action or not when I create it

onyx scaffold
#

With next_action, it will comes a bit further road but eventually goes to requires_capture eventually

bronze quest
#

I know. I'm saying that if no action is required, it will immediately move to requires_capture and also fire the webhook, which I won't need if this happens.

onyx scaffold
#

Which webhook specifically?

bronze quest
#

payment_intent.amount_capturable_updated

#

I suppose what I could do is always handle it asynchronously with webhooks, even if no action is required

onyx scaffold
#

if no action is required, it will immediately move to requires_action and also fire the webhook
I didn't get this part. If no action is required then it won't move to require_action for sure

bronze quest
#

sorry, requires_capture

#

My mistake

onyx scaffold
#

Okie then yes correct. So when payment_intent.amount_capturable_updated is fired you have no way to know if it came through requires_action or not

#

Generally it should be fine for not knowing that (regardless of if your customer is challenged, they already paid and now it's up to you to capture)

bronze quest
#

Okay, so the issue then is how the webhook will know if it needs to handle the order (and capture it) or if this is being done by the same request (to our server) that created the payment intent.

#

And I suppose this is where I could just have it always go through the webhook, even if no action was required; then it should be the same either way

#

If that makes sense

onyx scaffold
#

you mean you will need to handle the require_action status? There is different webhook for it: payment_intent.requires_action

bronze quest
#

No, requires_capture

#

Webhook captures the charge and completes the order

#

But if no async payment took place (requires_action -> next_action), the webhook should be ignored because the order was captured synchronously by our server when it created the payment intent

onyx scaffold
#

because the order was captured synchronously by our server when it created the payment intent
The best approach is to remove this logic and instead move all order fulfillment over webhook. Think that your customer may accidentally close their browser, or lost internet connection, or they are in a train went through a tunnel, you will lose them in your synchronously flow anyway

bronze quest
#

But if they close their browser it won't matter as the server is doing the capture?

#

so they would return to the page eventually (and receive emails etc.) and see that their order has processed

#

I also need a synchronous flow for when there is no payment (no charge), because I won't get a webhook then, so I can't really scrap it entirely

onyx scaffold
#

Your client will confirm first, right, then after that send the id to your server to capture.

#

(are your confirming from client?)

bronze quest
onyx scaffold
#

So what if it finished confirmation but never been able to send the id to your server? (Your server won't receive anything to capture)

bronze quest
#

The webhook would do it then. So this would require I always pass confirm: false when creating the intent, yes?

#

I think I may have gotten requires_confirmation and requires_action mixed up a bit.

#

We want there to always be something to send to the client, regardless if it's with a next_action or not, yes?

onyx scaffold
#

So this would require I always pass confirm: false when creating the intent, yes?
You can simply don't pass anything. confirm=false is the default behavior

We want there to always be something to send to the client, regardless if it's with a next_action or not
Sorry don't really follow this

bronze quest
#

Yes, I know, I was just being explicit about the parameter being false.

I mean that when I do confirm: false, the payment intent will never move directly to requires_capture on the server, it will always go to requires_confirmation, which the client can handle and do requires_action if required, after which I get my requires_capture webhook.

onyx scaffold
#

Ah yes. That's good because ideally you always need the client in case there is requires_action

bronze quest
#

Alright, cool

#

I'm sorry I've just worked on this all day. It's an implementation that has lived on Stripe since before Payment Intents, and now it needs to be moved exclusively to async flow in order to support various payment methods that don't support confirmation_method: manual, so it's getting me a little confused sometimes, even though I know the API fairly well

onyx scaffold
#

Np! Take a good rest 🙂

bronze quest
#

No rest for the wicked