Slik legger du til abonnementer med Stripe: planer, prøveperioder, webhooks og mislykkede betalinger

For å legge til abonnementer med Stripe lager du et produkt med en gjentakende pris i Stripe-dashbordet. Deretter sender du kunder til Stripe Checkout i abonnementsmodus fra serveren din, og lar en webhook fortelle appen din når hver betaling lykkes, feiler, endres eller avsluttes. Lagre abonnementsstatusen mot brukeren, og gi tilgang basert på den, ikke på suksessiden. Legg til en knapp Administrer fakturering som åpner Stripes hostede kundeportal, slik at folk kan bytte kort, bytte plan og kansellere uten at du bygger de skjermene selv.

Denne guiden bygger videre på slik legger du til betalinger i appen din, som dekker engangs-Checkout, testmodus og å gå live. Her fokuserer vi på det som er annerledes med løpende fakturering. Stripe-detaljene er hentet fra Stripes dokumentasjon per september 2026.

Hvorfor abonnementer er vanskeligere enn engangsbetalinger

En engangsbetaling skjer mens kunden er i appen din. Et abonnement fortsetter etter at de har gått: fornyelser hver måned, kort som utløper, oppgraderinger midt i en periode, og kanselleringer som trer i kraft ved periodeslutt. Appen din får bare vite om dette gjennom webhooks. De fleste feil med abonnementer kommer av at man behandler den første betalingen som hele historien.

Alternativene dine

For de fleste apper er Checkout pluss portalen det riktige valget. Sammenlign leverandører i Stripe vs Paddle vs Lemon Squeezy hvis skattehåndtering bekymrer deg.

Planlegg prisingen i Stripe først

I Stripe er et produkt det du selger («Pro-plan»), og en pris er hvordan du tar betalt for det («$20 per måned», «$200 per år»). Ett produkt kan ha flere priser. Bestem:

• Hvilke nivåer du tilbyr, og hva hvert nivå låser opp i appen din
• Månedlig, årlig eller begge
• Om du tilbyr prøveperiode, og om den krever kort på forhånd

Opprett produktene og prisene i testmodus, og behold pris-ID-ene. Appen din refererer til dem. Hvis du ikke har bestemt prisingen ennå, les slik prisetter du et SaaS-produkt og freemium vs. gratis prøveperiode.

Livssyklusen til et abonnement du må håndtere

Stripes oversikt over abonnementer lister statusene et abonnement kan ha. De viktigste for tilgang er:

Lagre statusen på bruker- eller kontoposten din, og bygg tilgangen på den. Oppdater den hver gang en relevant webhook kommer.

Webhook-hendelsene du må håndtere

Reglene for håndterere fra Stripes webhook-dokumentasjon gjelder fortsatt: verifiser signaturen med den rå forespørselskroppen, returner et 2xx-svar raskt, håndter duplikater og hendelser i feil rekkefølge, og regn med nye forsøk. Hva er en webhook forklarer ideen, og guiden om betalinger lister reglene i detalj.

Steg for steg

1. Lag produkter og priser i Stripes testmodus.
2. Legg til hemmeligheter: den hemmelige nøkkelen, pris-ID-ene, og senere signeringshemmeligheten for webhooken. Legg dem aldri i frontend-kode.
3. Prissiden: hver plans knapp kaller serveren din, som oppretter en Checkout-økt i abonnementsmodus for den innloggede brukeren. Send med bruker-ID-en din slik at webhooken kan koble betalingen til kontoen.
4. Webhook-endepunkt: verifiser signaturer og håndter hendelsene over, og oppdater én abonnementspost per bruker.
5. Lås funksjoner bak den lagrede statusen og planen, sjekket på serveren for hver beskyttet handling, ikke bare skjulte knapper.
6. Kundeportalen: konfigurer den i Stripe-dashbordet (hvilke planer folk kan bytte til, og om de kan kansellere). Legg deretter til en knapp Administrer fakturering som lager en portalsesjon på serveren og sender brukeren dit.
7. Mislykkede betalinger: velg oppførsel for nye forsøk og hva som skjer etter siste forsøk i Stripes faktureringsinnstillinger. Vis et banner i appen mens statusen er past_due.
8. Test hele livssyklusen, og publiser deretter og registrer den live webhooken.

Ledetekster til KI-byggeren

Legg til abonnementsfakturering med Stripe. Planer: Starter (pris-ID i STRIPE_PRICE_STARTER) og Pro (STRIPE_PRICE_PRO). Prissiden oppretter en Checkout-økt i abonnementsmodus på serveren med STRIPE_SECRET_KEY, med den innloggede brukerens ID knyttet til økten. Lagre Stripe-kunde-ID, abonnements-ID, plan og status på brukeren. Eksponer aldri den hemmelige nøkkelen i nettleseren.

Legg til POST /api/stripe/webhook. Verifiser signaturen med STRIPE_WEBHOOK_SECRET ved hjelp av den rå forespørselskroppen. Håndter checkout.session.completed, invoice.paid, invoice.payment_failed, customer.subscription.updated, customer.subscription.deleted og customer.subscription.trial_will_end. Registrer behandlede hendelses-ID-er slik at duplikater ignoreres. Oppdater brukerens status fra abonnementsobjektet, ikke fra rekkefølgen hendelsene kommer i.

Lås Pro-funksjoner på serveren: tillat dem bare når status er active eller trialing og planen er Pro. Vis et banner «Betalingen feilet, oppdater kortet ditt» når status er past_due. Legg til en knapp Administrer fakturering som åpner Stripes kundeportal for denne brukeren.

Oppgraderinger, nedgraderinger og proratering

Når en kunde bytter plan, skaper endringen ofte en proratering ifølge Stripes dokumentasjon: den nye prisen gjelder for resten av den gjeldende faktureringsperioden. Du kan forhåndsvise proratering eller slå den av. Hvis planene har samme intervall, forblir faktureringsdatoene like. Å gå fra månedlig til årlig flytter faktureringsdatoen til dagen for byttet. Å la kundene bytte plan i portalen sparer deg for å skrive denne logikken selv, men bestem i portalinnstillingene hvilke bytter som er tillatt.

Testsjekkliste

Bruk Stripes testmodus og testkort, og gå gjennom hver tilstand:

• Nytt abonnement gir riktig plan til riktig bruker
• At nettleserfanen lukkes rett etter betaling gir fortsatt tilgang (beviser at webhooken fungerer)
• Et avvist kort ved registrering gir ingen tilgang
• En mislykket fornyelse setter kontoen til past_due og viser banneret
• Å oppdatere kortet i portalen gjenoppretter statusen active
• Oppgradering og nedgradering endrer funksjonene riktig
• Kansellering ved periodeslutt beholder tilgangen til sluttdatoen, og fjerner den deretter
• Brukere i prøveperiode får tilgang, får påminnelsen, og konverterer eller mister tilgang riktig
• Å sende den samme webhook-hendelsen to ganger endrer ingenting

Stripes testklokker lar deg simulere at tid går, slik at du kan teste fornyelser uten å vente en måned. Sjekk Stripes gjeldende testdokumentasjon for hvordan du bruker dem.

Vanlige feil

• Gi tilgang på suksessiden. Kunder kan betale og aldri nå den. Bruk webhooken.
• Bare håndtere den første betalingen. Fornyelser, feil og kanselleringer kommer senere, som hendelser.
• Sjekke planstatus bare i frontend. Hvem som helst kan kalle API-et ditt direkte.
• En bruker, mange abonnementer ved en feil. Sjekk for et eksisterende abonnement før du oppretter en ny Checkout-økt, eller send eksisterende kunder til portalen.
• Fjerne tilgang ved første mislykkede fornyelse. Kort feiler av kjedelige grunner. En kort nådeperiode med et tydelig banner beholder kundene.
• Glemme live-webhooken. Test- og live-endepunkter har forskjellige signeringshemmeligheter.
• Ignorere skatt og refusjoner. Bestem refusjonspolicyen din og sjekk skatteforpliktelsene dine med en regnskapsfører før lansering.

Abonnementer på Mythex

Apper du bygger på Mythex bruker din egen Stripe-konto og dine egne nøkler. Det finnes ingen Stripe-tilkobling med ett klikk for appen din. Legg til testnøklene og pris-ID-ene som prosjekthemmeligheter, bruk ledetekster som de over, og test med Stripes testkort i forhåndsvisningen. Webhooks krever appens offentlige URL, så publiser før du registrerer endepunktet i Stripe, og publiser på nytt etter at du har byttet til live-nøkler, slik at den live appen henter dem. Se Ta betalinger med Stripe og Håndter webhooks i backenden din. For resten av produktet dekker slik bygger du en SaaS-MVP hva du bør bygge rundt faktureringen.

Spørsmål