#dev-travis_docs
1 messages · Page 1 of 1 (latest)
đź‘‹ 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/1442844356997414964
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
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.
- dev-travis_docs, 6 days ago, 5 messages
hey there đź‘‹ when an attempt to complete a payment fails, the PaymentIntent moves to a requires_payment_method status, and you can attempt to retry the payment using the same PaymentIntent: https://docs.stripe.com/payments/paymentintents/lifecycle
the only scenario where you'd need to create a new PaymentIntent is if the status is canceled (for example, if you cancel it via the API, or if the associated invoice is voided)
https://docs.stripe.com/api/payment_intents/cancel
is there a specific scenario you have in mind where you think you might need to create a new PaymentIntent?
Yes, I have a few more questions.
Hey, taking over here. Let me know if there's any follow-up Qs I can answer!
In our backend, we have three transaction statuses: success, failure, and pending.
When a transaction is created, we initially set its status to pending.
If the transaction fails due to payment-related issues—such as insufficient funds, incorrect PIN, etc.—we update the status to failure.
However, some errors come from the SDK on the client side, such as “developer mode enabled” or similar issues. In these cases, we show the related error message to the user, but the transaction status remains pending on our backend.
However, some errors come from the SDK on the client side, such as “developer mode enabled” or similar issues. In these cases, we show the related error message to the user, but the transaction status remains pending on our backend.
can you share more details ?
like what?
Like what makes the status update in your backend ? Are you missing a webhook event for example ?
just a min
just charge 'success' event and paymentIntent 'failed' events and paymentIntent 'cancel event' are availabe and can update status.
We need more details here to help you see what was the issue
What is the PaymentIntent Id you are referring to? What is the Event Id you were expecting to get and you didn't received in order to update the status in your integration ?
in Tap to Pay react native SDK when we collect pin if device developer mode enabled or screen recoder active or accssebilities enabled etc payment failed,
how to recieve this event in our backend?
how to recieve this event in our backend?
You need to catch this from you ReactNative SDK and then call your backend (via a custom API) and update the transaction
There won't be a webhook event for that particular use case
đź‘‹ If you want to cancel a Payment Intent on the Stripe side, you can cancel it with this API call: https://docs.stripe.com/api/payment_intents/cancel
There's no status specifically called failure for Payment Intents. I think canceled is the closest to what you're looking for: https://docs.stripe.com/api/payment_intents/object#payment_intent_object-status
So in this situation, how can we know whether the user canceled the payment manually or the payment failed because of developer-mode-enabled?
You can pass a cancellation_reason to the cancel call which will populate the cancellation_reason on the object which can be used to identify it