#liam-hunt-bonterra_code

1 messages · Page 1 of 1 (latest)

low fulcrumBOT
#

👋 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/1324468567709716561

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

undone nestBOT
low fulcrumBOT
stone mist
#

Hi 👋 I don't think you should do any filtering of errors there. Are you using an approach similar to what we show in our guides where all errors are passed to handleError?

slim ferry
#

Hi! That's right, I'm using something like handleError where I take the error string and show it to the customer in a banner.

#

My reason for thinking I should deviate from the approach of always calling handleError is: when const { error: submitError } = await elements.submit(); errors, it appears Stripe automatically shows a validation message on the PaymentElement? And I would prefer not to display the same error message twice

#

In this scenario, it looks like StripeJS automatically red outlines the card input and shows a red text error message

#

Also - and I'm likely overthinking this - the typescript type for StripeError says

 /**
   * A human-readable message providing more details about the error. For card errors, these messages can be shown to your users.
   */
  message?: string;

which suggests that non-card errors should not be shown to the user. But again I might be reading too much into it

signal cave
#

Gotcha, that is a good point. I am looking in to what guidance we have on this and will get back to you with what we can find.

slim ferry
#

Thank you! A bit more context - my company is touchy about showing customers messages with either too much info about either technical systems (things like "API limit reached"), or information that could be helpful to card fraudsters

signal cave
#

Yeah definitely a good thing to consider. We do generally try to design things with that in mind. It is helpful for you to have informative error messages but confusing if a user sees one that isn't relevant to them. From my testing, the error definitely can be redundant to something that is already shown in the payment element. I am checking to see if there is a good consistent way to check this in our error response. If not, definitely raising some feedback about this.

slim ferry
#

👍 thank you again!

signal cave
#

In our reference for the confirmPayment call we do directly say that card_error and validation_error errors can be shown to users, but the error from my test is a validation_error. It does sound like you can definitely avoid showing errors of type invalid_request_error, as those are more API focused.

If the confirmation fails, the Promise will resolve with an {error} object that describes the failure. When the error type is card_error or validation_error, you can display the error message in error.message directly to your user. An error type of invalid_request_error could be due to an invalid request or 3DS authentication failures.
https://docs.stripe.com/js/payment_intents/confirm_payment

I am going to consult my colleagues on this. If we can't find anything now, we may need to create a ticket so I can raise this to the team that works on elements and get back to you later.

Stripe JS Reference
signal cave
#

Yep as far as we can see that error message will always be redundant for the payment element and express checkout element. I am actually not immediately sure why we return the message and specify that in the docs. I'll raise this so we can review and clarify

slim ferry
#

Thank you - to clarify "that error message will always be redundant" that refers to any error message returned by const { error: submitError } = await elements.submit();? Of all error types?

signal cave
#

Correct

slim ferry
#

Thanks! So then errors thrown by

await stripe.createConfirmationToken({
    elements,
    params,
  });

do are not shown on the StripeJS elements automatically

signal cave
#

I don't think so but am looking in to it.

slim ferry
#

Ty! Don't intend to rush, just want to make sure I'm confident I understand the findings 🙂

signal cave
#

Oh of course, I am honestly a bit surprised at myself that I never thought of these questions.

low fulcrumBOT
signal cave
#

From what we can see, you are correct that createConfirmationToken will not effect the payment element. So I think the rule from the doc where you show errors other than invalid_request_errors should make sense there. Though as far as I am aware any validation type error should get caught by elements.submit so I'm not sure if it ever will return an error that needs to be shown.

slim ferry
#

Ok! I think this gives me most of a working approach

  1. Don't show errors from const { error: submitError } = await elements.submit(); as they show in the PaymentElement or ECE
  2. Show errors from createConfirmationToken if they are of type card_error or validation_error, though the latter might never happen

For 2, just clarifying that the typescript type StripeErrorType has items other than card_error, validation_error, invalid_request_error. So "show everything but invalid_request_error" and "show card_error or validation_error" aren't the same

viscid kelp
#

Hello! I'm taking over and catching up...

#

If so, how you handle these is entirely up to you. For example, an API connection error might be something you want to log in detail internally but show to your customer as a more generic error. A card error, on the other hand, can be shown directly to your customers.

slim ferry
#

Ok. The question is exactly which types of errors I can safely show to my customer - it sounds like to the answer to that is card_error or validation_error?

viscid kelp
#

That depends on what you definition of "safely" is. Safely as in you won't disclose sensitive information? Safely as in the customer is likely to understand the error message? Something else?

slim ferry
#

I would say I'd want both of those things to be true in order to show the customer a message

#

Like showing them some generic non-stripe-generated string unless the message is something the customer could both understand and fix themself

viscid kelp
#

In that case you'd want to show them card errors, validation errors, and maybe API connection errors (it's possible the connection issue could be on their end and might be something they can fix).

slim ferry
#

Ok, thank you! I think this answers all my questions.