#davidbarratt_unexpected
raw rapidsBOT
👋 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/1327064985662394449
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
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.
- davidbarratt_3ds-deferred-next-action, 3 days ago, 23 messages
pale merlin
hello 👋 looking into this now
have you looked into using webhooks as a way of handling this case?
in general for any case where there is uncertainty server-side of when an asyncronous process will complete, you can just listen to webhooks for the relevant event and take action when you receive it
fleet ridge
yes we have, the problem is that the user will have to wait on the webhook in order to get the approriate redirect url
basically we cannot generate the redirect url (which is a Shopify restriction) until the payment is completely done.
the Stripe JS SDK tells us that it's done, but it's obviously not trustworthy, so my hope was that Stripe signed the payment intent with our server side secret, but that doesn't seem to be the case.
the best solution we can come up with is to accept the race condition and have the user hit a "Continue" button which will (hopefully) be enough of a delay for the replication to be done
the only other solution I could come up with, which is a lot more work, is to let the client open a request to the backend and leave that request open until we receive the webhook, but that's a lot of work and overhead.
I guess this is mostly a feature request to add signatures to the JS SDK so that we can push those resources (like payment intents) to the server and they can be verified on the server as not having been tampered with. We'll still use the webhooks just incase the client disconnects. But if the client disconnects the redirect url is meaningless anyways so that's totally fine.
I also wanted to make sure I wasn't missing something extremely obvious.
pale merlin
gotcha. yeah, i definitely understand the frustration with the potential disconnect between what you're getting from the two sources. i'm checking with a colleague to confirm a few things, and it sounds like this is an expected state where (due to replication lag, like you suspected) you may not get the exact same response from the get a payment intent API until we fire the webhook event