#zepatrik-clocks
1 messages ยท Page 1 of 1 (latest)
hm well, for me it is a subscription related feature to create a subscription through checkout ๐
if you want a subscription in the incomplete_expired status you could create the subscription from the API directly I think, instead of using Checkout
yeah, I totally get it, just from an org chart point of view on our side those are different teams, to explain it
let me give you an excerpt of the code in question:
// polling fallback strategy, in case the webhook did not update the subscription yet
if sub.OngoingStripeCheckoutID.Valid && time.Since(sub.UpdatedAt) > h.d.Config().StripeCheckoutPollAfter() {
sess, err := h.d.StripeClient().CheckoutSessions.Get(sub.OngoingStripeCheckoutID.String, &stripe.CheckoutSessionParams{
Params: stripe.Params{Expand: []*string{stripe.String("subscription")}},
})
if err != nil {
return
}
// an existing subscription means that the checkout is done
if sess.Subscription != nil {
h.d.PaymentService().HandleCheckoutSessionCompleted(ctx, sess)
} else if time.Since(time.Unix(sess.ExpiresAt, 0)) >= 0 {
// checkout expired, this case is here to minimize unnecessary polling and reset the subscription for cases where payment failed
sub.OngoingStripeCheckoutID = x.NullString{}
if err := h.d.PaymentStore().UpdateSubscription(ctx, sub); err != nil {
return
}
}
}
the problem was that a checkout session after failed payment has a subscription in the incomplete_expired state
which was not obvious from the docs....
is there some docs page that has all the possible states of the checkout session?
for polling like that I would use https://stripe.com/docs/api/checkout/sessions/object#checkout_session_object-payment_status personally instead of looking for if the subscription field is set , to determine the overall status of the Session
or you could use the Events List API to list recent checkout.session.completed events and see if there is one for the cs_xxxx ID you're checking against
looking for the payment status makes more sense, good point
but is there a way to detect that the payment failed? in our case a customer completed the checkout and got positive feedback, but the payment still failed in the background
in that case we would like to reset state on our side, but payment_status only has paid or unpaid?
there's no such things as it failing really since that's an internal detail of Checkout
if the customer can't pay on the Checkout page they can try again, it's all handled on the page
as the merchant you only care about being notified of successful payments so you can fulfill them, that's how Checkout is designed.
in our case a customer completed the checkout and got positive feedback, but the payment still failed in the background
not sure what that means really without an example since that generally wouldn't happen(but we might be talking about something like an async SEPA debit)
in case you can look it up this is the payment intent I am talking about specifically: pi_3LWbjtCIM0fIcVe11qekrskD
what I see in the dashboard is that the payment was declined by the bank/...
this was a credit card payment
and the checkout session had a subscription created, but with the incomplete and later incomplete_expired state
would that checkout session have the unpaid payment status at any given point in time?
well the customer would not have seen positive feedback in that case, they would have seen an error about the decline.
yep, it will have had that status for the whole time
ok thanks, TL;DR never trust the customer ๐
still wondering why a subscription was created ๐ค
because we have to create the subscription in order to create an invoice to create a PaymentIntent to attempt the payment
ok I see...
but those are internal details, as the merchant you're supposed to only care about listening to checkout.session.completed and fulfilling the order
yeah we had some problems with the webhooks (mainly on our side, and specifically due to our local setup with the cli webhook forwarder) that led to implementing this polling backup strategy
we use the checkout.session.completed as the main thing
๐ taking over for my colleague. Let me catch up.
yeah we had some problems with the webhooks
do you need help on that front?
I guess it was just bugs in the CLI/our deployment of the CLI in k3d
seemed pretty reliable recently
thanks for the answers, I think everything is clear(er) now
let me know if you need any more help