#brandontrytn_error
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1250485984928202796
๐ Have more to share? Add details, code, screenshots, videos, etc. below.
Hello! Can you give me a request ID showing this error? Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
I chatted a while ago with this same error. client is reporting this error again
let me check
unfortunately there does not appear to be a way for me to search for this in your logs
Where are you seeing the error?
the way we have it coded any error message that comes from the stripe sdk we pass through to the client
Your code should have access to the request ID in that case. See here: https://docs.stripe.com/api/request_ids
don't believe we log headers, but will check
Alternatively, can you give me a Payment Intent ID that experienced this error?
trying to get that info from the client now
would this show the error on an incomplete payment within their account?
It depends on the integration and other details.
based on the initial screenshot the total charge was 258.83, the 2 most recent payments are for that amount. an incomplete pi_3PQsXTC7aUEOHyHm0LVS3heJ and a completed one pi_3PQtyxC7aUEOHyHm0cNJ019s
but looking at those both on my end I don't explicitly see that error anywhere
Yeah, I don't either. So your platform is creating these Payment Intents on your connected accounts?
yes, they use our platform, have a connect account through us, we create the payment intent when they get to the review page to purchase. in this case it's a back-office purchase not customer facing
If you view the Dashboard as the connected account in question, then look in the logs, do you see one of the failed requests?
no, just a bunch of card declines for incorrect info or fraud or things like that
Hm. Is that the exact text of the error message?
Oh, I think I found it... it seems like it's actually a client-side error coming from Stripe.js... in which case I would still need the associated Payment Intent ID to investigate. Can you change your code so it logs the Payment Intent ID when this happens so we can then look at a specific Payment Intent?
actually, we might log that, let me check
so we do log all errors we get from stripe.js, we do not have any messages from it in the past 7 days
however we only log the error message so we wouldn't have the payment intent id
there is a third payment intent in the account recently for that amount pi_3PQsBCC7aUEOHyHm1t3nvJ98 but I do not see this in the logs on the dashboard
so client said this payment intent went through (pi_3PQtyxC7aUEOHyHm0cNJ019s) after it errored, so it should be one of the incomplete ones I believe
To clarify, that Payment Intent showed the error in your screenshot, but then went through successfully after that?
I cannot provide a specific one, based on the amounts in the screenshot those are the 3 payment intent ids. the client said it errored and then tried again and it went through. the one that went through was pi_3PQtyxC7aUEOHyHm0cNJ019s, the 2 incomplete with the same amounts, in descending time, are pi_3PQsXTC7aUEOHyHm0LVS3heJ and pi_3PQsBCC7aUEOHyHm1t3nvJ98. the pi_3PQsXTC7aUEOHyHm0LVS3heJ one was right before the success
said it happened 10:30am eastern time on 6/12
So, client-side, it sounds like you're using the deferred flow with the Payment Element, right?
we're using the payment element yes, not familiar with the deferred flow if you can elaborate on that
It's this approach: https://docs.stripe.com/payments/accept-a-payment-deferred
no, we create an intent on the server before rendering the review page, so the intent is created when it's time to collect payment
Basically I'm wondering what options you pass client-side when you call stripe.elements() to create an Elements session?
elements = stripe.elements({
appearance: {
labels: 'above',
theme: userPrefs !== null && userPrefs.isDarkThemeEnabled ? 'night' : 'none'
},
clientSecret: clientSecret,
locale: window.globalSettings.culture
});
paymentElement = elements.create('payment', {
business: {
name: $('#ShopName').val()
},
defaultValues: {
billingDetails: {
address: {
country: settings.fields.$country.val()
},
name: settings.fields.$name.val()
}
},
fields: {
billingDetails: {
address: {
country: 'never'
}
}
},
wallets: {
applePay: 'never',
googlePay: 'never'
}
});
paymentElement.mount('#payment-element');
Huh. I don't know what conditions would result in that error when you pass in the client secret of a Payment Intent, but then allow it to work again with the same client secret and no updates to the Payment Intent.
I recommend you add a lot more logging and try to figure out exact steps to reproduce the issue.
what specific information would you need to troubleshoot so I can ensure the logging does what's needed?
I believe we make an update call if there's already a payment intent on the cart if they were to refresh the page or make some other change
Mainly logging the Payment Intent ID when the error happens, and then log the Payment Intent ID again when it succeeds after that (to make sure it is, in fact, the same Payment Intent). And exact dates and times for all of that, to compare with API request logs.
and this would only occur from stripe.js, so I should focus on the logging in js, or can it also occur from the server?
And you shouldn't log the client secret itself, but you should add a check to make sure the Payment Intent ID you're logging matches the client secret being used (the client secret's first part is the Payment Intent ID).
This error happens client-side, so that's where the logging itself needs to happen, but the logs should be sent to your server so you can examine them afterwards/without customer involvement.
yeah for sure, ok I'll add a ton of logging and wait for it to happen again and then open another thread for next steps
Sounds good! We should be able to get to the bottom of it with more details and specific examples. ๐