#scif0642
silent oxide
harsh sphinx
That's because it hits maximum 10 times of confirmation
dreamy spruce
Don't really understand
I'm ok that PI can be cancelled but why customer try to attempt and on that particular attempt customer will receive a weird «wrong status» error
I want to catch a webhook and renew pi_secret_* prior to customer's next attempt
harsh sphinx
Look at its history, you can see it has been declined by the bank 10 times. At the 11th times you try to confirm it, it exceeds the limitation of 10
dreamy spruce
I'm asking why the cancelled event was fired after 11th attempt. Not after 10th unsuccessful
harsh sphinx
Because the limitation is 10. An attempt after that triggered the limit, marked the PI as cancelled, and triggered the webhook event
dreamy spruce
🤦♂️ But this is horrible 😦 Stripe knows that 10th attempt is the last chance and essentially any further attempts are prohibited. But don't send cancelltion webhook
I cannot find how to detect the time when pi_secret_* should be updated/invoice cancelled/etc
harsh sphinx
Sorry I don't get the issue. When you are at 10th attempts, you would know the next one will hit the limit, right?
dreamy spruce
Do you think this is a good idea to count number of failed payment attempts on my BE???
harsh sphinx
It depends. Let's take a step back. What you can not do after it hits 11th times and PI was cancelled? (or what do you want to do in the 10th attempts?)
dreamy spruce
To me it was expected that once PI become invalid (after 10th attempt), then Stripe should mark it accordingly.
Three options:
- i will try to create/initiate a new PI for the Invoice
- I will void the invoice and create a new one
- I will cancel the subscription and create a new one and provide customer with a new PI
harsh sphinx
Okie, but you can do it even after the PI is cancelled, right? What is bad about the PI is cancelled?
(I am trying to understand your scenario)
dreamy spruce
That dissolves the logic of work with Stripe — some pieces are offloaded to FE and others on BE. FE becomes aware on some Stripe errors and handles it on the FE
harsh sphinx
Sorry I don't really follow the last statement 🤔
dreamy spruce
How I can handle the case when customer tried to pay one more time but it failed? Only using handling the errors using JS
That means, FE must be aware how to handle these errors
Instead of that, if PI lifecycle would be more logical and my BE received a webhook earlier than customer just would be supplied with a new pi_secret_* string without requirement to handle specific Stripe errors.
@harsh sphinx , what strategy would you recommend to pay such subscriptions? It could be the case that customer has applied a coupon so subscription recreation would be not the best option, probably
I assume that invoice and PI could have some subscription specific details like e-mandate and something else, so probably manual invoice creation is not the best option
Ideally would be to have some PI rotation/renew mechanism to obtain a new pi_secret without subscription recreation
harsh sphinx
Trying to grasp your use-case, but I think you mean a Subscription, when it renew a new Invoice is created and a new PI is created, but declined by the bank
harsh sphinx
Okie, so after the decline, you can just reuse the client secret and let the customer provide a different payment method, If it ever gest into 11th attempts and the PI got cancelled, then redo another Subscription. But generally it should be very rare for a customers to have straights 10 different cards got declined
The specific PI you provided in the start, it looks like Customer retried a same card for 10 times
dreamy spruce
Some customers, probably a bit stupid 🙂 But I can see a few more same cases so want to handle such issues properly
harsh sphinx
I mean if they spam your UI 10 times with a same card, they are probably doing some weird stuff or trying to expoit or smthing. When you see the PI got cancelled, just get them back to previous page when you about to creat a Subscription, like resetting the flow