#__flx
main ice
quasi mesa
Hi there
Yep using stripe trigger is a good way to test Webhooks. In terms of any programmatic testing that you want to do we recommend mocking responses like we talk about here: https://stripe.com/docs/automated-testing
I'm not really sure I understand your second question here so feel free to provide more details for that
wheat osprey
Oh, I forgot to write the question. The question is, is it considered enough to listen to
customer.created and customer.updated
to associate a customer email to a customer id?
because I found sometimes during this convoluted approach the customer ID was just wrong, because there were multiple customers for one email, and I kept updating them (not adding them, having the email with multiple customer IDs). then again I would be confused about what to do with multiple customer IDs, would that ever be something that happens in production?
quasi mesa
Yep we don't de-duplicate by default
So you can have multiple Customer objects with the same email
What you would typically do in production is check if a Customer with that email already exists when creating a new Customer: https://stripe.com/docs/api/customers/list#list_customers-email
Then you would either ask that customer to authenticate and re-use that Customer object or you would ask that customer to use a different email and create a new Customer object
wheat osprey
cool, makes sense
i'm still trying to map the article about automated testing in my brain. I'm slow today lol
quasi mesa
Basically you just don't actually hit the Stripe API when you test. You hit it once to understand what the object shape will look like. Then you create a mock of that object to be used in your tests
wheat osprey
okay, so that only applies when we call your api. that makes sense
so if i were to test my checkout redirect route for example?
quasi mesa
You would simulate going to a page with a similar URL to what the redirect would take you, then you mock out the objects like the Checkout Session and PaymentIntent and then ensure that page displays the mocked data for those objects.
So then if you change anything on your redirect page your tests ensure that data is still displayed
wheat osprey
Sure, yes. In our example, we don't even do any other API calls on the success page. We just have a route that creates the checkout session and redirect to the URL that comes from the API.
So I would call the route, mock your API and expect to get redirected to the mocked URL.
quasi mesa
Yep
wheat osprey
Just to double check then.
I saw in one help article it was recommended to listen to customer.created and customer.updated, etc events, and for subscriptions to listen to subscription.updated, subscription.deleted, etc.
Now in another example of a subscription integration I read that I can listen to
checkout.session.completed
for the customer
and invoice.paid // invoice.payment_declined (or similar).
I don't really see the difference there tbh.