Succesmelding na betaling en aanvraag onderscheiden

Een formulier kent minstens drie momenten die elk een eigen status verdienen. Verzonden betekent dat de gegevens bij jou zijn aangekomen. Goedgekeurd betekent dat iemand van je team de aanvraag heeft beoordeeld en aanvaard. Betaald betekent dat het geld daadwerkelijk bevestigd is, volgens jouw betaalprovider.

Het probleem ontstaat wanneer de tekst op het scherm niet overeenkomt met wat er gebeurd is. De Web Accessibility Initiative adviseert in de W3C-handleiding voor toegankelijke formulieren om gebruikers te informeren over geslaagde afronding, fouten en hoe ze die herstellen. Die melding moet dus iets zeggen wat klopt. Een melding die te veel belooft, is geen hulp maar een bron van misverstanden.

Begin daarom met een eerlijke vraag: welk feit heeft het systeem op dit ogenblik echt vastgesteld, en welk feit nog niet?

Doorloop je eigen flow als klant en noteer alles wat je ziet of ontvangt. Doe dit met een testaanvraag die je achteraf kunt herkennen, en zo nodig met een testbetaling die je betaalprovider daarvoor toelaat. Controleer in de gebruikersomgeving van je provider zelf of testmodus beschikbaar is.

1. Open het formulier en verstuur het met herkenbare testgegevens.
2. Noteer de exacte tekst op het bevestigingsscherm, inclusief titel en eventuele knoppen.
3. Controleer de automatische e-mail: onderwerp, afzender, eerste zin en eventuele vermelding van een volgende stap.
4. Kijk in je interne systeem welke status de aanvraag nu heeft en wie daar een melding van krijgt.
5. Laat een collega zonder voorkennis vertellen wat volgens hem of haar nu is gebeurd en wat er nog moet gebeuren.
6. Herhaal dit voor het moment van goedkeuring en voor het moment van betaling.

Het antwoord van die collega in stap 5 is je belangrijkste meetpunt. Als die persoon 'het is betaald' zegt na enkel een verzonden aanvraag, is je taal te vaag. Dat is een observatie uit één test, geen bewijs over al je klanten; herhaal de test met enkele mensen om een patroon te zien.

Gebruik onderstaande tabel als vertrekpunt en pas de woorden aan je eigen aanbod aan. Een status krijgt pas een bevestigende tekst wanneer het bijbehorend feit is vastgesteld.

Beslisregel: komt een tekst op een scherm of in een mail terecht zonder dat het bijbehorende feit vaststaat, pas dan de tekst aan en niet het feit.

Een succesmelding mag pas verschijnen als de invoer geldig is. MDN over validatie aan de clientzijde beschrijft dat controle in de browser een eerste check is en een goede gebruikservaring geeft, maar niet bedoeld is als volledige beveiliging. Gegevens die via het formulier binnenkomen, moet je ook op de server controleren, omdat clientcontrole te makkelijk te omzeilen is.

Praktisch betekent dat twee dingen voor jouw statusnamen. Ten eerste: laat 'verzonden' pas verschijnen na een geslaagde ontvangst door de server, niet zodra de knop is aangeklikt. Ten tweede: toon bij een mislukte stap een foutmelding met een duidelijke hersteloptie, zodat de klant niet denkt dat alles in orde is.

Test dit bewust: laat een verplicht veld leeg, vul een e-mailadres in een verkeerd formaat in en onderbreek je verbinding vlak na het versturen. Noteer bij elke test welke melding verschijnt en of die klopt met wat er echt gebeurde. Vraag je ontwikkelaar of platformleverancier hoe de servercontrole is ingericht; vanuit de publieke pagina kun je dat niet bevestigen.

Let ook op het omgekeerde geval: een time-out of foutmelding kan optreden nadat de aanvraag al is opgeslagen. Controleer in een veilige testomgeving, met een unieke herkenbare testaanvraag, of die na een foutmelding toch in je systeem staat. Test ook wat er gebeurt als de klant opnieuw verstuurt: ontstaat er dan een tweede aanvraag of betaling, of herkent het systeem de eerste? Zonder die controle kan een foutmelding tot dubbele aanvragen leiden.

Dit voorbeeld is volledig verzonnen en bevat enkel invoer en verwachte controles, geen resultaten. Stel: een kmo verkoopt een dienstverlening na goedkeuring en laat de klant daarna online betalen.

Invoer: een testaanvraag met de naam 'Test Aanvraag 01', een herkenbaar e-mailadres van het team en een bedrag van 100 euro in een testomgeving.

Verwachte controles per stap:

1. Na verzenden toont het scherm 'ontvangen', niet 'bevestigd'. De mail noemt dat goedkeuring nog volgt. Intern staat de status op 'verzonden'.
2. Na handmatige goedkeuring wijzigt de status naar 'goedgekeurd'. De klant krijgt een mail met een betaallink en de zin dat betaling nog openstaat.
3. Na het starten van de betaling staat de status op 'betaling gestart'. Het scherm vermeldt dat de bevestiging nog wordt afgewacht. Sluit de klant de pagina of keert hij terug zonder uitkomst, dan blijft de status ongewijzigd tot de provider iets bevestigt.
4. Pas na bevestiging door de provider wordt de status 'betaald' en volgt de betaalbevestiging.

Overdrachtsnotitie voor collega's: noteer per status wie de volgende actie doet, binnen welke afgesproken tijd, en welke tekst de klant mag verwachten. Beloof niet universeel snel antwoord; stel enkel een termijn die jouw team echt kan waarmaken.

Na elke aanpassing aan tekst, status of koppeling herhaal je een korte controle. Het gaat om een eigen toets, geen garantie op minder vragen of meer afgeronde betalingen.

• Komt de tekst op het scherm overeen met de interne status op dat moment?
• Noemt de e-mail dezelfde statusnaam als het scherm en je intern systeem?
• Kan een lezer van enkel de mail zeggen wat er nog moet gebeuren?
• Is de foutmelding bij een mislukte stap anders dan de succesmelding?
• Weet elke collega wie de volgende stap oppakt?

Denk ook aan toegankelijkheid. De cursus Forms van web.dev behandelt onder meer het testen van formulieren op verschillende apparaten en het meten en analyseren ervan. Test je meldingen dus ook met toetsenbord en op een telefoon, en controleer of eventuele analyticsmetingen geen persoonsgegevens (zoals naam of e-mailadres) in eventparameters of URL's meesturen. Een gemeten pageview of klik bewijst bovendien geen ontvangen aanvraag of bevestigde betaling; die feiten volgen uit je server en je provider.

De grenzen: deze gids vertrekt van algemene richtlijnen voor formulieren en van een fictief voorbeeld. Hoe je betaalprovider, formulierplugin of webshop statussen verstuurt, kan verschillen en wijzigen; controleer dat in de beheeromgeving of bij de leverancier. Wil je weten welke zichtbare signalen je website nu geeft, bekijk ze dan via Marketing Scan. Een publieke scan meet wat zichtbaar is en bewijst geen volledige implementatie van deze controles.