#wjq8g6_best-practices
viral gyroBOT
đź‘‹ Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đź”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1372366095918301327
đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.
amber bramble
We've implemented retries and other checks to reduce the chance of the Place Order call failing to be sent, but we are still seeing this issue pop up, possibly due to users closing the app immediately after payment.
Since users would think that their payment has gone through (uncaptured payments still show as pending on Apple Pay), they would think they have paid for an order even though it's not the case.
slow needle
hello! So regarding this bit :
We are seeing that due to spotty networks, Step 4 (sending the order to the backend) sometimes fails and the payment is left uncaptured
Are you listening to webhooks also to capture the order? It's a bit hidden, but mentioned in this section https://docs.stripe.com/payments/place-a-hold-on-a-payment-method#capture-funds
Additionally, when a customer completes the payment process on a PaymentIntent with manual capture, it triggers the payment_intent.amount_capturable_updated event. You can inspect the PaymentIntent’s amount_capturable property to see the total amount that you can capture from the PaymentIntent.
amber bramble
Not at the moment, though that was one of the solutions we thought about, some sort of timeout that would automatically cancel any uncaptured payments after X minutes that is started by the webhook
slow needle
i'm a bit confused about why you would want to automatically cancel any uncaptured payments though
you can use the webhook to trigger a capture if it hasn't been captured yet, no?
amber bramble
If the payment was left uncaptured, that means the additional business logic (i.e injecting the order into POS) wasn't ran either.
And that could fail for other reasons
slow needle
you can't trigger that additional business logic too?
maybe it requires some refactoring of your code to do so. The way I would envision it to work is a two-pronged approach for this - either process the order from the client callback or handle the corresponding webhook for a successful order. Once you process one of them, you can disregard the other.
You would handle this logic with a queue system where you can retry it if necessary, and if it fails for certain reasons you can cancel the uncaptured payment
amber bramble
I see, there's a good amount of data that we currently pass through for that place order call to the backend. Would we be able to store that via metadata on the payment intent?
slow needle
yep, but as always I recommend testing things out to be certain it all works as expected since we (Stripe) don't have full insight into your systems
amber bramble
Yep, let me think about that approach a bit more. Are there any other alternatives you would suggest that we look into? We discussed moving the paymentIntent confirmation to the backend as well but that seems to have other negatives (like needing to handle payment errors or additional verification on the backend and sending that to the frontend)
slow needle
we don't really recommend using server-side payment confirmation for those reasons that you mentioned...