matt-conflitti_webhooks

[elder shoal]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1263847430596726824

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[chilly coyote]

Is this for an automated test suite?

[karmic granite]

yes. trying to use fixtures with the cli to test my various flows in a deterministic way

also needing guidance as to the minimal events to handle for my flows.

i.e. can i just use customer.subscription.updated to update user info should I be tracking things like invoice.paid to be sure they have paid? It sounds like payment events may lag an hour or so behind subscription moving into active which would leave the user unable to use the app.

https://stackoverflow.com/questions/26984476/stripe-webhook-for-when-trial-ends

 switch (event.type) {
      case supportedEvents.checkoutSessionCompleted:
        stripeSubscriptionId = session.subscription;
        subscriptionTier = 'pro';
        break;
      case supportedEvents.customerSubscriptionUpdated:
        stripeSubscriptionId = session.id;
        // TODO: is this after each payment?
        // https://docs.stripe.com/api/subscriptions/object?event_types-invoice.payment_succeeded=#subscription_object-status
        // incomplete happens if initial payment fails but have 24 hours to fix
        if (['trialing', 'active', 'incomplete'].includes(session.status)) {
          subscriptionTier = 'pro';
        }
        break;
      // TODO: are these necessary if we have subscription.updated handling this
      case supportedEvents.invoicePaid:
        stripeSubscriptionId = session.subscription;
        subscriptionTier = 'pro';
        break;
      case supportedEvents.invoicePaymentFailed:
        stripeSubscriptionId = session.subscription;
        subscriptionTier = 'unpaid';
        break;
      default:
        console.log(`Unhandled event type ${event.type}`);
        response.send();
        return;
    }

is what i am thinking

[chilly coyote]

We discourage automated testing against our api. Instead, we recommend using mocks of our api responses: https://docs.stripe.com/automated-testing. Test suites should not call our api. That contributes to rate limiting. If you need to test specific subscription flows, I recommend manually running through your flows and using test clocks: https://docs.stripe.com/billing/testing/test-clocks. As far as which events to listen to, it's hard to say because every integration is different. This guide should help you decide though: https://docs.stripe.com/billing/subscriptions/webhooks

[karmic granite]

okay, what is the purpose of fixtures then? and these are not tests that I plan to put into cicd pipelines, just local testing

[chilly coyote]

Oh ok

Fixtures are fine for generating some test data and testing/experimenting locally

Automated testing is what you shouldn't do

I asked if this was for an automated test suite at the beginning and you said yes