Switch with no breaks vs switch with breaks on Stripe Webhook - php

Question

So, I have a Stripe webhook for a subscription site for one of my clients and I am using Stripe for the payment process. Because it was faster in my case to use the Stripe PHP SDK directly, what I did is the following preparation steps.
I have created the subscription plans manually in the Stripe dashboard.
I have a database table with specific subscription options and I've copied the corresponding Stripe Subscription Plan IDs to the table.
This way I know which plan has been selected and can make the correct correspondence/relation between customer and subscription type.
Then, the process I have is:
Customer selects the subscription type desired.
I prepare a checkout session using the PHP SDK and send the customer to Stripe to complete the subscription process.
Customer completes the subscription process and comes back to the site to a 5 second "Wait for the subscription to be created" section. This is literally a page with a setTimeout that redirects the customer after 5 seconds to the subscription section and gives the webhook time to do its job.
During those 5 seconds if everything goes well, the webhook is notified of the subscription, creates the transaction and then the subscription. The thing is that sometimes it works and sometimes it doesn't work. If I re-send it, it works, but the idea is not to do this manually.
My question is the following, I am using 3 events for the webhook:
customer.subscription.created
charge.succeeded
customer.subscription.updated
In the end I only end up using the charge.succeeded and the customer.subscription.updated events, because they are the ones I've found useful.
According to the webhook dashboard, the three events were sent and correctly received, but it would seem something's not working on the other end.
Now I am also not sure how this works, because of what my webhook does. The original code the Webhook generator gives me has the events like this:
switch ($event->type) {
case 'charge.succeeded':
$charge = $event->data->object;
case 'customer.subscription.created':
$subscription = $event->data->object;
case 'customer.subscription.updated':
$subscription = $event->data->object;
// ... handle other event types
default:
echo 'Received unknown event type ' . $event->type;
}
But I had to add breaks after each case because in some cases, variables I needed didn't exist in the context of another event.
My question is the following, does the switch with no breaks execute each case in order or only the events it receives, and what would be a good practice in this case to ensure I always receive the information required.
I thought of creating the subscription before the payment, but that just adds extra steps, because if the person decides to go back before paying, I'd have to delete it.

Answer 1

If you use Checkout, you should only be listening to the checkout.session.completed Event instead which indicates the Checkout Session was completed successfully. This is also what Stripe covers in their documentation about fulfillment.
Once you get that Event, you can look at the Session, find the id of the Customer (cus_123) and Subscription (sub_123) associated with that Session and save all the information in your database.
Additionally, event delivery to your webhook endpoint can fail or be slow. Those can happen for various reasons and Stripe has a retry logic documented here.
Since the customer is redirected to your success url, you should already be able to write code to check who they are. This is usually done from a cookie and then you look up their Session id cs_live_123. Alternatively, you can configure Checkout to put the Checkout Session id in the URL as a query parameter which is documented here. This would allow you to synchronously look up the Session, check its completion state, store all the information you need (by re-using the code used in your webhook handler) and synchronously redirect them to the right page. Or you can also poll your database until you got the Event.
It's important to always have a webhook endpoint to catch those events. The customer could close the tab or lost the connection and never be redirected. But if the redirect succeeds, you can already look them up more directly.