dan-checkout-subscription

[sinful venture]

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

• danboyle8637, 5 days ago, 5 messages

[viral trail]

Hi 👋 to clarify, are you saying your database query is running regardless of the Event type being received, customer.subscription.created or customer.subscription.updated, and you want to adjust that? Or is it that you're receiving customer.subscription.updated Events shortly after initially creating a Subscription?

[pulsar hare]

So two scenarios:

1. When a user updates or cancels their subscription in the Stripe Billing Session...

I listen to customer.subscription.updated so I can run a database query and update their membership.

My issue happens when a brand new subscription signs up, the same customer.subscription.updated event runs and and so does that database query.

Because I'm getting a subscription object... as far as I know there is not way I can see if the subscription was updated.

I can tell if it was cancelled as there are properties for that.

Does that make sense?

[viral trail]

Can you share the ID of a customer.subscription.updated Event from your testing that corresponds with a newly created Subscription?

[pulsar hare]

Sorry I can't right now. I am not at my dev computer. I will have to come back in a couple hours.

Thanks for trying to help though!

[viral trail]

Any time! I'll let you know what I was thinking so you can take a look when you have a chance.

My suspicion is that your Subscriptions are being created in such a way that they are created, and then quickly have something happens that causes them to update. It's hard to say what could be causing that without seeing an example, but an example of one scenario is you create a Subscription with a payment_behavior of default_incomplete (which will create an incomplete Subscription) and then pay the first Invoice that was generated (moving the Subscription to an active state). While it's still a fresh Subscription, that is technically a creation followed by an update.

[pulsar hare]

Hmmmm... let me quickly log into github and see what my code does.

This is how I'm constructing my request:

const baseUrl = `https://api.stripe.com/v1/checkout/sessions`;
        const lineItems = `line_items[]price=${priceId}&line_items[]quantity=${quantity}`;
        const metadata = `metadata[membership_plan]=${membership}&metadata[product]=fww_live`;

const urlParamsLineItems = new URLSearchParams(lineItems).toString();
            const urlParamsMetadata = new URLSearchParams(metadata).toString();
            const urlParsmsCheckoutData = new URLSearchParams(checkoutData).toString();

            const reqUrl = `${baseUrl}?${urlParamsLineItems}&${urlParamsMetadata}&${urlParsmsCheckoutData}`;

[viral trail]

Interesting, is that running? It looks like it's missing the required mode parameter, but maybe that's in your checkoutData object.

I don't recall offhand if Checkout Sessions are one of the flows that create customer.subscription.created Event quickly followed by customer.subscription.updated, but it may be.

[pulsar hare]

I do have the mode set sorry:

const checkoutData = {
                mode: "subscription",
                success_url: nonMemberSuccessUrl,
                cancel_url: nonMemberCancelUrl,
            };

Essentially though you're saying that customer.subscription.updated should NOT be running when a new subscription is created.

At least that gets me going in a direction to figure this out

[viral trail]

Correct, it's a minor distinction, but I do not think you should see customer.subscription.updated when a Subscription is created. If it's being created and then updated shortly after (such as when the payment processes), I would expect you to see a customer.subscription.created Event followed shortly by a customer.subscription.updated Event.

[pulsar hare]

ok cool. I'll check some things out and if I keep getting stuck I'll come back.

Thanks for helping though. I'm going to check those properties when creating the session.

[viral trail]

Any time!
I just ran through a test with one of my Checkout Session + Subscription flows, and the behavior I'm seeing is what I described. There are two distinct Events being generated when the Subscription is being paid for, one when it gets created then a second when the payment succeeds.

I don't think that is something that you will be able to adjust when working with Checkout Sessions though.

[pulsar hare]

ahhh... okay. Thanks!