PayPal i Lovable: kontrollera betalflödet före lansering

Vad som har ändrats

Lovable lade den 8 november 2026 till en koppling som låter en app använda ett befintligt PayPal-konto. Enligt Lovables changelog kan appen skapa en checkout, debitera en godkänd order, göra återbetalningar och läsa orderinformation.

Kopplingen passar exempelvis en butik, donationssida, biljettförsäljning eller bokning där kunden betalar en deposition. Du kan lägga till den från Connectors i Lovable eller be Lovable ansluta PayPal i projektchatten.

Det här är en connector till ditt eget PayPal-konto, inte samma funktion som Lovables inbyggda betalningslösning. Pengarna går till det konto du ansluter och PayPal hanterar sina avgifter och sin betalningsadministration. För livebetalningar behöver du ett verifierat PayPal-företagskonto och en PayPal REST-app med uppgifter för produktionsmiljön.

Lovable låter dig skapa separata anslutningar för sandbox och live. Det är viktigt eftersom PayPal använder olika REST-appar och inloggningsuppgifter för testmiljö och produktion. Namnge gärna anslutningarna tydligt, till exempel PayPal Sandbox och PayPal Live, så att det blir svårt att länka fel miljö till projektet.

Connectorn tar hand om en del teknisk infrastruktur. Hemligheten till PayPal ska inte hamna i besökarens webbläsare, och anropen går via Lovables connector gateway. Lovables dokumentation beskriver också att meddelanden från PayPal kontrolleras innan appen agerar på dem. Men connectorn bestämmer inte när din egen order ska räknas som betald, när en biljett ska skickas eller hur en misslyckad återbetalning ska visas. Den logiken måste fortfarande vara tydlig i appen.

Godkännande är inte samma sak som debitering

Det viktigaste att förstå är att en PayPal-checkout innehåller skilda händelser.

Först skapar appen en order och skickar kunden till PayPal. Kunden loggar in, granskar köpet och godkänner det. Därefter måste appens server begära att betalningen fångas, på engelska capture. Det är då debiteringen genomförs.

Statusen APPROVED betyder därför inte att du säkert har fått betalt. Den betyder att kunden har godkänt ordern hos PayPal. Först när capture har lyckats och betalningen har status COMPLETED bör din app behandla köpet som betalt.

Det här ska inte heller blandas ihop med PayPals särskilda intent AUTHORIZE, som används för att reservera medel inför en senare debitering. Lovables connector beskriver ett flöde där en godkänd order fångas efter checkout. Kundens godkännande är alltså en del av checkouten, inte ett bevis på att en capture har slutförts.

En vanlig men riskabel implementation är att visa en tacksida och samtidigt markera ordern som betald så snart kunden kommer tillbaka från PayPal. Returen visar bara att webbläsaren har navigerat tillbaka. Kunden kan ladda om sidan, öppna samma returadress igen eller hamna där trots att serveranropet misslyckades.

Låt därför servern kontrollera ordern och genomföra capture. Gränssnittet kan visa att betalningen behandlas medan detta sker. Leverans, bokningsbekräftelse, biljett eller annan rättighet ska aktiveras först när appen har en bekräftad betalningsstatus.

Modellera status i din egen databas

Spara inte bara en boolesk kolumn som paid. Betalningar kan vänta, misslyckas och återbetalas delvis. En enda av-eller-på-status tappar viktig information och gör support, avstämning och felsökning svårare.

En enkel lokal modell kan se ut så här:

Spara även PayPals order-id, capture-id och refund-id när de finns. De identifierar olika objekt och behövs för att slå upp rätt händelse. En återbetalning görs mot en capture, inte bara mot ditt interna ordernummer.

Behåll gärna PayPals råa status bredvid din lokala status. Då kan din app använda begripliga interna begrepp utan att kasta bort information som behövs vid felsökning. Spara också när statusen senast kontrollerades och vilken händelse som orsakade ändringen.

PayPal kan skicka statusuppdateringar genom webhooks. En webhook är ett meddelande från PayPal till din server när något händer utan att en användare aktivt laddar en sida. Hanteringen bör tåla att samma meddelande kommer igen. Om en uppdatering redan har behandlats ska appen inte skicka ännu en biljett, minska lagret igen eller upprepa en återbetalning.

Listan över senaste transaktioner bör inte användas som omedelbar bekräftelse i checkouten. Lovable uppger att den kan uppdateras med fördröjning och att Transaction Search måste vara aktiverat i PayPals REST-app. Använd i stället order- och capture-status för det aktuella köpet.

Hantera återbetalningar som egna händelser

Lovables connector kan göra både fullständiga och partiella återbetalningar. Det betyder inte att appen bör ändra ordern direkt till refunded när någon trycker på en knapp.

En återbetalning har ett eget förlopp och kan vara väntande, slutförd, misslyckad eller avbruten. Skapa därför en separat post för varje återbetalningsförsök. Spara vilket capture-id som användes, vem som initierade åtgärden, orsaken, statusen och PayPals refund-id.

Vid en partiell återbetalning behöver appen dessutom räkna samman tidigare återbetalningar. Annars kan en administratör försöka återbetala mer än vad som återstår. Gränssnittet bör visa både den ursprungliga betalningen, redan återbetalat värde och vad som fortfarande kan återbetalas.

Gör återbetalningsfunktionen idempotent. Det innebär att en upprepad begäran med samma avsikt inte ska skapa samma ekonomiska åtgärd igen. Det är särskilt viktigt när ett nätverksfel gör att appen inte vet om PayPal hann behandla anropet. Kontrollera aktuell status innan du försöker igen och återanvänd en unik referens för samma operation om implementationen stödjer det.

Tänk också på återbetalningar som görs direkt i PayPals administrationsgränssnitt. Din databas kan annars fortsätta visa ordern som betald trots att pengarna har skickats tillbaka. Kontrollera att webhookflödet eller en schemalagd avstämning fångar upp externa ändringar.

Återbetalningen är den tekniska pengahändelsen. Vad som samtidigt ska hända med en bokning, biljett, donation eller leverans är en separat verksamhetsregel. En återbetalad betalning innebär inte automatiskt att appen vet om en plats ska frigöras, en biljett spärras eller en beställning stoppas.

Testa hela flödet i sandbox

Börja med PayPals sandbox och länka endast sandbox-anslutningen till testprojektet. Använd separata testkonton för säljare och köpare. Kontrollera resultatet både i appens databas och i PayPals testmiljö – inte bara genom vad gränssnittet visar.

Gå igenom följande situationer:

• Kunden godkänner checkouten och capture slutförs innan ordern markeras som betald.
• Kunden avbryter hos PayPal och kommer tillbaka utan att ordern aktiveras.
• Kunden godkänner men capture blir väntande eller misslyckas.
• Retursidan laddas om utan att capture eller leverans upprepas.
• Betalknappen trycks flera gånger utan att parallella orderflöden skapas.
• Samma webhook behandlas igen utan dubbla utskick eller statusändringar.
• En fullständig återbetalning uppdaterar både betalningen och ordervyn.
• En partiell återbetalning lämnar korrekt kvarvarande värde.
• En återbetalning från PayPals eget gränssnitt syns senare i appen.
• En saknad, borttagen eller felaktigt länkad connector ger ett begripligt fel.
• En användare utan rätt behörighet inte kan genomföra återbetalningar.
• Loggarna innehåller användbara id:n men aldrig PayPal-hemligheten.

Be gärna Lovable beskriva det genererade betalflödet i klartext: var ordern skapas, var capture sker, vilka databasfält som ändras och vilka webhookhändelser som hanteras. Be sedan Lovable lägga till tester för omladdning, upprepade anrop och misslyckade svar. Att en checkout fungerar i det lyckade standardfallet säger lite om hur appen beter sig när nätverket eller PayPal svarar oväntat.

Kontrollera detta före livebetalningar

När sandboxflödet är stabilt skapar du en separat liveanslutning med uppgifter från PayPals produktionsmiljö. Koppla bort sandbox från projektet innan liveanslutningen länkas och verifiera att publicerad kod använder rätt connector.

Gör en sista kontroll:

• Hemligheten finns endast i connectorn och exponeras inte i klientkod, loggar eller databastabeller.
• Belopp, valuta och innehåll räknas fram eller valideras på servern.
• En order blir inte betald enbart för att kunden når retursidan.
• Leverans sker först efter bekräftad capture.
• Väntande och misslyckade betalningar har tydliga användartexter.
• Capture och återbetalningar kan återförsökas utan dubbla ekonomiska händelser.
• Webhooks kan tas emot, verifieras och behandlas flera gånger säkert.
• Manuella ändringar i PayPal kan stämmas av mot din databas.
• Endast rätt roller kan se betalningsuppgifter och initiera återbetalningar.
• Supportvyn visar PayPals order-, capture- och refund-id.

Genomför därefter en kontrollerad livetransaktion och följ den genom godkännande, capture, lokal orderstatus och återbetalning. Kontrollera vad kunden ser i varje läge och vad en administratör kan använda för att förstå händelseförloppet.

PayPal-connectorn minskar arbetet med själva API-anslutningen, men ett hållbart betalflöde kräver fortfarande tydliga tillstånd, säkra serverbeslut och testade felvägar. När betalningen behöver bli en pålitlig del av hela tjänsten är nästa steg att gå från prototyp till produkt.

---

Källa: Lovable changelog