Betaling og adgang

Abonnementer og adgang: lad ikke ét betalingsfelt styre hele appen

Et abonnement er ikke bare “betalt” eller “ikke betalt”. Prøveperioder, fornyelser, mislykkede betalinger, planskift og opsigelser sker over tid. Appen skal derfor have en tydelig regel for, hvornår en kunde får, beholder og mister adgang – også når events kommer flere gange, i forkert rækkefølge eller slet ikke når frem første gang.

Adskil betaling, abonnement og produktadgang

Betalingsudbyderen ved, hvad der er faktureret og betalt. Jeres app ved, hvilken virksomhed, bruger og funktion betalingen skal åbne. De to modeller skal forbindes, men de bør ikke være den samme databasepost eller en enkelt boolean.

Betaling: Et konkret forsøg eller en faktura med beløb, valuta og betalingsstatus.
Abonnement: Aftalen om produkt, pris, periode, prøveperiode, fornyelse og opsigelse.
Adgang: Den serverhåndhævede ret til bestemte funktioner for en bestemt kunde.

Gem stabile eksterne referencer som kunde-, abonnements-, produkt- og pris-id sammen med appens eget virksomheds-id. Gem også den senest afstemte status og tidspunktet for afstemningen. Adgangskontrollen skal bruge en lokal, serverstyret regel eller udbyderens dokumenterede entitlement-model – aldrig tekst fra retur-URL'en eller et produktnavn, browseren selv sender.

Skriv adgangspolitikken før webhookkoden

Stripe har blandt andet statusserne trialing, active, incomplete, past_due, unpaid, paused og canceled. De beskriver faktureringens tilstand – ikke automatisk virksomhedens aftale om produktadgang. Skriv derfor beslutningen som en tabel, som både udvikling, support og økonomi kan forstå.

Situation	Mulig adgangsregel	Hvad appen skal vise
Gyldig prøveperiode	Åbn de aftalte prøvefunktioner til slutdatoen	Plan, slutdato og hvad der sker bagefter
Aktiv og bekræftet	Åbn funktionerne i den aktuelle plan	Plan, næste fornyelse og selvbetjening
Første betaling mangler	Åbn ikke betalingskrævende adgang endnu	Betaling mangler eller kræver handling
Fornyelse fejler	Brug en bevidst frist eller begrænsning – ikke et tilfældigt udfald	Hvad kunden skal gøre, og hvornår adgang ændres
Opsagt ved periodens udløb	Bevar den betalte adgang til den aftalte slutdato	Præcis slutdato og mulighed for at fortryde før udløb
Udløbet eller endeligt opsagt	Luk betalte funktioner efter den dokumenterede regel	Læsbar status, dataadgang og vej til genaktivering

Status active er ikke altid lig med “alle fakturaer er betalt”. Stripe dokumenterer blandt andet, at en aktiv abonnementsstatus kan eksistere med andre åbne fakturaer, og at visse fakturerings- og betalingsmetoder har en anden timing. Brug den valgte betalingsmetode, fakturastatus og jeres egen adgangspolitik samlet.

Opret abonnement og kundeportal på serveren

Browseren må vælge mellem de planer, I faktisk tilbyder, men serveren skal koble valget til et kendt pris-id, den indloggede virksomhed og den rigtige betalingskunde. Accepter ikke frit beløb, valuta, prøveperiode, rabat, virksomheds-id eller kunde-id fra klienten.

Find den lokale kunde: Udled virksomheden af den servervaliderede session og kontrollér, hvem der må ændre abonnementet.
Vælg en tilladt plan: Kortlæg et internt plannavn til et aktivt eksternt produkt- og pris-id.
Opret server-side: Opret Checkout, abonnement eller ændring med den hemmelige API-nøgle uden for frontend.
Gem relationen: Forbind virksomhed, betalingskunde og abonnement med stabile id'er.
Åbn kundeportalen sikkert: Opret en kortlivet portalsession på serveren for netop den kunde, som den aktuelle bruger må administrere.

En hostet kundeportal kan håndtere betalingsoplysninger, fakturaer, planskift og opsigelse uden at appen bygger egne kort- og fakturaskærme. Aktivér kun de muligheder, som jeres produkt- og adgangsmodel kan håndtere, og test hver tilladt ændring.

Lad verificerede webhooks opdatere den lokale adgang

Abonnementshændelser sker asynkront: en fornyelse kan ske uden en åben browser, og en betaling kan kræve handling eller fejle senere. Webhooken skal derfor være den sikre beskedvej fra udbyderen til appen. Retur-siden kan vise status, men må ikke alene åbne en betalt funktion.

Verificér afsenderen: Kontrollér signaturen med endpointets secret og den rå request-body, før eventet får virkning.
Gem før behandling: Registrér event-id, type, relevant objekt-id og modtagelsestid uden at kopiere unødige betalingsdata.
Tål dubletter: Samme event kan blive leveret igen. Opdateringen og eventuelle mails skal være sikre at gentage.
Forvent forkert rækkefølge: Stripe garanterer ikke leveringsrækkefølgen. Hent den aktuelle abonnements- eller fakturaressource, når en gammel payload ikke er et sikkert facit.
Svar hurtigt: Kvittér efter sikker registrering, og flyt langsom adgangsberegning, mail og integrationer til kontrolleret efterbehandling.
Opdatér atomisk: Gem ny abonnementsstatus, adgang og behandlet event samlet eller med en genkørbar arbejdsgang.

Lyt kun til de eventtyper, integrationen faktisk bruger. Et lille, dokumenteret sæt er lettere at teste end “alle events”. Det kan eksempelvis omfatte ændringer i abonnementet, betalt eller fejlet faktura og eventuelle entitlement-ændringer.

Planskift og opsigelse kræver datoer – ikke gæt

Et planskift kan gælde straks eller fra næste periode og kan oprette en forholdsmæssig regulering. En opsigelse kan tilsvarende gælde nu eller ved periodens udløb. Vis den konkrete virkning før bekræftelse, og opdatér først produktadgangen efter den status og dato, som udbyderen efterfølgende bekræfter.

Opgradering: Aftal om højere adgang åbner efter bekræftet betaling eller straks efter en anden tydelig forretningsregel.
Nedgradering: Kontrollér hvad der sker med data eller brugere, som ligger over den nye plans grænser; slet aldrig automatisk som skjult følge.
Opsigelse ved periodeslut: Bevar adgang indtil den bekræftede slutdato, og vis at automatisk fornyelse er stoppet.
Øjeblikkelig opsigelse: Aftal særskilt virkning på adgang, refundering, åbne fakturaer, dataeksport og genaktivering.

Afstem regelmæssigt – webhooks kan ikke stå alene

Et endpoint kan have været nede, en person kan have ændret abonnementet i udbyderens dashboard, eller en lokal opdatering kan være fejlet efter kvitteringen. Kør derfor en periodisk afstemning mellem lokale kunder og betalingsudbyderens aktuelle abonnementer.

Find lokal adgang uden et gyldigt eksternt abonnement – og abonnementer uden en lokal virksomhed.
Sammenlign produkt, pris, status, slutdato, opsigelsesflag og seneste relevante faktura.
Registrér afvigelsen, ret kun efter en dokumenteret regel, og send ukendte tilfælde til en navngiven ansvarlig.
Mål sidste succesfulde webhook og afstemning, antal fejl og hvor længe en ukendt status har stået.

Afstemning er også vejen tilbage efter en driftsfejl: Appen skal kunne genberegne den lokale adgang ud fra betroede kilder uden at genudsende velkomstmails eller udføre den samme ændring flere gange.

Test måneder på timer – i et isoleret miljø

En vellykket første Checkout tester ikke en fornyelse næste måned. Stripe kan simulere Billing-forløb over tid i en sandbox med test clocks. Brug simuleringen til at udløse de statusser, webhooks og datoer, som ellers kræver lang ventetid, og kontrollér både adgang, beskeder, logs og afstemning.

Ny kunde med vellykket første betaling og korrekt planadgang.
Prøveperiode med og uden gyldig betalingsmetode ved udløb.
Fornyelse der lykkes, fejler, kræver handling og senere bliver betalt.
Webhook der leveres som dublet, forsinket og i en anden rækkefølge.
Opgradering og nedgradering nu eller ved næste periode.
Opsigelse nu, opsigelse ved periodens udløb og fortrydelse før slutdato.
Manglende webhook efterfulgt af en afstemning, der reparerer den lokale status.
Bruger uden rettighed, der forsøger at åbne kundeportal eller ændre en anden virksomheds abonnement.

Typiske fejl

Et felt hedder isPaid: Prøveperioder, fejl, periodeslut og planskift kan ikke beskrives sikkert.
Retur-siden åbner produktet: En ændret eller genåbnet URL får adgang uden en verificeret serverstatus.
Browseren sender kunde-id'et: En bruger kan forsøge at åbne portal eller ændre abonnement for en anden virksomhed.
Første fejl lukker straks: Midlertidig betalingsfejl bliver til uventet driftsstop uden en bevidst frist eller besked.
Opsigelse lukker med det samme: Kunden mister den periode, som stadig skal være aktiv efter den valgte model.
Eventrækkefølgen er facit: Et forsinket event overskriver en nyere, korrekt adgangstilstand.
Kun webhooks kontrolleres: En mistet levering eller manuel dashboardændring opdages aldrig ved afstemning.
Test stopper ved første køb: Ingen har afprøvet fornyelse, mislykket betaling, planskift eller periodeslut.

Tjekliste før abonnementer styrer rigtig adgang

☐ Betaling, abonnement og produktadgang er adskilte begreber i data og kode.
☐ Virksomhed, betalingskunde, abonnement, produkt og pris forbindes med stabile id'er.
☐ Adgangspolitikken beskriver prøveperiode, aktiv, første betalingsfejl, fornyelsesfejl, opsigelse og udløb.
☐ Serveren vælger tilladte priser og udleder virksomhed og betalingskunde af den validerede session.
☐ Kundeportalen kan kun åbnes for en virksomhed, den aktuelle bruger må administrere.
☐ Retur-URL og frontendstatus kan ikke alene åbne eller lukke betalte funktioner.
☐ Webhooks verificerer signaturen på den rå body og er sikre ved dubletter og forkert rækkefølge.
☐ Lokal adgang opdateres atomisk eller gennem en dokumenteret, genkørbar arbejdsgang.
☐ Planskift og opsigelse viser pris-, adgangs- og datakonsekvens før bekræftelse.
☐ En periodisk afstemning finder manglende events og uoverensstemmelser.
☐ Alarmer dækker fejlede webhooks, gammel ukendt status og mislykket afstemning.
☐ Fornyelse, fejl, prøveperiode, planskift og opsigelse er testet over simuleret tid.

Relaterede guides

Sikker onlinebetaling fra ordre til bekræftet levering Webhooks med signaturer, dubletter og genbehandling Roller og serverhåndhævede rettigheder Pengebeløb, valuta og afrunding Logning, overvågning og alarmer Se hele guidebiblioteket

Officielle kilder

Statusser, events, portalindstillinger og betalingsmetoder kan ændre sig. Stripe er det konkrete eksempel i guiden; brug den valgte betalingsudbyders aktuelle dokumentation og testmiljø, hvis appen bruger en anden løsning.

Virker abonnementet, men er adgangen stadig bundet til den glade vej?

Startklar er til virksomheder med en fungerende AI-bygget app, som skal kunne bruges sikkert i hverdagen. Vi kan gennemgå betalingsflow, webhook, adgangsmodel, afstemning og test ud fra den stack og udbyder, appen allerede bruger.

Se Startklar-forløbet