#zepatrik-clocks

1 messages ยท Page 1 of 1 (latest)

vapid goblet
#

hi, clocks are only for Subscription related features yes.

fair harness
#

hm well, for me it is a subscription related feature to create a subscription through checkout ๐Ÿ˜…

vapid goblet
#

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

vapid goblet
fair harness
#

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?

vapid goblet
#

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

fair harness
#

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?

vapid goblet
#

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)

fair harness
#

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?

vapid goblet
#

well the customer would not have seen positive feedback in that case, they would have seen an error about the decline.

vapid goblet
fair harness
#

ok thanks, TL;DR never trust the customer ๐Ÿ˜‚

#

still wondering why a subscription was created ๐Ÿค”

vapid goblet
#

because we have to create the subscription in order to create an invoice to create a PaymentIntent to attempt the payment

fair harness
#

ok I see...

vapid goblet
#

but those are internal details, as the merchant you're supposed to only care about listening to checkout.session.completed and fulfilling the order

fair harness
#

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

dense cypress
#

๐Ÿ‘‹ taking over for my colleague. Let me catch up.

#

yeah we had some problems with the webhooks
do you need help on that front?

fair harness
#

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

dense cypress
#

let me know if you need any more help