Embedded payments: een betaalervaring in je toepassing ontwerpen

Begin met de handeling die de gebruiker uitvoert

Beschrijf waar de klant zich bevindt wanneer hij wil betalen. Is de opdracht al definitief, is het bedrag bekend en welke bevestiging verwacht hij? Een knop moet voortkomen uit een bestaande zakelijke aanvraag. Als iedere klik een nieuwe order maakt, wordt herhaald gebruik lastig te onderzoeken. Leg daarom de relatie tussen opdracht en betaalverzoek vast. Een geïntegreerde uitstraling is nuttig wanneer zij de taak duidelijker maakt, maar mag niet verhullen dat de toepassing ook onverwachte acties en onderbrekingen moet kunnen verwerken.

Betaalwidget voor uw website

Kies de overdracht op basis van het hele verloop

Een redirect en een popup hebben andere zichtbare interacties. Vergelijk hoe de klant de betalingsomgeving herkent en hoe hij terugkomt bij de opdracht. Bij een popup moet de toepassing begrijpen dat de gebruiker het venster kan sluiten voordat een resultaat bekend is. Bij een redirect kan de terugkeer achterwege blijven. Beschrijf in beide gevallen het vervolgmoment voor de klant. Een keuze alleen op basis van minder zichtbare paginawisselingen zegt weinig over de betrouwbaarheid van de uiteindelijke zakelijke beslissing.

Integratie en API

Houd vertrouwelijke gegevens op de juiste plaats

De toepassing moet bedrag, valuta en context op de server valideren. Laat de interface geen onbeperkt vertrouwen krijgen omdat zij in je eigen website staat. In het OrsunPay-betaalverloop vindt de gevoelige kaartinvoer plaats in de door de PSP gehoste omgeving. Zorg dat geheime integratiesleutels niet in browsercode terechtkomen. Beoordeel de werkelijk gebruikte inrichting en verantwoordelijkheden met je technische team. Een ingebedde knop geeft op zichzelf geen veiligheids- of nalevingsgarantie en is geen reden om documentatie van de onderliggende provider over te slaan.

Gehoste betaalpagina

Laat de server het resultaat bepalen

Een gesloten popup kan zowel bij een onderbroken proces als bij een al voltooide handeling voorkomen. Ook een terugkeerpagina is geen zelfstandig betaalbewijs. Gebruik daarom een gecontroleerde status en ondertekende servermeldingen. De documentaties van Stripe en Mollie leggen uit hoe gebeurtenissen het zichtbare proces aanvullen. Werk dezelfde opdracht bij wanneer een melding later arriveert en maak verwerking idempotent. Een herhaalde klik of dubbel evenement mag niet twee leveringen veroorzaken. Het scherm moet het bekende resultaat tonen, niet een resultaat afleiden uit alleen venstergedrag.

Maak uitzonderingen bruikbaar voor product en support

Bereid een bericht voor als het resultaat nog wordt gecontroleerd en geef de klant een manier om de opdracht terug te vinden. Bewaar de referenties waarmee support kan zoeken zonder te vragen om onnodige vertrouwelijke gegevens. Test een herhaalde klik, een netwerkvertraging en het sluiten van het venster. Wanneer een fout ontstaat, moet duidelijk zijn of de aanvraag opnieuw mag worden verwerkt of eerst onderzocht moet worden. Deze afspraken voorkomen dat verschillende onderdelen van de toepassing eigen, tegenstrijdige herstelacties starten.

Controleer publicatie en bereik van de widget

OrsunPay bevat een widgetimplementatie voor JavaScript met redirect- en popupgedrag, maar een publieke pakket-URL of publicatie is niet bevestigd. Het productbereik is daarom beperkt en moet voor een concreet gebruik worden afgestemd. Plan geen installatie uit een verondersteld openbaar pakket. De widget vervangt ook geen volledige winkel, ticketing- of donatieomgeving. Je eigen PSP-overeenkomsten blijven gelden en softwarekosten staan los van de afrekening. Een goed ontwerp noemt zowel het gewenste gedrag als de afhankelijkheden die nog moeten worden bevestigd.

• Koppel de knop aan een bestaande zakelijke opdracht.
• Valideer bedrag en context op de server.
• Behandel een gesloten popup niet als betaalresultaat.
• Test herhaalde klikken en vertraagde gebeurtenissen.
• Bevestig het gebruikte pakket en de publicatiestatus vooraf.

Bronnen

• Stripe-documentatie over webhooks
• Mollie-documentatie over betalingen