#gratte-idepmotency-afterpay
1 messages ยท Page 1 of 1 (latest)
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- gpratte, 4 days ago, 9 messages
Hi ๐
So this only occurs when you use the AfterPay sandbox, right?
yes
I'm still developping the integration, we have not used AfterPay in production yet.
Yeah, unfortunately we don't control that sandbox (it's AfterPay's code) and there have been plenty of rough edges working with it.
Which event type are you having issues with?
payment_intent.payment_failed
Thanks, taking a look
Okay wait. I know the issue
AfterPay is async. So when a payment fails we don't have a request object that directly ties to it. Since there's no related API request there isn't an idempotency key.
The same would be true for a us_bank_account payment method, where the payment can fail asynchronously
Ok, noted. Could you guide me then on how to receive the failed event for an async method of paiment? An URL to the doc for example.
I'm not sure I know what you mean. Even with an empty request hash, the event should still validate using our SDK methods.
I'm using the Python stripe SDK, version 5.2.0, and it raises the following on event validation:
Event evt_3OfS4MKLq4FC4XUF1gVGn6id is missing idempotency in its request.
Should I try more recent version of the lib just in case?
Here is an example of how you should be validating your webhook events: https://stripe.com/docs/webhooks/quickstart
Does your code look like this?
Yes, I'm calling:
stripe.Webhook.construct_event(payload, headers["stripe-signature"],
endpoint_secret)
oh, my bad, the idempotency validation is in our code, not Stripe's ....
sorry about that, I should have debugged a bit more before jumping to conclusion.
thanks for your help!
No worres! Somtimes it takes having to explain your code to see where the bug is
we are using the idempotency key in our code though to avoid processing the same event twice
we put that key into a Redis structure so we know if we have seen that event yet
would you have a suggestion to replace that idempotency key?
That makes sense. In this case the request, which has the idempotency key, is the request to confirm the payment
https://dashboard.stripe.com/test/logs/req_7d4ZfL5tFGl1r1
gratte-idepmotency-afterpay
If I understand that would be the POST request made by Stripe Checkout itself when the user press the Pay button?
Correct. that is what happening here
I'm not sure how to connect the dots from the info you provided. I don't think I have a direct access to that request data, and I'm not sure there is an event who contains it.
In this case there were two events that fired for this request. payment_intent.created and payment_intent.requires_action
If I follow I would need to generate the idempotency key based on some data from one of these events?
That doesn't make much sense. There isn't an idempotency key to be generated since it's not a request your server made to Stripe.
If you "created" one it would not have much meaning as far as the Stripe API is concerned, since it is not related to an API request
Let's try to get back to the start then. I would like to be able to do some action on my end when the AfterPay payment fails. Time is not sensitive -- it can takes minutes before I receive the event. However having an idempotency key would help. What would be your recommendation for that case?
However having an idempotency key would help
What purpose does this serve in this instance?
As I told the purpose is to avoid handling the same event twice, as suggested in the Stripe documentation.
In that case I would store the event ID
I'd like to have the superpower to read mind, but that has not occured to me yet in my life. Could you be more specific, give more details or context in your answers?
oh I guess you mean the id of the event, such as evt_3OfS4MKLq4FC4XUF1gVGn6id..
You don't want to handle the same payment_intent.paymet_failed event twice, correct? If we re-sent the event it would have the same event.id value https://stripe.com/docs/api/events/object#event_object-id
Therefore, if you store that value in your DB, before you take action on the event you can check if you have already seen it.
that makes sense
๐ Making sense is quite an accomplishment when digging into the ins & outs of API and all our tooling ๐
I'll go with that suggestion. Thanks for your support and patience. I must admit I lost mine when I submitted that quirky remark about reading mind, sorry about that. Have a nice day!