#m1dnight-subs

1 messages · Page 1 of 1 (latest)

bright mesa
#

hi! you can ignore them.

hard geode
#

But when I look in the Stripe dashboard I see that theyre going to be billed in the next period. So I assume that the first payment can fail, but the subscription will be requested to be paid for the next periods?

#

So perhaps if the subscription fails I should also ensure that it is deleted in the Stripe dashboard?

#

I'm just trying to cover my bases here.

bright mesa
#

ah you didn't mention subscriptions

#

So I assume that the first payment can fail, but the subscription will be requested to be paid for the next periods?
it doesn't usually work that way, if the first payment failed the subscription would be incomplete and it 'expires' after 23 hours.

hard geode
#

Yeah I just noticed I mistyped that. Sorry about that.

bright mesa
#

so I'd need to see examples of what you're talking about

hard geode
#

Aaah, that expiration makes sense.

bright mesa
#

m1dnight-subs

hard geode
#

I have an example with this id: sub_1Lf1lfD4tI8fPwouNcuZeyVq

#

So then I see two options: either allow the customer to fix the payment (but how?) or allow the customer to create a new payment. I guess the first one can be done via the management page of Stripe that each customer has access to.

#

"portal session" is the name apparently. Sorry :p

bright mesa
#

so this looks like an entirely active subscription. Where's the failure exactly?

hard geode
#

I just activated it by manually paying it.

#

Via the portal session, that is.

#

But doesn't seem to trigger the right update on my side. I get a subscription update to "incomplete"

#

But perhaps instead of wasting your time I should read some more documentation?

bright mesa
#

For that subscription, you used Checkout to create a CheckoutSession, visited that, entered the test card 4000 0000 0000 9995, that failed, you tried again and used 4242424242424242, and that creates a subscription and pays the initial invoice and creates a Customer with that card saved.

bright mesa
#

you only care when you receive a checkout.sesion.completed event, that's when you reconcile to your system that the subscription exists

hard geode
#

oooh.

#

Then I've been doing it all wrong.

#

I'll check that out. thanks for your time!

bright mesa
#

to be clear you're not wasting my time or something, I'm just having trouble understanding.

Generally if you're using Checkout, the idea is you only need to listen for the Checkout specific events (https://stripe.com/docs/payments/checkout/fulfill-orders) and that's when you know that a subscription exists(and it would always be active). Now, during the usage of Checkout, we do internally create some objects like PaymentIntents and Invoices for the payment attempts the customer is making, and you'll get webhooks about those if you listen to those types, but you don't really have to worry about those.

I might not be understanding completely your scenario though

hard geode
#

I think you do. At this point Ive been handling all the separate events on my end (invoices, subscriptions, customers, etc). But most of them just log to a file. This way I'm sure I have all the events. But I completely ignored the checkout events. It's exactly what I need.

#

Makes stuff a lot simpler, too.