Wie inloggen en betalen uitbesteedt aan gespecialiseerde providers, houdt wachtwoorden en kaartnummers van de eigen servers. Daarmee verandert niet wie de code bezit die controleert of iemand is ingelogd, welk abonnement hij koos en wat er gebeurt als een betaling mislukt. In een AI-gebouwde SaaS heeft de AI-codingtool die code geschreven. De beveiliging van login- en betaalintegraties komt dus neer op een review van de code die uw product met zijn providers verbindt.
Deze gids geeft bestuurders van AI-gebouwde SaaS een reviewplan voor beide integraties: vijf authenticatiecontroles die laten zien of de login op de server wordt afgedwongen, zes betaalcontroles die omzet en abonnementsstatus beschermen, de EU-regels die gelden (PSD2, PCI DSS en de AVG (GDPR)) en de volgorde waarin u alles controleert voordat u live betalingen ontvangt. De meeste controles eindigen met een vraag voor uw developer. De gids hoort bij onze handleiding over AI-gebouwde producten veilig in productie.
TL;DR
Payment integration security betekent de verbinding tussen uw SaaS en uw betaalprovider beschermen, inclusief de beslissingen die toegang geven tot betaalde functies.
- Authenticatie vraagt om vijf controles: sessies valideren op de server, herstellinks, sessies laten verlopen en uitloggen, MFA voor accounts met veel rechten, en eigenaarschap van het loginsysteem.
- Betalingen vragen om zes controles: de opzet van de checkout, verificatie van webhooks, idempotency, prijzen op de server, abonnementsstatus en het afhandelen van fouten.
- Laat beide integraties reviewen voordat u live betalingen ontvangt. Zet de betreffende release stil als een vervalste identiteit, een vals betaalbericht of een aangepaste prijs toegang kan geven. Onbekende uitkomsten vragen om onderzoek; een geslaagde checkout alleen bewijst niet dat u klaar bent.
Waarom authenticatie en betalingen eerst komen
Authenticatie en betalingen komen eerst omdat een fout in een van beide de grootste impact heeft in een SaaS-product. Faalt de authenticatie, dan kan een aanvaller een account overnemen en valt elke maatregel weg die afhangt van wie de gebruiker is. Faalt de betaalintegratie, dan is de schade financieel: betaalde abonnementen die gratis worden gebruikt, dubbele afschrijvingen en terugbetalingen die de toegang niet intrekken. Beide stromen verwerken bovendien persoonsgegevens, dus één bug kan tegelijk een beveiligingsincident en een AVG-vraag worden.
Providers nemen een deel van dit risico over, niet alles. Gehoste authenticatiediensten zoals Auth0, Clerk, Firebase Auth of Supabase Auth bewaren de wachtwoorden; Stripe, Mollie of Adyen beheren de kaartgegevens. De code die het antwoord van de provider leest en bepaalt wat er daarna gebeurt, staat in uw eigen codebase.
Twee verwante onderwerpen hebben een eigen gids: API-keys en secrets van providers op de server houden, en broken access control, dat bepaalt wat een ingelogde gebruiker mag zien of wijzigen.
Neemt uw product betalingen aan of bewaart het klantgegevens achter een login, laat dan eerst deze twee integraties reviewen, nog vóór performance of codestijl. B2B-teams die single sign-on (SSO) willen aanbieden, laten de login eerst reviewen, omdat SSO een tweede inlogroute toevoegt aan dezelfde sessieafhandeling.
Authenticatie: vijf controles voor een AI-gebouwde SaaS
Authenticatie stelt vast wie uw product gebruikt. In een AI-gebouwde SaaS kunt u de belangrijkste best practices voor authenticatie controleren zonder code te lezen: vijf controles, elk met een vraag voor uw developer. Twee begrippen helpen daarbij: een sessie houdt bij wie is ingelogd, en een token is de digitale toegangspas die de browser bij elk verzoek meestuurt.
Inloggen gecontroleerd op de server, niet in de browser
Uw systeem moet de digitale toegangspas op de eigen server controleren, elke keer dat iemand gegevens opvraagt. Een pagina of knop verbergen in de browser verandert alleen wat mensen zien; met eenvoudige tools stuurt iemand verzoeken rechtstreeks naar uw systeem en slaat hij het scherm over. Inlogcontroles die alleen in de browser draaien zijn een van de zeven beveiligingsrisico’s van vibe coding. Vraag: “Wat gebeurt er als iemand klantgegevens opvraagt zonder in te loggen?” Het antwoord dat u wilt horen: “Dat wordt geweigerd, en hier is de test die het aantoont.”
Wachtwoordreset en magic links
De link ‘wachtwoord vergeten’ is een tweede ingang tot elk account. Is die zwak, dan kan iemand een account overnemen zonder het wachtwoord te kennen. Een veilige resetlink werkt één keer, verloopt na korte tijd en gaat alleen naar het e-mailadres dat al bij het account hoort. De pagina toont bovendien dezelfde melding, of een e-mailadres nu geregistreerd is of niet, zodat buitenstaanders niet kunnen testen wie uw klanten zijn. Deze punten volgen de richtlijnen van OWASP voor wachtwoordresets (OWASP is een open community die richtlijnen voor webbeveiliging publiceert). Dezelfde regels gelden voor magic links, de inloglinks die per e-mail worden verstuurd. Vraag: “Wat gebeurt er als een resetlink twee keer wordt gebruikt?”
Sessies laten verlopen en uitloggen
Wie op ‘uitloggen’ klikt, moet de sessie op uw server beëindigen, niet alleen in de browser. Anders kan iedereen die de digitale toegangspas heeft gekopieerd, bijvoorbeeld op een gedeelde computer, het account blijven gebruiken. Ook de opslagplek van die pas telt: OWASP raadt af de pas te bewaren waar elk script op de pagina hem kan lezen, omdat één geïnjecteerd script (een aanval die cross-site scripting of XSS heet) hem dan kan kopiëren. Vraag: “Werkt mijn oude sessie nog nadat ik ben uitgelogd?”
MFA voor admin- en eigenaaraccounts
Multi-factor authentication (MFA) betekent een tweede bewijs na het wachtwoord, zoals een code uit een app op uw telefoon. Maak MFA verplicht voor iedereen die alle klanten kan zien of de facturatie kan wijzigen: founders, admins en supportmedewerkers. Zonder MFA legt één gestolen adminwachtwoord alle klanten tegelijk bloot. OWASP adviseert teams om MFA verplicht te stellen voor beheerders en andere gebruikers met veel rechten. Voor gewone gebruikers kan MFA optioneel blijven tot uw B2B-klanten erom vragen. Vraag: “Is MFA verplicht voor elk admin-, eigenaar- en supportaccount?”
Zelf een login bouwen of een provider gebruiken
Gebruik een gevestigde loginprovider. Bouwt u de login zelf, dan is uw team zolang het product bestaat verantwoordelijk voor wachtwoordopslag, bescherming tegen brute-force-aanvallen, accountherstel en MFA. Een provider neemt de wachtwoordopslag over, maar uw product moet de andere maatregelen nog steeds afdwingen en laten reviewen.
Twijfelt u bij een van deze vijf vragen, markeer de login dan als niet gereviewd en plan een review.
Payment integration security: zes controles
Payment integration security vraagt om betrouwbaar bewijs van betaling en een juiste koppeling tussen dat bewijs en betaalde toegang. Vraag de reviewer om de echte integratiecode te bekijken en daarna niet alleen geslaagde aankopen te testen, maar ook verzoeken die moeten mislukken.
| Controle | Wat kan misgaan | Wat het u kost | Oplossen vóór livegang? |
|---|---|---|---|
| Gehoste checkout of eigen kaartformulier | Kaartgegevens lopen via uw eigen servers | Meer compliancewerk en risico voor uw bedrijf | Beslissen vóór livegang |
| Geverifieerde betaalberichten | Accepteert een vals bericht ‘betaling ontvangen’ | Betaalde abonnementen gratis ontgrendeld | Ja |
| Eén betaling, één effect | Verwerkt een herhaald bericht twee keer | Dubbel tegoed of een verkeerde accountstatus | Ja |
| Prijzen op de server | Neemt de prijs over uit de browser van de klant | Duurste abonnement gekocht voor de laagste prijs | Ja |
| Abonnementen gelijk met de provider | Volgt alleen geslaagde betalingen | Opgezegde klanten houden toegang; betalende klanten worden buitengesloten | Ja |
| Fouten betekenen ‘niet betaald’ | Telt een fout of onbekende status als betaald | Gratis toegang en een administratie die niet klopt | Ja |
Gehoste checkout of eigen kaartformulier
Een gehoste checkout is een betaalpagina die uw betaalprovider beheert: de klant vult de kaartgegevens daar in, niet op uw site. Kies daarvoor, tenzij volledige controle over de vormgeving van de betaalstap het extra compliancewerk waard is. Kaartgegevens buiten uw servers houden verlaagt uw verplichtingen onder PCI DSS, de beveiligingsstandaard van de kaartindustrie. Een kaartformulier dat uw team zelf bouwt, legt meer van dat werk bij uw bedrijf. Sommige providers bieden ook betaalvelden aan die in uw eigen pagina staan; vraag uw provider hoe die optie wordt ingedeeld. Vraag uw developer: “Vullen klanten hun kaartgegevens in op de betaalpagina van onze provider of op ons eigen formulier?”
Geverifieerde betaalberichten
Als een klant betaalt, stuurt uw betaalprovider uw systeem een kort automatisch bericht: ‘betaling ontvangen’. Zo’n bericht heet een webhook. Controleert uw systeem niet of het bericht echt van de provider komt, dan kan iedereen die het adres vindt een vals bericht sturen en gratis een betaald abonnement ontgrendelen. Providers maken die controle mogelijk, bijvoorbeeld door elk bericht te ondertekenen met een geheime sleutel die uw systeem controleert, of door alleen een betalingsreferentie te sturen die uw systeem bij de provider opzoekt. Uw systeem moet ook dubbele berichten weigeren. Vraag: “Hoe weet ons systeem dat een betaalbericht echt is?”
Eén betaling, één effect
Betaalproviders sturen een bericht opnieuw als uw systeem de ontvangst niet bevestigt, dus dezelfde betaalmelding kan meer dan eens binnenkomen. Verwerkt uw systeem die melding elke keer, dan kan een klant dubbel tegoed, dubbele facturen of een verkeerde accountstatus krijgen. De oplossing: leg elk verwerkt bericht vast, negeer herhalingen en bevestig de ontvangst snel, zodat de provider stopt met opnieuw versturen. Dit heet idempotency. Toets uw proces met de vraag: “Wat gebeurt er als hetzelfde betaalbericht twee keer binnenkomt?”
Prijzen en abonnementen bepaald op de server
Uw server bepaalt het bedrag dat een klant betaalt, niet de browser. Gebruikt uw checkout prijs-, abonnements- of kortingsgegevens uit de browser, dan kan iedereen met wat technische kennis die aanpassen en uw duurste abonnement voor de laagste prijs kopen. De browser stuurt alleen de gekozen optie, zoals Pro jaarlijks. Uw server zoekt de prijs op en maakt de checkout aan. Toets uw proces met de vraag: “Waar komt het bedrag op onze checkoutpagina vandaan?”
Abonnementen die overeenkomen met de provider
Wie betaalde functies krijgt, moet overeenkomen met wat uw betaalprovider meldt, inclusief opzeggingen, mislukte verlengingen, terugbetalingen en chargebacks. Luistert uw systeem alleen naar geslaagde betalingen, dan houden klanten die opzeggen hun toegang en kan één gemist bericht een betalende klant buitensluiten. Berichten kunnen ook in een andere volgorde binnenkomen. Uw systeem controleert daarom de actuele status van het abonnement bij de provider en vertrouwt niet alleen op het laatste bericht. Vraag om een test voor elk geval: upgrade, downgrade, opzegging, mislukte verlenging en terugbetaling.
Fouten die standaard ‘niet betaald’ betekenen
Behandel elke onduidelijke betaling als niet betaald. Time-outs, geweigerde kaarten, fouten of onbekende statussen mogen geen betaalde functies ontgrendelen. AI-gegenereerde code kan een onbekende status als geslaagd behandelen of standaard op actief zetten, waardoor functies vrijkomen zonder bevestiging. Geef pas toegang nadat de provider de betaling bevestigt, en leg elk onduidelijk geval vast voor opvolging. Anders geeft u functies weg en sluit uw financiële administratie niet aan op die van de provider. Vraag: “Wat gebeurt er als een betaling mislukt of de status onduidelijk is?”
Het dashboard van uw betaalprovider toont geslaagde betalingen. Het toont geen systeem dat valse betaalberichten accepteert of de prijs uit de browser overneemt.
Een onafhankelijke AI-built product review leest de integratiecode rond uw providers en vertelt u in begrijpelijke taal wat u moet oplossen voordat u live betalingen ontvangt.
EU-regels die beide integraties bepalen
Betaalauthenticatie, beveiligingsstandaarden voor kaarten en de bescherming van persoonsgegevens dekken in de EU verschillende verantwoordelijkheden. Toets elk ervan aan uw werkelijke betaalmethoden, gegevensstromen en contracten.
- PSD2 (Richtlijn (EU) 2015/2366), artikel 97, stelt eisen aan sterke klantauthenticatie (SCA) voor betaaldienstverleners in de betaalstromen waarop de richtlijn van toepassing is. SCA gebruikt ten minste twee onafhankelijke factoren; 3D Secure ondersteunt dit bij kaartbetalingen. Uw integratie moet de vereiste authenticatie, annulering en mislukking afhandelen. Uitzonderingen en de reikwijdte van de transactie tellen mee; niet elke betaling vraagt om een zichtbare extra stap.
- PCI DSS is de beveiligingsstandaard van de kaartindustrie; de complianceprogramma’s worden beheerd door kaartmerken en acquirers. Wie het verzamelen van kaartgegevens uitbesteedt, houdt verantwoordelijkheden als merchant. Stem met uw provider of acquirer af welke verplichtingen gelden voor uw checkoutopzet. Bij iDEAL betaalt de klant via de eigen bank en verwerkt uw checkout geen kaartgegevens; de SCA-regels van PSD2 gelden daar wel.
- AVG-artikel 32 verplicht verwerkingsverantwoordelijken en verwerkers om technische en organisatorische beveiligingsmaatregelen te nemen die passen bij het risico. E-mailadressen van accounts, herleidbare loginregistraties en factuurgegevens van klanten moeten worden beschermd. Houd volledige authenticatietokens en gevoelige kaartgegevens uit uw logs en spreek af wie de bewaarde gegevens mag inzien.
Deze controles betreffen twee integratiegrenzen. Gebruik de bredere checklist voor de review van AI-gebouwde SaaS om de rest van het product te toetsen voordat u meer klanten toegang geeft.
In welke volgorde laat u authenticatie en betalingen reviewen?
Review de controles in de volgorde van wie een fout kan misbruiken: eerst iedereen op internet, dan elke geregistreerde gebruiker, daarna randgevallen.
- Inloggen gecontroleerd op de server: zonder deze controle kan iedereen elke andere maatregel omzeilen.
- Geverifieerde betaalberichten: iedereen die het berichtadres vindt, kan een ontbrekende controle misbruiken, zonder account.
- Prijzen en abonnementen op de server: elke geregistreerde gebruiker kan een checkoutverzoek aanpassen.
- Foutafhandeling en abonnementsstatus: die bepalen wie toegang houdt na een weigering, opzegging of terugbetaling.
- Eén betaling, één effect: herhaalde berichten leiden tot verkeerd tegoed en verkeerde facturen.
- Resetlinks, uitloggen en MFA voor admins: deze sluiten routes naar accountovername af.
- Type checkout en EU-bevestigingen: leg vóór livegang vast of u een gehoste of ingebedde checkout gebruikt en welke delen van PCI DSS en SCA uw provider afdekt.
Authenticatie en betalingen zijn één onderdeel van een launchreview. De volledige set controles voor SaaS, inclusief tenantisolatie, staat in de review van AI-gebouwde SaaS.
Hoe Sunbytes authenticatie- en betaalflows reviewt
Werkt een provider correct maar geeft uw app de verkeerde toegang, dan moet de review de applicatiecode bekijken die die beslissingen verbindt. Neem uw authenticatieopzet, betaalmethoden en openstaande controles mee naar een scopinggesprek met Sunbytes.
Sunbytes reviewt die code onafhankelijk van wie hem herstelt, met software engineering en security samen beoordeeld. Onze AI-built product review omvat security en data en de betrouwbaarheid van kritieke flows; daar zitten sessiecontroles, webhookverwerking en abonnementslogica. U ontvangt duidelijke bevindingen met het bewijs erachter, een geprioriteerd actieplan dat scheidt wat nu moet en wat kan wachten, en een technische overdracht waarmee uw team of AI-codingtool aan de slag kan. Het werk valt onder een ISO 27001-gecertificeerd ISMS met Nederlandse leiding, met ruim 15 jaar ervaring en meer dan 300 opgeleverde projecten.
Wat een review moet omvatten, hangt af van uw stack en providers; de scope bepalen we per situatie. Neem contact op met ons team over uw authenticatie- en betaalflows voordat u live betalingen ontvangt.
