#tannerhuynh_api

1 messages · Page 1 of 1 (latest)

empty shaleBOT
#

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

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

fervent citrus
#

HI 👋

So you want to actually receive an error in the Express Checkout Element? Like as if a user provided a bad card through Google Pay?

vast forge
#

Yes, but at the moment we are trying to test Link payment.

fervent citrus
#

Okay

vast forge
#

We have tried all the different permutations of testing cards with fraud or decline, but it does not seem to trigger the error state from the confirmation token.

fervent citrus
#

So when you are prompted for the one-time password for Link, what values are you using?

vast forge
#

I've used the 000001 - 3 values but that is an inline error instead of an error during the token creation.

fervent citrus
#

Confirmation Token creation by itself does not perform validation so we wouldn't raise an error there

vast forge
#

Is it safe to assume that it will raise one of the 400 - 500 errors with a error.type key value?

#

Although atypical, we are just trying to square away QA testing use cases. If the only error we will see is load testing / down time, then we can avoid testing it.

fervent citrus
vast forge
#

Under confirmation token creation I see..

if (error) {
// This point is only reached if there's an immediate error when
// creating the ConfirmationToken. Show the error to your customer (for example, payment details incomplete)
setErrorMessage(error.message);
}

But there seems to be no documentation on what to expect for errors and what the error payload would be.

fervent citrus
#

That is a good point. I can raise this internally. Do you think it would make more sense to document which types of errors will be raised here or have a test payment method that will trigger these errors?

vast forge
#

I think it would be very helpful to have both. When testing for QA but for developing error states in the UI. We are expecting an error, but we want to have our own translation for users speaking different languages. Since we don't know specifically what to expect for the payload, we aren't able to determine what to show to the user.

#

I see in https://docs.stripe.com/declines that there is a resemblance of a payload, but I don't know if that is the same structure being used across all the error states.

fervent citrus
vast forge
#

Yup. okay thanks!