Stripe-data i Postgres: vad kan ersätta webhooks?

Stripe-data hamnar ofta i flera delar av en produkt. Betalningen sker hos Stripe, användaren finns i Supabase och produktåtkomsten avgörs av kod som körs via exempelvis Vercel. För att hålla delarna synkroniserade har många byggt webhook-funktioner som tar emot händelser från Stripe och uppdaterar den egna databasen.

Det fungerar, men innebär också ansvar för misslyckade leveranser, dubletter, fel ordning och avstämning mot Stripe. Den 15 oktober 2026 presenterade Stripe realtidssynk från Stripe Data Pipeline till Postgres. Funktionen kan förenkla mycket av detta, särskilt om du använder Supabase eller en annan Postgres-baserad tjänst.

Men en synkroniserad databas och en webhook löser olika problem. Skillnaden är viktig när betalstatus styr vad en användare får göra i produkten.

Vad Stripe har lanserat

Stripe Data Pipeline har tidigare främst använts för att flytta Stripe-data till datalager och lagringstjänster för analys. Den nya Postgres-synken är gjord för databaser som används direkt av applikationer.

Du väljer vilka Stripe-tabeller som ska synkroniseras. Stripe fyller först databasen med befintliga poster och fortsätter sedan att kopiera förändringar när kunder, betalningar, fakturor och abonnemang uppdateras. Stripe beskriver detta som realtid, men det ska förstås som en kontinuerlig synk med en kort och varierande fördröjning – inte som att båda systemen ändras exakt samtidigt.

Tjänsten är i publik förhandsversion. Dokumentationen varnar för att en rad tillfälligt kan visa ett tidigare tillstånd och att vissa typer av förändringar kan ta längre tid att dyka upp. Det påverkar hur säkert det är att fatta omedelbara beslut från den synkroniserade kopian.

Synken omfattar resurser i Stripes publika API som kan hämtas som listor. Du kan bland annat välja data för kunder, betalningsförsök, avgifter, fakturor, återbetalningar, Checkout-sessioner och abonnemang. Varje tabell motsvarar en Stripe-resurs och innehåller även synkmetadata samt den fullständiga resursen som JSON.

För Supabase och Neon kan anslutningen göras genom auktorisering i Stripe Dashboard. För annan Postgres behöver du normalt skapa en separat databasanvändare, ge Stripe nödvändiga rättigheter och tillåta en säker nätverksanslutning. Stripe skapar och förvaltar ett eget schema med de tabeller du valt.

Det schemat ska betraktas som Stripe-förvaltat och skrivskyddat för din applikation. Bygg egna vyer och tabeller bredvid det, men ändra inte Stripes tabeller, kolumner eller innehåll.

Vad synken kan ersätta

Den tydligaste vinsten är att du inte längre måste använda webhooks bara för att bygga en lokal kopia av Stripe.

Ett vanligt upplägg ser ut så här:

• Stripe skickar en händelse när ett abonnemang ändras.
• En serverfunktion verifierar signaturen.
• Funktionen tolkar händelsen och uppdaterar en egen tabell.
• Koden försöker hantera dubletter och händelser som kommer i oväntad ordning.
• Ett separat jobb jämför ibland den lokala tabellen med Stripe.

Data Pipeline tar över stora delar av den kedjan. Stripe skriver det aktuella resurstillståndet till Postgres, granskar synkroniserade poster mot källdatan och försöker rätta avvikelser. Du behöver inte själv återskapa slutläget genom att tolka en följd av händelser.

Det passar särskilt bra för följande behov:

• Rapportering. Du kan kombinera betalningsdata med användare, organisationer och produktdata i SQL.
• Kundsupport. Supportvyer kan visa abonnemang, fakturor, återbetalningar och betalstatus utan separata API-anrop till Stripe.
• Felsökning. Du kan jämföra användarens interna konto med de Stripe-poster som hör till kunden.
• Kontosidor. Produkten kan visa aktuell plan, fakturahistorik och kommande förändringar från databasen.
• Avstämning. Du kan hitta konton som saknar kundkoppling eller har en produktnivå som inte stämmer med Stripe.

Synken minskar också behovet av tabeller som försöker vara förenklade kopior av Stripe. I stället kan du skapa SQL-vyer som översätter Stripes datamodell till produktens språk, exempelvis billing_overview eller current_plan.

Det betyder inte att du ska låta hela applikationen läsa Stripes råtabeller direkt. En vy ger dig en stabilare gräns där du kan välja relevanta kolumner, namnge begrepp tydligt och dölja betalningsuppgifter som inte ska vara tillgängliga för klienten.

Vad synken inte ersätter

En webhook är en händelse: något har hänt, agera nu. Data Pipeline är en synkroniserad kopia: så här ser resursen ut när uppdateringen har nått databasen.

Den skillnaden gör att webhooks fortfarande är relevanta när en specifik förändring ska starta en process. Exempel är att skicka ett kvitto, lägga en order i en kö, varna om en misslyckad betalning eller reagera på en tvist.

Webhooks har sina egna problem. Stripe kan försöka leverera en händelse igen, samma händelse kan tas emot mer än en gång och olika händelser behöver inte levereras i den ordning de skapades. Därför måste en webhook-hanterare vara idempotent – samma meddelande ska kunna behandlas igen utan att samma åtgärd utförs på nytt.

Data Pipeline gör det lättare att slippa sådan logik när målet bara är att lagra det senaste tillståndet. Däremot ger en tabelländring inte automatiskt samma tydliga signal om varför något ändrades eller vilken affärsprocess som ska köras.

Var särskilt försiktig med följande:

• Orderhantering. Vänta inte blint på att en rad ska ändras om ordern behöver börja behandlas direkt efter en bekräftad betalning.
• Meddelanden. En aktuell fakturarad berättar inte om ett visst mejl redan har skickats.
• Engångsåtgärder. En databasfråga kan köras flera gånger och får inte råka skapa samma leverans eller kredit flera gånger.
• Tidskritiska flöden. Realtidssynk har fortfarande fördröjning, särskilt under en förhandsversion.
• Händelser utan lämplig tabell. Data Pipeline synkroniserar resurser, inte nödvändigtvis varje signal som Stripe kan skicka.

Ett rimligt hybridupplägg är därför att låta Data Pipeline äga kopian av Stripe-data och behålla webhooks för utvalda händelser som verkligen ska starta en åtgärd. Webhook-koden blir då mindre: verifiera händelsen, registrera ett jobb och svara snabbt. Den behöver inte samtidigt försöka underhålla en komplett spegling av Stripe.

Välj en tydlig källa till sanning

Begreppet källa till sanning betyder det system vars uppgift är att avgöra vad som faktiskt gäller. Problemet uppstår när både Stripe och din egen tabell anses ha sista ordet.

En bra ansvarsfördelning kan vara:

Det sista beslutet är mer komplicerat än att kontrollera om ett abonnemang har status active. Du kan behöva ta hänsyn till provperioder, planerade uppsägningar, obetalda fakturor, manuellt beviljad åtkomst, interna konton eller en tidsfrist efter betalningsproblem.

Skapa därför inte produktåtkomst som ett utspritt villkor i flera gränssnitt och serverfunktioner. Samla reglerna i en vy, databasfunktion eller servermodul. Resultatet kan innehålla fält som has_access, plan_key, access_reason och source_updated_at.

Du behöver också bestämma hur fördröjning ska hanteras. Om en kund precis har betalat men synken ännu inte är klar kan du:

• läsa den senaste resursen direkt från Stripe i bekräftelseflödet
• låta en webhook ge preliminär åtkomst och senare stämma av mot Data Pipeline
• visa ett vänteläge och kontrollera igen
• använda en tydligt definierad tidsfrist innan åtkomst tas bort

Undvik att låta klientkod i webbläsaren fatta beslutet. Produktåtkomst ska kontrolleras på serversidan eller i databasen med rätt behörigheter. I Supabase innebär det även att det Stripe-förvaltade schemat inte bör exponeras direkt genom klientens API. Skapa begränsade vyer eller egna härledda tabeller och tillämpa row level security där användardata visas.

Kopplingen mellan din användare och stripe_customer_id behöver vara stabil och unik. E-postadress är olämplig som primär koppling eftersom den kan ändras och förekomma på flera konton. Spara Stripes identifierare på rätt intern användare eller organisation och kontrollera att samma Stripe-kund inte råkar kopplas till motstridiga konton.

Så inför du synken utan att skapa nya luckor

Börja med att kartlägga vad dina nuvarande webhooks faktiskt gör. Dela upp ansvaret i lagring av Stripe-data, produktåtkomst och engångsåtgärder. Då ser du vad Data Pipeline kan ta över och vad som behöver finnas kvar.

Använd gärna denna kontrollista:

• Dokumentera vilka Stripe-händelser du tar emot och varför.
• Markera vilka handlers som bara kopierar data till Postgres.
• Behåll handlers som startar leveranser, meddelanden eller andra engångsåtgärder.
• Välj bara de Stripe-tabeller som produkten och rapporteringen behöver.
• Placera synken i ett separat schema och använd en separat databasroll.
• Säkerställ att webbläsarklienter inte kan läsa rå betalnings- eller kunddata.
• Bygg egna vyer för produktens begrepp i stället för att sprida Stripe-statusar i koden.
• Spara när källdatan senast uppdaterades så att gamla beslut kan upptäckas.
• Bestäm vad användaren ser medan en betalning eller uppgradering väntar på synk.
• Testa uppgradering, nedgradering, uppsägning, återbetalning och misslyckad betalning.
• Kör den gamla och nya lösningen parallellt tills resultaten kan jämföras.
• Lägg övervakning på synkens hälsa och på konton där åtkomst inte stämmer med Stripe.

Ta inte bort webhook-endpoints direkt efter att pipeline-tabellerna har fyllts. En historisk återfyllnad visar att data kan kopieras, men inte att alla framtida tillstånd och felvägar fungerar i din produkt. Testa även vad som händer när synken är sen eller tillfälligt otillgänglig.

Den viktigaste förändringen är alltså inte att webhooks försvinner. Det är att du kan sluta använda dem som en hembyggd datakopieringsmotor. Låt Stripe synkronisera sitt tillstånd, låt din produkt definiera åtkomstreglerna och använd händelser bara där en faktisk reaktion behövs.

När betaldata, åtkomst och användarflöden hänger ihop blir nästa steg att kontrollera hela resan från köp till fungerande konto – läs vidare om att bygga för betalande kunder.

---

Källa: Stripe blog