Så lägger du till prenumerationer med Stripe: planer, provperioder, webhooks och misslyckade betalningar
För att lägga till prenumerationer med Stripe skapar du en produkt med ett återkommande pris i Stripe-instrumentpanelen, skickar kunderna till Stripe Checkout i prenumerationsläge från din server och låter en webhook tala om för din app när varje betalning lyckas, misslyckas, ändras eller upphör. Lagra prenumerationens status kopplad till användaren och ge åtkomst utifrån den, inte utifrån framgångssidan. Lägg till en knapp Hantera fakturering som öppnar Stripes hostade kundportal, så att folk kan byta kort, byta plan och säga upp sina prenumerationer utan att du bygger de skärmarna.
Den här guiden bygger på så lägger du till betalningar i din app, som täcker engångs-Checkout, testläge och att gå live. Här fokuserar vi på vad som skiljer återkommande fakturering. Stripe-detaljerna är från Stripes dokumentation per september 2026.
Varför prenumerationer är svårare än engångsbetalningar
En engångsbetalning sker medan kunden är i din app. En prenumeration fortsätter även efter att kunden har lämnat: förnyelser varje månad, kort som går ut, uppgraderingar mitt i en period, uppsägningar som gäller vid periodens slut. Din app hör bara om dessa via webhooks. De flesta prenumerationsfel uppstår när man behandlar första betalningen som hela historien.
Dina alternativ
| Metod | Vad du bygger | Bäst för |
|---|---|---|
| Payment Link med återkommande pris | Ingenting utom en länk | Testa efterfrågan; hantera åtkomst för hand |
| Checkout (prenumerationsläge) + kundportal | En serverrutt, en webhook, en faktureringsknapp | De flesta SaaS-appar och medlemskap |
| Prenumerations-API med eget betalningsformulär | Mycket mer: betalningsgränssnitt, autentisering, återförsök | Appar med ovanliga faktureringsflöden |
| Merchant-of-record-leverantör | Liknar Checkout | Säljare som vill att leverantören sköter försäljningsmomsen |
För de flesta appar är Checkout plus portalen rätt avvägning. Jämför leverantörer i Stripe kontra Paddle kontra Lemon Squeezy om skattehanteringen oroar dig.
Planera din prissättning i Stripe först
I Stripe är en produkt det du säljer ("Pro-plan") och ett pris är hur du tar betalt för den ("199 kr per månad", "1 990 kr per år"). En produkt kan ha flera priser. Bestäm:
- Vilka nivåer du erbjuder och vad varje nivå låser upp i din app
- Månadsvis, årsvis eller båda
- Om du erbjuder en provperiod, och om den kräver kort i förväg
Skapa produkterna och priserna i testläge, och behåll deras pris-ID:n; din app refererar till dem. Om du inte har bestämt prissättningen, läs så prissätter du en SaaS-produkt och freemium kontra gratis provperiod.
Prenumerationens livscykel som du måste hantera
Stripes översikt över prenumerationer listar de statusar en prenumeration kan ha. De som är viktigast för åtkomst:
| Status | Vad det betyder | Ge åtkomst? |
|---|---|---|
trialing | I en provperiod | Ja |
active | I gott skick | Ja |
incomplete | Första betalningen är inte klar ännu; Stripe ger kunden 23 timmar | Nej |
incomplete_expired | Första betalningen lyckades aldrig | Nej |
past_due | Senaste betalningen misslyckades eller prövades inte; nya försök kan följa | Ditt val; många appar tillåter en kort respitperiod |
unpaid | Försöken är klara, fakturor förblir öppna, inga fler försök | Nej, Stripes dokumentation säger att åtkomsten ska återkallas |
canceled | Avslutad; kan inte startas om | Nej |
paused | En provperiod slutade utan betalningsmetod och sattes på paus | Nej |
Lagra statusen på din användar- eller kontopost och basera åtkomsten på den. Uppdatera den varje gång en relevant webhook kommer.
Webhook-händelserna att hantera
| Händelse | Vad din app gör |
|---|---|
checkout.session.completed | Koppla de nya Stripe-kund- och prenumerations-ID:na till din användare |
invoice.paid | Markera prenumerationen som aktiv och spara den nya periodens slut |
invoice.payment_failed | Berätta för användaren att kortet misslyckades och länka till portalen |
invoice.payment_action_required | Be användaren slutföra kortautentisering |
customer.subscription.updated | Uppdatera plan, status och eventuell schemalagd uppsägning |
customer.subscription.deleted | Ta bort betald åtkomst |
customer.subscription.trial_will_end | Påminn användaren innan provperioden slutar; Stripe skickar den tre dagar före |
Hanterarreglerna från Stripes webhook-dokumentation gäller fortfarande: verifiera signaturen med den råa kroppen, svara snabbt med ett 2xx, hantera dubbletter och händelser i fel ordning, och räkna med återförsök. Guiden vad är en webhook förklarar idén, och betalningsguiden listar reglerna i detalj.
Steg för steg
- Skapa produkter och priser i Stripes testläge.
- Lägg till hemligheter: den hemliga nyckeln, pris-ID:na och senare webhookens signeringshemlighet. Lägg aldrig dem i kod för gränssnittet.
- Prissida: varje plans knapp anropar din server, som skapar en Checkout-session i prenumerationsläge för den inloggade användaren. Skicka med ditt användar-ID så att webhooken kan koppla betalningen till kontot.
- Webhook-slutpunkt: verifiera signaturer och hantera händelserna ovan, och uppdatera en prenumerationspost per användare.
- Lås funktioner utifrån den lagrade statusen och planen, kontrollerad på servern för varje skyddad åtgärd, inte bara dolda knappar.
- Kundportal: konfigurera den i Stripe-instrumentpanelen (vilka planer folk kan byta till, om de kan säga upp), lägg sedan till en knapp Hantera fakturering som skapar en portalsession på servern och omdirigerar dit.
- Misslyckade betalningar: i Stripes faktureringsinställningar väljer du beteendet vid återförsök och vad som händer efter sista försöket. Visa en banner i appen när status är
past_due. - Testa hela livscykeln, publicera sedan och registrera den live-webhook.
Prompter till din AI-byggare
Lägg till prenumerationsfakturering med Stripe. Planer: Starter (pris-ID i STRIPE_PRICE_STARTER) och Pro (STRIPE_PRICE_PRO). Prissidan skapar en Checkout-session i prenumerationsläge på servern med STRIPE_SECRET_KEY, med den inloggade användarens ID kopplat. Spara Stripe-kund-ID, prenumerations-ID, plan och status på användaren. Exponera aldrig den hemliga nyckeln i webbläsaren.
Lägg till POST /api/stripe/webhook. Verifiera signaturen med STRIPE_WEBHOOK_SECRET med den råa förfrågningskroppen. Hantera checkout.session.completed, invoice.paid, invoice.payment_failed, customer.subscription.updated, customer.subscription.deleted och customer.subscription.trial_will_end. Spara behandlade händelse-ID:n så att dubbletter ignoreras. Uppdatera användarens status utifrån prenumerationsobjektet, inte utifrån i vilken ordning händelserna kommer.
Lås Pro-funktioner på servern: tillåt dem bara när statusen är active eller trialing och planen är Pro. Visa en banner "betalningen misslyckades, uppdatera ditt kort" när statusen är past_due. Lägg till en knapp Hantera fakturering som öppnar Stripes kundportal för den här användaren.
Uppgraderingar, nedgraderingar och proration
När en kund byter plan skapar ändringen enligt Stripes dokumentation ofta en proration: det nya priset tillämpas på resten av den aktuella faktureringsperioden. Du kan förhandsgranska prorationer eller stänga av dem. Om planerna har samma intervall stannar faktureringsdatumen kvar; om man byter från månadsvis till årsvis flyttas faktureringsdatumet till dagen för bytet. Låter du kunderna byta plan i portalen slipper du skriva den logiken, men bestäm i portalinställningarna vilka byten som är tillåtna.
Testchecklista
Använd Stripes testläge och testkort, och gå igenom varje tillstånd:
- Ny prenumeration ger rätt plan till rätt användare
- Att stänga fliken direkt efter betalning ger ändå åtkomst (bevisar att webhooken fungerar)
- Ett nekat kort vid registrering ger ingenting
- En misslyckad förnyelse sätter kontot i past_due och visar bannern
- Att uppdatera kortet i portalen återställer status active
- Uppgradering och nedgradering ändrar funktioner korrekt
- Uppsägning vid periodens slut behåller åtkomst till slutdatumet, och tar sedan bort den
- Provperiodsanvändare får åtkomst, får påminnelsen, och konverterar eller förlorar åtkomst korrekt
- Att skicka samma webhook-händelse två gånger ändrar ingenting
Stripes testklockor låter dig simulera att tid går, så att du kan testa förnyelser utan att vänta en månad. Kontrollera Stripes aktuella testdokumentation för hur de används.
Vanliga misstag
- Att ge åtkomst på framgångssidan. Kunder kan betala och aldrig nå den. Använd webhooken.
- Att bara hantera första betalningen. Förnyelser, misslyckanden och uppsägningar kommer senare, som händelser.
- Att bara kontrollera planstatus i gränssnittet. Vem som helst kan anropa ditt API direkt.
- En användare, av misstag många prenumerationer. Kontrollera om det redan finns en prenumeration innan du skapar en ny Checkout-session, eller skicka befintliga kunder till portalen i stället.
- Att återkalla åtkomst vid första misslyckade förnyelsen. Kort misslyckas av tråkiga skäl. En kort respitperiod med tydlig banner behåller kunder.
- Att glömma live-webhooken. Test- och live-slutpunkter har olika signeringshemligheter.
- Att ignorera skatt och återbetalningar. Bestäm din återbetalningspolicy och kontrollera dina skatteskyldigheter med en revisor före lansering.
Prenumerationer i Mythex
Appar du bygger på Mythex använder ditt eget Stripe-konto och dina egna nycklar; det finns ingen anslutning till Stripe med ett klick för din app. Lägg till dina testnycklar och pris-ID:n som projekthemligheter, använd prompter som de ovan och testa med Stripes testkort i förhandsgranskningen. Webhooks behöver din apps publika URL, så publicera innan du registrerar slutpunkten i Stripe, och publicera igen efter bytet till live-nycklar så att live-appen hämtar dem. Se Ta emot betalningar med Stripe och Hantera webhooks i din backend. För hela produkten täcker så bygger du en SaaS-MVP vad du bygger runt faktureringen.
Frågor
Vad är det enklaste sättet att lägga till prenumerationer med Stripe?
Skapa en produkt med ett återkommande pris i Stripe-instrumentpanelen, skicka kunderna till Stripe Checkout i prenumerationsläge, hantera prenumerationshändelser med en webhook och länka en knapp Hantera fakturering till Stripes hostade kundportal. Då slipper du bygga kortformulär och skärmar för planbyten själv.
Vilka Stripe-webhook-händelser behöver jag för prenumerationer?
Minst checkout.session.completed för att koppla den nya prenumerationen till din användare, invoice.paid för att bekräfta varje lyckad betalning, invoice.payment_failed för att varna om misslyckade förnyelser, och customer.subscription.updated och customer.subscription.deleted för att följa planändringar och uppsägningar.
Vad händer när en prenumerationsbetalning misslyckas?
Enligt Stripes dokumentation per september 2026 blir prenumerationen oftast past_due, och Stripe kan försöka betala igen utifrån dina inställningar. Efter sista försöket avgör dina instrumentpanelinställningar om den avslutas, markeras som obetald eller lämnas som past_due.
Kan jag erbjuda en gratis provperiod utan att be om kort?
Ja. Stripe stöder gratis provperioder, och dokumentationen beskriver en pausad status för provperioder som slutar utan betalningsmetod när det är inställt så. Att ta kort i förväg ger oftast färre registreringar men fler betalande kunder; testa vad som passar din produkt.