Så lägger du till betalningar i din app: checkout, prenumerationer och webhooks

Det enklaste sättet att lägga till betalningar i din app är Stripe: använd en Payment Link om du bara behöver en knapp "Köp" och kan hantera ordrar för hand, Stripe Checkout om din app behöver veta vem som betalade och reagera automatiskt, och Checkout i prenumerationsläge plus Stripes kundportal för återkommande fakturering. I alla fall utom det enklaste behöver du också en webhook, det vill säga en serverslutpunkt som Stripe anropar när en betalning lyckas. Testa allt med Stripes testnycklar och testkort innan du byter till live-nycklar.

Den här guiden förklarar varje alternativ, webhook-delen som de flesta guider hoppar över och vad du bör kontrollera innan du tar emot riktiga pengar. Stripe-detaljerna är från Stripes egen dokumentation per september 2026.

Varför använda en betalningsleverantör alls

Samla aldrig in kortnummer i egna formulär. Att hantera rå kortdata gör att du omfattas av PCI DSS (kortbranschens säkerhetsstandard) och är ett allvarligt ansvar. En betalningsleverantör som Stripe är värd för betalningsformuläret, sparar kortet, hanterar bankens autentisering och berättar för din app resultatet. Din app ser bara "kund X betalade för Y".

Den här guiden använder Stripe eftersom det är allmänt använt, väldokumenterat och stöds av de flesta AI-appbyggare. Det finns andra leverantörer, och vissa fungerar som "merchant of record" och tar över hanteringen av försäljningsmoms åt dig; om skatteefterlevnad oroar dig är den modellen värd att jämföra.

De tre sätten att ta emot betalningar med Stripe

Payment Links

En Payment Link är en betalningssida som Stripe är värd för och som du skapar i Stripe-instrumentpanelen utan kod. Du får en URL som du kan lägga bakom en knapp i din app, dela i ett mejl eller visa som QR-kod. Stripes dokumentation säger att Payment Links kan sälja en produkt, en prenumeration eller ta emot en donation, och du kan låta kunderna välja vad de betalar eller begränsa antalet köp.

Fångsten: din app vet inte automatiskt att en viss inloggad användare har betalat. För en donationssida eller en liten butik där du fullföljer ordrar för hand utifrån Stripes e-postnotiser är det bra. För "betala för att låsa upp Pro-funktionerna" är det inte det.

Stripe Checkout

Checkout är en betalningssida som din server skapar på begäran för ett specifikt köp. Din server berättar för Stripe vad som köps (och valfritt vilken kund som köper), Stripe returnerar en URL, och du skickar kunden dit. Enligt Stripes dokumentation stöder det både engångs- och prenumerationsbetalningar, som en helt Stripe-driven sida, en sida inbäddad i din webbplats eller ett inbäddat formulär.

Flödet:

1. Kunden klickar på Köp i din app.
2. Din server skapar en Checkout-session med din hemliga nyckel, inklusive ett ID som kopplar den till din användare eller order.
3. Kunden skickas till Stripe och betalar.
4. Stripe skickar tillbaka dem till din framgångssida.
5. Stripe skickar en händelse checkout.session.completed till din webhook, och din server markerar ordern som betald eller låser upp åtkomst.

Steg 2 måste ske på servern, eftersom det använder din hemliga nyckel. Det är huvudorsaken till att Checkout behöver en backend.

Prenumerationer

Prenumerationer använder Checkout i prenumerationsläge med ett återkommande pris som du sätter upp i Stripe. Den första betalningen fungerar som flödet ovan. Därefter sker förnyelser, misslyckade kort, uppgraderingar och uppsägningar över tid, ofta när kunden inte alls är i din app, så din app får veta om dem endast via webhooks.

För att låta kunderna hantera sin egen prenumeration erbjuder Stripe en hostad kundportal. Enligt Stripes dokumentation kan kunderna där uppdatera betalningsmetoder och faktureringsuppgifter, ändra eller säga upp prenumerationer samt visa och ladda ner fakturor. Du konfigurerar den i Stripe-instrumentpanelen och lägger till en knapp "Hantera fakturering" som skickar kunden dit. Då slipper du bygga de skärmarna själv.

Webhooks: delen du inte kan hoppa över

En webhook är en HTTP-förfrågan som Stripe skickar till din server när något händer. (Se vad en webhook är för den allmänna idén.) Stripes guide för fullföljande av ordrar är tydlig: du kan inte enbart förlita dig på framgångssidan för att fullfölja ordrar, eftersom en kund kan betala och sedan tappa anslutningen innan sidan laddas. För prenumerationer och fördröjda betalningsmetoder krävs webhooks.

Händelser värda att hantera

Regler för en korrekt webhook-hanterare

Dessa kommer direkt från Stripes webhook-dokumentation, och AI-genererade hanterare missar ibland någon av dem:

• Verifiera signaturen. Varje händelse innehåller en Stripe-Signature-header. Din hanterare kontrollerar den med slutpunktens signeringshemlighet (den börjar med whsec_). Utan detta kan vem som helst skicka en falsk "betalningen lyckades" till din server.
• Använd den råa förfrågningskroppen. Signaturkontrollerna misslyckas om ditt ramverk tolkar eller ändrar kroppen först.
• Svara snabbt med ett 2xx-svar, och gör sedan långsammare arbete. Timeouts räknas som fel.
• Hantera dubbletter. Stripe kan leverera samma händelse mer än en gång. Spara behandlade händelse-ID:n, eller gör fullföljandet säkert att köra två gånger.
• Anta inte ordning. Stripe garanterar inte att händelser kommer i den ordning de inträffade.
• Räkna med återförsök. I live-läge försöker Stripe leverera misslyckade anrop i upp till tre dagar, så ett kort avbrott förlorar inga betalningar, men din hanterare måste klara sena händelser.

Webhooks behöver en publik HTTPS-adress, så de fungerar oftast först när din app är publicerad (Stripes CLI kan vidarebefordra händelser till en lokal dator för utvecklare).

En prompt som täcker hela flödet

Lägg till ett engångsköp med Stripe Checkout för "Pro-paketet" (pris-ID i STRIPE_PRICE_ID). Skapa Checkout-sessionen på servern med STRIPE_SECRET_KEY från hemligheter, och inkludera den inloggade användarens ID i sessionen. Lägg till en slutpunkt POST /api/stripe/webhook som verifierar Stripe-signaturen med STRIPE_WEBHOOK_SECRET med den råa förfrågningskroppen, hanterar checkout.session.completed och markerar att användaren har Pro-paketet. Gör det säkert om samma händelse kommer två gånger. Sidor för framgång och avbrott. Exponera aldrig den hemliga nyckeln i webbläsaren.

För prenumerationer, lägg till: "Använd prenumerationsläge med STRIPE_PRICE_ID. Hantera invoice.paid, invoice.payment_failed, customer.subscription.updated och customer.subscription.deleted. Lägg till en knapp Hantera fakturering som öppnar Stripes kundportal."

Testläge

Stripe har separata sandbox- (test) och live-miljöer med separata nycklar. Sandbox-nycklar börjar med pk_test_, sk_test_ eller rk_test_; live-nycklar börjar med pk_live_, sk_live_ eller rk_live_. Testtransaktioner flyttar inga pengar.

Nyttiga testkort från Stripes testdokumentation (valfritt framtida utgångsdatum, valfri tresiffrig CVC):

Testa åtminstone:

• En lyckad betalning låser upp rätt sak för rätt användare
• Ett nekat kort visar ett tydligt meddelande och låser upp ingenting
• Att stänga webbläsarfliken direkt efter betalning ger ändå åtkomst (detta bevisar att webhooken fungerar, inte bara framgångssidan)
• Att avbryta på Stripe-sidan för tillbaka användaren till din app utan att något debiteras
• För prenumerationer: säg upp i kundportalen och bekräfta att åtkomsten upphör när den ska

Att gå live

1. Aktivera ditt Stripe-konto med dina företags- och bankuppgifter.
2. Byt till live-nycklar i din apps hemligheter. Stripe rekommenderar begränsade nycklar med bara de behörigheter din integration behöver, i stället för en obegränsad hemlig nyckel.
3. Skapa en live-webhook-slutpunkt som pekar på din publicerade app. Den har en egen signeringshemlighet, skild från testversionen, så uppdatera den.
4. Skapa produkter och priser igen i live-läge; test-läge-ID:n finns inte där.
5. Gör ett riktigt litet köp och återbetala det.

Håll alla nycklar i projektets hemligheter, aldrig i kod eller chatt. Vår säkerhetschecklista går igenom nycklar och verifiering av webhooks mer i detalj.

Skatter, återbetalningar och pappersarbete

Betalningar medför skyldigheter som kod inte löser. Det här är inte skatterådgivning; stäm av med en revisor.

• Försäljningsskatt, moms och GST. Beroende på var du och dina kunder finns kan du behöva registrera dig, ta ut och redovisa skatt. Stripe Tax kan beräkna och ta ut skatt i kassan, bevaka var din försäljning kan skapa en skyldighet och hjälpa till med registreringar och redovisning, men ansvaret ligger kvar hos dig. Merchant-of-record-leverantörer är ett alternativ som tar över mer av detta.
• Återbetalningar och bestridanden. Bestäm din återbetalningspolicy före lansering och lägg den på din webbplats. Bestridanden (chargebacks) förekommer; för journal över vad som köpts och levererats.
• Kvitton och fakturor. Stripe kan skicka kvitton via e-post; företag kan behöva riktiga fakturor.
• Avgifter. Varje leverantör tar betalt per transaktion. Kontrollera leverantörens aktuella prissida i stället för att lita på siffror i artiklar.

Vilken uppsättning som passar din app

• Donationer eller ett fåtal produkter: Payment Links. Se så bygger du en webbplats för välgörenhetsdonationer.
• En butik med varukorg: Checkout med artikelrader och en webhook. Se så bygger du en nätbutik.
• SaaS eller medlemskap: Checkout i prenumerationsläge, webhooks och kundportalen. Se så bygger du en SaaS-MVP och så prissätter du en SaaS-produkt.
• En marknadsplats som betalar ut till säljare: en annan, mer reglerad uppsättning (Stripe Connect eller liknande). Planera för det separat.

Lägga till betalningar i Mythex

Betalningar i appar du bygger på Mythex använder ditt eget Stripe-konto och dina egna nycklar; det finns ingen knapp "Anslut Stripe" med ett klick för din app. Det vanliga flödet:

1. Skaffa Stripe-nycklar för test.
2. Lägg till STRIPE_SECRET_KEY (och webhook-hemligheten senare) i projektets hemligheter, via /secrets, projektinställningarna eller hemlighetskortet som agenten visar när den behöver en nyckel.
3. Be agenten om Checkout med en prompt som den ovan.
4. Testa i förhandsgranskningen med testkort. Publicera innan du registrerar webhooken, eftersom den behöver din publika URL.
5. Efter bytet till live-nycklar publicerar du igen så att den live-appen hämtar dem.

Se Ta emot betalningar med Stripe och Hantera webhooks i din backend i dokumentationen.

Frågor