---
title: "Comment by Hayrullah Kar on \"Why isn’t my Stripe webhook updating Supabase?\" | Hashnode"
description: "The status code legend under Event deliveries is a handy shortcut for anyone staring at a failed endpoint. One cause I would add: Stripe does not guarantee that"
url: "https://hashnode.com/posts/why-isn-t-my-stripe-webhook-updating-supabase/6ae9d43fde20b4f15aa70ce8/comment/6aeec84651134f1647c84073"
---

[Discussion](https://hashnode.com/posts/why-isn-t-my-stripe-webhook-updating-supabase/6ae9d43fde20b4f15aa70ce8)

Comment [Why isn’t my Stripe webhook updating Supabase?](https://hashnode.com/posts/why-isn-t-my-stripe-webhook-updating-supabase/6ae9d43fde20b4f15aa70ce8)

[Hayrullah Kar](https://hashnode.com/@magesheet)

[2d ago](https://hashnode.com/posts/why-isn-t-my-stripe-webhook-updating-supabase/6ae9d43fde20b4f15aa70ce8/comment/6aeec84651134f1647c84073)

The status code legend under Event deliveries is a handy shortcut for anyone staring at a failed endpoint. One cause I would add: Stripe does not guarantee that events arrive in the order they were created, and retries make the mix worse. A handler that writes the subscription status straight from each payload can apply an older customer.subscription.updated after a newer one and leave Supabase in the wrong state, even though every delivery shows 200 and every event ID is stored once. Two simple fixes: re-fetch the subscription from the Stripe API inside the handler and write what it returns, or store the created timestamp of the last applied event on the row and skip anything older.