Configuración de webhooks de Stripe para cancelaciones de suscripción
Clase 19 de 27 • Curso de Lanzamiento y Monetización de Webs con Lovable
Resumen
Capture Stripe webhook notifications with confidence and turn subscription events into actionable insights. Learn how to select the right event, wire a Supabase edge function, secure access with RLS, and test end to end using Stripe’s tools. No guesswork, just a clear path from setup to reliable follow-ups.
Why use Stripe webhooks for subscription changes?
Stripe webhooks let you notify sales or go-to-market teams when users unsubscribe or update billing. You can also persist these events for follow-up and support.
- Monitor events with Workbench. Open the Stripe dashboard’s Workbench to view logs, failures, and event health.
- Add a destination. Choose Your account and set a webhook endpoint to receive events from the same Stripe account.
- Select the right event. Focus on subscription lifecycle signals like customer.subscription.deleted for cancellations. Avoid noise by not subscribing to unnecessary events.
- Document intent. Add a clear description so future editors know the purpose: when a user unsubscribes, send event to Supabase and save to a follow-up table.
How to configure a Supabase endpoint and secure data?
Point Stripe to a Supabase edge function that captures the event and saves it to a Canceled Subscriptions table. Restrict access so only admins can view sensitive data.
What endpoint url and signing secret do you need?
- First create the webhook endpoint so Stripe can generate the signing secret.
- If your tool asks for the secret early, use a temporary value, complete the Stripe setup, then update with the real secret revealed in the destination.
- Paste the actual secret back into your tool and redeploy the edge function to verify signatures correctly.
How to store cancellations for follow-up?
- Insert each customer.subscription.deleted into the Canceled Subscriptions table.
- Save the Stripe customer ID so support can quickly identify the account in the Stripe dashboard.
- Include a flag to mark whether a follow-up has been sent.
- Handle cases where the customer email may be missing. Insert the record anyway so no cancellation is lost.
How to restrict access with rls policies?
- Apply RLS policies so only admins can query the table.
- Ensure regular users can never read others’ subscription data.
How to test and debug Stripe events quickly?
Use Stripe’s tools to simulate and resend events until everything works end to end. Resolve signature and payload issues without shipping guess fixes.
How to trigger customer.subscription.deleted in the cli?
- In the Developer Workbench, copy the suggested command template.
- Use the correct CLI form:
stripe trigger customer.subscription.deleted. - Let Stripe chain related events until the cancellation is emitted to your webhook.
How to handle common 400 errors?
- webhook signature verification failed. Update your endpoint to use the correct signing secret and webhook version, then redeploy. Resend the failed delivery from Stripe instead of re-triggering.
- no customer email found. Some deleted customers may not include an email. Adjust parsing to avoid hard dependence on email and still insert the record.
- After fixes, look for 200 responses in Event deliveries to confirm success.
How to verify data landed in your admin dashboard?
- Open the admin dashboard’s follow-ups view and refresh after successful deliveries.
- If the table is empty despite 200 responses, review insertion logic: allow records without email, include the Stripe customer ID, and ensure the follow-up flag defaults correctly.
- Once visible, your team can filter and act on cancellations promptly.
Ready to build on this flow? Share what event you want to capture next or the part you want to automate, and let’s refine it together.