Je kunt de naam, het e-mailadres en optionele adresgegevens in een betaallink meesturen, zodat de ontvanger ze niet opnieuw hoeft in te voeren. PayRequest gebruikt deze waarden om de gehoste checkout vooraf in te vullen. Het e-mailadres wordt binnen de juiste onderneming gebruikt om de klant te vinden of aan te maken. Gebruik voor gevoelige of afgeschermde handelingen een ondertekende klantroute, niet een aanpasbaar database-ID.
Deze handleiding toont de praktische URL-opbouw, welke velden je kunt vergrendelen en welke gegevens nooit in een openbare link thuishoren.
Beslismatrix voor veilig vooraf invullen
| Gegeven | In een gewone link opnemen? | Waarom |
|---|---|---|
| Product-ID | Ja, na tenantcontrole op de server | Selecteert het product van de juiste verkoper |
| Naam | Meestal | Vermindert typwerk, maar bewijst geen identiteit |
| E-mailadres | Wanneer passend voor het verzendkanaal | Koppelt het klantrecord; blijft zichtbaar in de URL |
| Adres, plaats en postcode | Alleen als de checkout ze echt nodig heeft | Nuttig voor facturatie, maar vergroot blootstelling van persoonsgegevens |
| Intern klant-ID | Niet als losse autorisatiesleutel | Aanpasbare ID's mogen geen identiteit of toegang verlenen |
| Bank-, kaart- of mandaatgegevens | Nooit | Betaalgegevens horen in de beveiligde providerflow |
| Korting, bedrag of producteigendom | Nooit vanuit de browser vertrouwen | Opnieuw berekenen en valideren op de server |
De betaallink opbouwen
Een productcheckout van PayRequest kan deze vorm hebben:
https://payrequest.me/voorbeeld?product=1234&name=Sam%20de%20Vries&email=sam%40example.com
Optionele adresparameters zijn:
&address=Voorbeeldstraat%201&city=Amsterdam&postal=1000AA
Codeer waarden altijd correct voor gebruik in een URL. Een spatie wordt bijvoorbeeld %20 en een apenstaartje kan als %40 worden gecodeerd. Gebruik een standaard URL-builder in plaats van zelf onbehandelde waarden aan elkaar te plakken.
Wat doet PayRequest met deze waarden?
De gehoste pagina controleert of het product hoort bij de merchant van de PayRequest Page. Tijdens de checkout zoekt PayRequest binnen diezelfde tenant naar een klant met het opgegeven e-mailadres. Bestaat die klant, dan wordt de betaling eraan gekoppeld. Anders kan op basis van de ingediende checkoutgegevens een nieuwe klant worden aangemaakt.
Deze matching maakt betalen gemakkelijker, maar bezit van een e-mailadres is geen authenticatie. Toon nooit facturen, abonnementen of privégegevens alleen omdat een URL dat e-mailadres bevat.
Wanneer readonly dynamic fields op de PayRequest Page is ingeschakeld, worden de meegestuurde naam en het e-mailadres wel getoond, maar kan de klant ze niet aanpassen. De productprijs en het terugkerende interval moeten altijd op de server worden gecontroleerd, ongeacht wat in de URL staat.
Herbruikbare of persoonlijke link?
| Situatie | Beste link |
|---|---|
| Openbaar membership van €19 voor iedereen | Herbruikbare productlink zonder persoonsgegevens |
| Afgesproken serviceabonnement van €19 voor één klant | Persoonlijke vooraf ingevulde productlink |
| Factuur met vaste klant en vast bedrag | Factuurspecifieke ondertekende of geauthenticeerde betaalroute |
| Klantaccount, mandaatwijziging of privéhistorie | Login of ondertekende route, geen querystring als identiteit |
| CRM-campagne naar bekende contacten | Link per ontvanger met minimale velden en bewaarbeleid |
Behandel een persoonlijke link als klantcommunicatie, niet als openbare marketing-URL. Verstuur hem via de bedoelde e-mail of het klantgesprek en plak hem niet in openbare analytics, tickets of screenshots.
Customer ID versus ondertekende token
Een losse customer_id=42 lijkt handig, maar is onveilig wanneer de server dit als identiteitsbewijs gebruikt. Iemand kan 42 eenvoudig in 43 veranderen. Tenant-scoping voorkomt een lookup bij een andere onderneming, maar bewijst nog niet dat de ontvanger de genoemde klant is.
Gebruik voor een toekomstige CRM- of API-koppeling een ondoorzichtige ondertekende token die merchant, klant, product en vervaldatum bindt. Controleer bij ontvangst de handtekening en verloopdatum en laad de klant daarna uitsluitend binnen die merchant. Laat een URL alleen autoriteit dragen wanneer hij bewust voor die beperkte handeling is ondertekend.
Privacy- en checkoutchecklist
Controleer vóór het versturen:
- Neem alleen velden op die nodig zijn voor betaling, facturatie of levering.
- Controleer op de server dat het product bij de merchant hoort.
- Bereken prijs, aantal en abonnementsinterval opnieuw op de server.
- Bepaal of de klant vooraf ingevulde gegevens mag corrigeren.
- Log nooit betaalgegevens of gevoelige bankinformatie.
- Vermijd persoonsgegevens in campagnenamen en openbare referrer-URL's.
- Geef ondertekende links één doel en een vervaldatum.
- Test de exacte klantreis op mobiel.
De praktische test: open de definitieve link in een privévenster, controleer product en vooraf ingevulde velden en probeer iedere aanpasbare parameter te wijzigen. Geen enkele wijziging mag tenant, prijs, toegang of een privé-klantrecord kunnen verwisselen.
Minder typwerk zonder zwakkere beveiliging
Met PayRequest betaallinks kun je de checkout vooraf invullen; abonnementen regelen het terugkerende plan en beheer. Gebruik voor de privéfacturen of betaalmethode van een bestaande klant het klantenportaal, niet een querystring die zich als login gedraagt.
Vul gemaksgegevens vooraf in, authenticeer privéhandelingen en valideer bedragen en eigendom op de server. Zo krijgt de klant de kortste bruikbare checkout zonder dat een betaallink een onveilig klantaccount wordt.