#zepher2211-token-error

1 messages · Page 1 of 1 (latest)

rancid cliff
#

The best option really is to assume all errors can be raised by all APIs and just handle the specific ones you care about and treat all others as a generic error

tropic spire
#

I'm fine with that, but it's hard to know which specific ones I'm interested in if there isn't any information available about what that type of error is

rancid cliff
tropic spire
#

That page does contain a lot more information, it's still missing information about validation errors but I can probably show those to users

rancid cliff
#

What do you mean "validation errors"

#

I'm sorry but can you provide a bit more details on what is blocking you? Maybe share exact code and what you are trying to do?

tropic spire
#

One of the types a StripeError can have is validation_error, but there's no StripeValidationError or that type of error mentioned anywhere in the documentation.

For an example of an occasion you'd get a validation error, if you submit an invalid card number to the form you'll get that kind of error.

As for what blocking me, it's that I don't know exactly which errors will contain user friendly messages in their error, and which should only be seen by developers.

rancid cliff
#

One of the types a StripeError can have is validation_error, but there's no StripeValidationError or that type of error mentioned anywhere in the documentation.
what does that mean?

#

I'm really sorry, you likely are deep in something and think it's obvious context but I'm totally lost

#

I'm going to venture a real guess and this has nothing to do with our API and you're talking about Elements validation maybe?

tropic spire
#

Okay, so just starting from the top to try to get some context:

These errors I'm working on either displaying to the user and not reporting, or not showing to the user and reporting back to our error recording software come from both Stripe's createToken (https://stripe.com/docs/js/tokens_sources/create_token?type=cardElement) which we use with card elements but also to create bank account tokens. I'm also working with possible errors in response to stripe.confirmCardPayment (https://stripe.com/docs/js/payment_intents/confirm_card_payment), but the types in the type declaration (Typescript if you aren't familiar) show several error types that aren't in the documentation.

I'm trying to figure out which error types to display the error messages of directly to users, so that's why I'm here since the information wasn't in the documentation. The first link you sent contained more information than the API reference, but it still doesn't say anything about the validation error type shown in Stripe's type declaration.

#

You don't need to apologize, I'm the one looking for help haha

rancid cliff
#

all good

#

I'm still lost

#

Card Element is to collect card details (and kind of deprecated). We don't have an element for bank account details. What's the context, what are you trying to do, what's blocking you in typescript

#

any chance you could provide a lot more specific details and a specific question?

#

you seem to look at this both from a high level "let's handle errors" and also a really specific "I'm doing code X line Y and getting a type error" but not sharing the last bit

tropic spire
#

That's because it's a private repo, sorry for the weird back and forth

rancid cliff
#

all good, can you just share some bit of code?

tropic spire
#

createToken to create bank account tokens while supplying data I collected myself, I don't use any particular stripe elements for that, only for creating the card tokens. I'll work on putting together an example.

# 
// Use your card Element with other Stripe.js APIs
const { token, error } = await stripe.createToken(cardElement, {
    name: nameOnCardGetter.current?.(),
});

// Handle error
if (error) {
    // Is this a customer reable error?
    if (error.type === 'card_error' || error.type === 'validation_error') {
        setErrorDisplayingState(error.message);

        return;
    }

    // Report unknown errors
    Sentry.captureException(error);
}

There's a really short example specifically for card tokens

#

That line error.type === 'card_error' || error.type === 'validation_error'
is the one at contention, I'm just sort of guessing I can show users all validation_error
type errors because its not mentioned anywhere in the documentation that I've found

rancid cliff
#

okay that helps a lot

#

I'm still not fully grasping what is the problem though

#

validation_error is raised when we validate something in Elements and it's incorrect. Like if you type 09/21 as the expiration date

#

what are you looking for exactly? Because the code you have is fine, you mostly display the error message and that's it

tropic spire
#

Yes, I've deduced as much as well about what validation errors are, but there isn't any documentation that says explicitly that those errors can be shown to users like there is for card errors, and for several other error types for which there is no documentation at all I'm just treating them as unknown because I can't find any information about those error types. I came here to see if anyone could shed more light on those types that there's no documentation for.

#

The full list according to Typescript is: "api_connection_error" | "api_error" | "authentication_error" | "card_error" | "idempotency_error" | "invalid_request_error" | "rate_limit_error" | "validation_error" but the documentation only talks about api_error, card_error, idempotency_error, or invalid_request_error

#

I'm satisfied enough with showing the validation errors and not showing the errors I don't know anything about for now

rancid cliff
#

Yeah that's because the docs are explicitly about the API

tropic spire
#

But that was why I was here anyway

rancid cliff
#

Here you don't use our API, you use a client-side library (Stripe.js / Elements) and that has its own error handling logic. It can raise the real API's errors (since under the hood it will call https://stripe.com/docs/api/tokens/create_card) but it can also raise its own errors, where it validates data ahead of time (before even calling our API) and return the error

#

the validation errors are meant to be customer-facing, so yes you would surface those directly to the customer in that case!

tropic spire
#

That's frustrating, because the js docs link to the api docs for learning about "all the types of errors"

#

See the "Returns" section under this link to see what I mean

rancid cliff
#

yeah that's fair

#

Part of it is that you're using a really old API/integration

#

we rebuilt this a while ago, we have a brand new UI called PaymentElement that mostly handles all of this for you and displays the UI errors for you too

#

but I agree we could improve this!

tropic spire
#

I'll look into that and see if it fits our needs, when we are using this code we handle the payment on the server so that might put a wrench in using that component.