maks.piechota

[winged pendant]

Yes that's for renewal. More reference here https://stripe.com/docs/billing/subscriptions/webhooks

[lone socket]

so considering my use case:

1. access to product only when the subscription is active
2. renew the limit every time the subscription is paid

is it enough to:

1. check if the subscription has status 'active'
2. listen to invoice.paid webhook

or should I be aware of anything else?

like cases when the payment fail: I can see there is a webhook, but do I need to care about it? Isn't it enough to simply check whether the subscription state is active?

[winged pendant]

You should be aware of when a payment fail, to recover your customer transaction. It will help maximize your conversion rate

If you don't ,simply there will be some customer struggle to pay and you lost some sales

More here https://stripe.com/docs/billing/subscriptions/webhooks#payment-failures

[lone socket]

if the payment fails, can I simply get rid of subscription reference from my system and make the customer to create one one (where he can provide new payment details?)

[winged pendant]

Yeah you can do that but you will lost the history of the old Subscription

[lone socket]

will I?

wouldn't it be

there in stripe ?

attached to the customer?

[wild wave]

The Subscription object will still exist yes but it will be unrecoverable

[lone socket]

what does it mean?

[wild wave]

What does what mean?

[lone socket]

'unrecoverable' subscription

if I simply create a new one, do I need to care about the old subscription other than readonly access for history/audit by admin purpose?

which could be done by the admin in the stripe dashboard?

[wild wave]

Once they're 'deleted' they can't be reactivated, so you'd need to create a new Subscription

[wild wave]

You shouldn't need to, no

[lone socket]

but I don't want to delete it

from Stripe

I simply want to delete the reference (subscriptionId) attached to the user from my database

in order to force the user to create a new one

[wild wave]

Delete is the term/endpoint for cancelling the subscription. The actual record of the Subscription isn't deleted from the API

It just transitions to status: 'canceled': https://stripe.com/docs/api/subscriptions/object#subscription_object-status

[lone socket]

oh, ok, so if I get payment.failure webhook, and I want to force the user to create a new subscription in that case, then I need to cancel the old one in the first place? Otherwise it will be attempted to get charged again and again?

so would that flow be correct:

1. create new subscription with payment details
2. charge every month as long as the payment succeeds
3. if at some point the payment fails, immediately cancel the subscription by API and force user create a new one where he can provide new payment details

?

[wild wave]

Yes, we will likely retry multiple times. Depends on your recovery/retry settings

[wild wave]

Seems reasonable if that's how you want to proceed. However you're likely over complicating your integration. Why do you want to cancel after a payment failure?

[lone socket]

if the payment fails

when I query the subscription

its status will be

incomplete

?

[lone socket]

as I see here?

how do I know that this is incomplete due to payment failure?

and how do I make my user to update the payment details? Since I am using stripe checkout I don't have payment details view in my product, and I don't want to have, due to compliance. So is there any Stripe endpoint where I can generate redirectUrl for the user to update his payment details?

[wild wave]

Depends on whether this is the initial invoice that the payment failed on

Can we do one question at a time?

[lone socket]

yes

so let me ask just one question

I understand that the recommended way when the payment fails is to listen for invoice.payment_failed webhook and then notify user about that and let him update his payment info?
How do I do that without implementing payment details collection view on my side - is there anything similar to the checkout session where I can redirect the user to stripe domain?

[wild wave]

You can use the customer portal to re-collect payment info: https://stripe.com/docs/customer-management
Or you can enable automatic emails from us: https://stripe.com/docs/billing/revenue-recovery/customer-emails#failed-payment-notifications

[lone socket]

in case of the automatic emails - will it include any sort of link where they can only update their payment details for the subscription ?

[wild wave]

You can see the emails here: https://dashboard.stripe.com/settings/billing/automatic

Can send a test one to yourself too

[lone socket]

so I understand the custom link is custom developed solution on my portal

and the first one is the customer-management Stripe hosted?

[wild wave]

Yes, the hosted page is a paid option

[lone socket]

so yeah

that is why

I don't want to do this

I want, as initially proposed, just cancel the subscritpion

and force the user to create new one

with new payment details

[lone socket]

you said I am over complicating it, but actually it sounds simpler than all that we discussed above

[wild wave]

Ok, then that's fine. Go for it!

[lone socket]

I just want to understand if you see any issues if I go that way

[wild wave]

Well you're likely going to see a lot of invoice.payment_failed events relating to 3DS/auth attempts, especially for the initial payment and potentially for off-session/recurring payments

So you'd need to account for that

[lone socket]

but if it's initial payment failure, I would not get the invoide.paid event and the checkout session gets redirected to payment failure url right?

[wild wave]

No, why would the invoice be paid if the payment failed?

[lone socket]

exactly

so on the initial payment I don't need to care about that event, because I only listen to invoice.paid at this phase

[wild wave]

Ok, but you're planning to cancel the subscription when you receive invoice.payment_failed events, right?

[lone socket]

yes, but only if it exists already

[wild wave]

So if your customer attempts to pay, and the bank requests 3DS then that event will fire. If you cancel the subscription on that initial payment then it'll break the entire flow

[lone socket]

so is there any other event that would fit it better?

e.g.
invoice.finalization_failed

[wild wave]

Yeah, that exists. But it's not relevant here

[lone socket]

ok so in case of the recurring payments, if the 3DS is required, how the user gets notified about that? He doesnt? I get the invoice.payment_failure webhook and I need to handle that on my side, i.e. notify the user and handle it with the payment intent?

[wild wave]

It depends. Is this the initial payment, or a subsequesnt recurring payment where they'll be off-session?

[lone socket]

as I wrote, recurring payment

[wild wave]

They're not notified automatically as I explained. You can turn on our emails, or you need to use webhooks to inform them

[lone socket]

but 3DS means they need to confirm that on their mobile app for example right?

or how does it work in case of recurring payment?

I am from europe and I have never got into it for recurring payments

[wild wave]

Well you'd bring the user back on-session to a payment UI where you can re-confirm the payment and they can authenticate the payment

[lone socket]

oh ok

on-session means - I can take them on the create-checkout-session on stripe side?

[wild wave]

Or you use our automated emails with your hosted page which do that for you

On-session means they're present in the checkout/payment flow, and can therefore carry our any action requested by the bank

You wouldn't initiate a new Checkout Session in this scenario, no

[lone socket]

so I need to implement the whole checkout workflow on my own for this case?

ok then, even if that happens, 3DS, so the payment fails, and I cancel the subscription, then I can take the user back to create-checkout-session and have him go through the checkout again and create new subscription, and the 3ds will be handled there, by the Stripe Checkout?

[wild wave]

No, not the entire flow. The way this generally works:

• A recurring payment requires 3DS/auth, we fire a invoice.payment_failed/invoice.payment_action_required.
• You use that event to trigger an email to your users, asking them to come back on-session to complete the payment.
• In that email include a link to a page in your application which uses the existing payment_intent from the Invoice event(s), and build a UI that uses Stripe.js to re-confirm that Payment Intent which will trigger the 3DS flow for your user.

[lone socket]

ok I have to go for a call