#salteesam
autumn wadiBOT
Hello! We'll be with you shortly. 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.
- salteesam-terminal-busyerrors, 1 day ago, 32 messages
mild pelican
Hello! Sorry, not sure I understand. Terminal is our product for taking in-person payments, and Smart Retries are what we use to retry failed recurring payments. They're not direclty related to each other. Can you clarify?
dawn void
oh! maybe i'm misunderstanding. we are using terminals. and after a failed payment attempt on the terminal. stripe will sometimes automatically retry (asks the end user to try paying again)
we need to know when stripe will be trying again, and when they don't. i haven't been able to find any consistency or info online. I assumed it was using "smart retries" but that must not be the case
mild pelican
Okay, so someone attempts to pay with a Stripe Terminal reader, the payment fails, and the reader prompts them to try again?
dawn void
yes exactly. are there specific failure codes that will always retry? or is it based on something else (the status of the payment intent etc...)?
mild pelican
I thought Terminal would always prompt them to try again upon failure...
Are you using the server-driven integration?
dawn void
yes server-driven
does it retry even when the failure code is a connection error or api error?
i was just reading the note here:
In the case of a declined card, prompt the customer for an alternative form of payment. Use the same PaymentIntent in another request to the process_payment_intent endpoint. If you create a new PaymentIntent, you must cancel the failed PaymentIntent to prevent double charges.
For card read errors (for example, an error reading the chip), the reader automatically prompts the customer to retry without any notification to your application. If multiple retries fail, you can prompt for another payment method by making another process_payment_intent request.
and the docs make it seem like we need to re-send (re-prompt) the user with the payment intent - but it does seem to do that automatically. which is why i was confused as to when it does and doesn't do that
mild pelican
Well, there are different kinds of failures that can happen, and it depends on how your integration works. Can you give me an example of a failure that retries and one that doesn't?
dawn void
i'm just runnign to a meeting but will be back in an hour or so and i'll find some examples