Discrepanță Stripe la Anulare: Dashboard vs. Realitatea Webhook-ului

Un dezvoltator care rulează o aplicație SaaS construită cu Next.js, Drizzle și Postgres, folosind Stripe pentru facturare, a descoperit o discrepanță critică între confirmarea de anulare a abonamentului de către Stripe și propriul dashboard destinat clienților. După testarea personală a procesului de anulare cu un card real și portalul clienților, dezvoltatorul a observat că, deși Stripe indica corect că abonamentul urma să fie anulat la sfârșitul perioadei, dashboard-ul său continua să afișeze 'Renews' (Reînnoiește). Acest lucru s-a întâmplat chiar dacă ambele livrări de webhook pentru evenimentul de anulare au returnat un cod de stare 200 și logurile de execuție ale aplicației nu au arătat erori, ducând la o situație în care clientul a primit informații incorecte despre starea facturării sale.

Cauza principală a fost identificată în handler-ul webhook al dezvoltatorului, care, deși reîmprospăta datele abonamentului de la Stripe la fiecare eveniment, se baza pe câmpul depreciat `cancel_at_period_end`. Acest câmp nu mai este actualizat în mod fiabil pentru abonamentele care utilizează modul de facturare 'flexible' al Stripe. În schimb, anularea efectivă era înregistrată prin intermediul timestamp-ului `cancel_at`. Teoria inițială a dezvoltatorului despre o condiție de cursă a fost infirmată, deoarece logica handler-ului de a reîmprospăta starea cea mai recentă a abonamentului ar fi trebuit să atenueze astfel de probleme; problema a fost fundamental legată de citirea unui câmp învechit sau irelevant pentru modul de facturare dat.

Acest incident subliniază importanța verificării datelor direct de la sursă și înțelegerea nuanțelor câmpurilor API, în special atunci când se tratează atribute depreciate sau configurații specifice de facturare. Soluția dezvoltatorului a implicat ajustarea logicii pentru a interpreta corect timestamp-ul `cancel_at` și pentru a asigura că dashboard-ul reflectă cu acuratețe starea abonamentului. Cele mai bune practici includ acum utilizarea `previous_attributes` din Stripe în payload-urile webhook pentru depanare și menținerea unei strategii robuste de logging pentru a captura evenimentele critice în perioada de retenție, asigurând o gestionare corectă a stării pentru aplicațiile destinate clienților.